<div dir="ltr">Yes, the comoving bit is not in the Castro anymore - or at least no one uses it that I'm aware of.<div><br></div><div style>The number of Level_*/Cell_D_* files for each level is actually based on the number of processors set to do IO. This can be changed with a runtime parameter; Maestro also does this. The simple problems for which you have Castro data (like the one I just uploaded to dickenson) were run on a single core, so there is only one Cell_D file per level.</div>
<div style><br></div><div style>Chris</div><div style><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, May 16, 2013 at 11:38 AM, Casey W. Stark <span dir="ltr"><<a href="mailto:caseywstark@gmail.com" target="_blank">caseywstark@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi Matt.<div><br></div><div>I think castro.use_comoving was removed once Nyx was ripped out.</div><div><br>
</div><div>It sounds like there are more inconsistencies... Nyx datasets always have the structure plt%05i/Level_%i, then in each level directory, the Cell_H file and 64 data files Cell_D_%04d from 0000 to 0063.</div>
</div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, May 16, 2013 at 11:29 AM, Matthew Turk <span dir="ltr"><<a href="mailto:matthewturk@gmail.com" target="_blank">matthewturk@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>On Thu, May 16, 2013 at 10:06 AM, Michael Zingale<br>
<<a href="mailto:michael.zingale@stonybrook.edu" target="_blank">michael.zingale@stonybrook.edu</a>> wrote:<br>
> Yes, that is correct.<br>
><br>
> Also, orion is C++ Box lib, not Fortran.<br>
<br>
</div>Oops, thanks.<br>
<div><br>
><br>
> Finally, because of how C++ boxlib works, it isn't easy to store runtime<br>
> parameters if the default was unchanged. In Fortran box lib, a python<br>
> script parses parameter files and writes f90 code at compile time, making it<br>
> easy.<br>
<br>
</div>Ah, okay, great. That is helpful, and something we can do.<br>
<div><br>
><br>
> So for Castro and Nyx, if you tell me exactly what info you might need from<br>
> the runtime paramters, I can add a section to job_info that provides the<br>
> info<br>
<br>
</div>I will look into this, but I think right now it comes down to:<br>
<br>
amr.n_cell (We might be able to get this in the Header?)<br>
amr.ref_ratio (which I think we can get elsewhere?)<br>
Prob.lo_bc<br>
castro.use_comoving<br>
comoving_OmL<br>
comoving_OmM<br>
comoving_h<br>
comoving_a (Which is currently in a different file)<br>
<br>
One thing I'm also wondering about is looking at the Header file, it<br>
seems that all of the examples I have only have a single data file for<br>
each level, of the form:<br>
<br>
Level_*/Cell<br>
<br>
with a corresponding Cell_H that contains the necessary header info.<br>
Is this how it always is -- as in, only one data file per Header? Is<br>
there a way to read, from the header, how many types of data files<br>
there will be? It would make things considerably easier if I knew how<br>
many types of data files.<br>
<div><div><br>
><br>
> On May 16, 2013 9:53 AM, "Matthew Turk" <<a href="mailto:matthewturk@gmail.com" target="_blank">matthewturk@gmail.com</a>> wrote:<br>
>><br>
>> As a quick followup, I have noticed that in many cases we default to<br>
>> using the "inputs" values over the values in the Header file. For<br>
>> instance, the domain edges and the index space. I'd rather use the<br>
>> Header file since it's a fundamental component, whereas the inputs<br>
>> should not strictly be necessary to orient the data, if I understand<br>
>> Boxlib correctly.<br>
>><br>
>> On Thu, May 16, 2013 at 9:18 AM, Matthew Turk <<a href="mailto:matthewturk@gmail.com" target="_blank">matthewturk@gmail.com</a>><br>
>> wrote:<br>
>> > Hi all,<br>
>> ><br>
>> > Okay, from reading this I think I see a few things to address:<br>
>> ><br>
>> > * We should certainly ensure that the Fortran/C++ frontends both<br>
>> > work. I believe -- but may be wrong -- that Maestro and Orion are the<br>
>> > "Boxlib Fortran" frontends, and Nyx and Castro are the "Boxlib C++"<br>
>> > frontends. The differences seem to be in how level files are stored<br>
>> > and a bit about the parameters.<br>
>> > * A clear message: make as many of the inputs files optional as<br>
>> > possible, and once the job_info changes have been deployed, that will<br>
>> > only leave Orion without job_info.<br>
>> > * Particles should be delegated to subclasses.<br>
>> > * Almost none of the Enzo-isms are necessary anymore, and we can work<br>
>> > around the gamma/refine_by stuff.<br>
>> > * Get rid of paranoia mode<br>
>> > * Put off changes to the Pluto/Chombo frontends<br>
>> ><br>
>> > For what it's worth, I've gotten a "boxlib" frontend that can load up<br>
>> > the example Orion data as well as a Maestro dataset that Mike provided<br>
>> > me. The biggest issue was with the fortran-formatted numbers we<br>
>> > corrected for previously, but I think I've got a workaround.<br>
>> ><br>
>> > In digging through the code I also found a number of routines that<br>
>> > have been largely unchanged since their first implementation some<br>
>> > years ago, which I'm going to try to clean up.<br>
>> ><br>
>> > Thanks everyone. I've been using the bookmark "boxlib" in my repo at<br>
>> > <a href="https://bitbucket.org/MatthewTurk/yt" target="_blank">https://bitbucket.org/MatthewTurk/yt</a> .<br>
>> ><br>
>> > -Matt<br>
>> ><br>
>> ><br>
>> ><br>
>> > On Wed, May 15, 2013 at 8:36 PM, Michael Zingale<br>
>> > <<a href="mailto:michael.zingale@stonybrook.edu" target="_blank">michael.zingale@stonybrook.edu</a>> wrote:<br>
>> >> Maestro particles are also their own thing, and we shouldn't worry<br>
>> >> about<br>
>> >> them. We use them for postprocessing, and not really visualization.<br>
>> >><br>
>> >> Looking in BoxLib, it is the case that the F90 BoxLib<br>
>> >> (Src/F_BaseLib/fabio.f90) specifies Level_XX instead of Level_X names<br>
>> >> for<br>
>> >> the directory.<br>
>> >><br>
>> >><br>
>> >> On Wed, May 15, 2013 at 7:30 PM, Andrew Myers <<a href="mailto:atmyers2@gmail.com" target="_blank">atmyers2@gmail.com</a>><br>
>> >> wrote:<br>
>> >>><br>
>> >>> Hi Folks,<br>
>> >>><br>
>> >>> The Orion particles are completely independent of BoxLib. I don't know<br>
>> >>> if<br>
>> >>> new BoxLib specifies a way for particle data to be stored, or if all<br>
>> >>> the<br>
>> >>> Boxlib codes just do their own thing, so I'm not sure whether:<br>
>> >>><br>
>> >>> 1. The base class should be agnostic about particles and particle<br>
>> >>> readers<br>
>> >>> get implemented in each subclass, or<br>
>> >>> 2. The base class should implement the Nyx-style particles and the<br>
>> >>> Orion<br>
>> >>> subclass should overwrite this.<br>
>> >>><br>
>> >>> Matt, on your specific questions:<br>
>> >>><br>
>> >>><br>
>> >>> * Is it okay to get rid of the old enzo parameter mappings?<br>
>> >>><br>
>> >>> If I'm reading the code correctly, this is currently needed for<br>
>> >>> "Gamma"<br>
>> >>> and "Refineby" to get set correctly, but nothing else.<br>
>> >>><br>
>> >>> * Do we need to have all of the paranoid IO still?<br>
>> >>><br>
>> >>> I'm not 100% sure what this does, but currently paranoid_read is False<br>
>> >>> by<br>
>> >>> default and I've never noticed a problem with that.<br>
>> >>><br>
>> >>> * Do you mind if I reword some of the names?<br>
>> >>><br>
>> >>> Not at all.<br>
>> >>><br>
>> >>> -Andrew<br>
>> >>><br>
>> >>> On Wed, May 15, 2013 at 3:32 PM, Casey W. Stark<br>
>> >>> <<a href="mailto:caseywstark@gmail.com" target="_blank">caseywstark@gmail.com</a>><br>
>> >>> wrote:<br>
>> >>>><br>
>> >>>> Hi Matt.<br>
>> >>>><br>
>> >>>> That all sounds right.<br>
>> >>>><br>
>> >>>> Really unifying the BoxLib codes sounds like tricky business to me. I<br>
>> >>>> think the current boxlib codes castro, maestro, and nyx will be using<br>
>> >>>> basically the same versions of boxlib, but orion could be different<br>
>> >>>> altogether. I haven't seen the code, so I can't say, but I bet this<br>
>> >>>> is the<br>
>> >>>> reason for the particle difference.<br>
>> >>>><br>
>> >>>> > * Castro was originally going to be a frontend<br>
>> >>>><br>
>> >>>> Nyx was originally part of Castro, but we ripped it out around the<br>
>> >>>> same<br>
>> >>>> time. Is anyone using yt with Castro data now?<br>
>> >>>><br>
>> >>>> > * Some weird differences like Level_%i and Level_%02i for level<br>
>> >>>> > filenames.<br>
>> >>>><br>
>> >>>> Hm, I don't know about this one since we never use more than a few<br>
>> >>>> levels, and that's rare.<br>
>> >>>><br>
>> >>>> > * Is it okay to get rid of the old enzo parameter mappings?<br>
>> >>>> > * Do we need to have all of the paranoid IO still?<br>
>> >>>><br>
>> >>>> I'm not sure what these were for... If things like parameter names<br>
>> >>>> are<br>
>> >>>> fine without the remapping, then great. The IO seems fine, so I doubt<br>
>> >>>> we<br>
>> >>>> need a paranoid option.<br>
>> >>>><br>
>> >>>> > * Do you mind if I reword some of the names?<br>
>> >>>><br>
>> >>>> Go for it.<br>
>> >>>><br>
>> >>>><br>
>> >>>><br>
>> >>>> On Wed, May 15, 2013 at 11:50 AM, Matthew Turk<br>
>> >>>> <<a href="mailto:matthewturk@gmail.com" target="_blank">matthewturk@gmail.com</a>><br>
>> >>>> wrote:<br>
>> >>>>><br>
>> >>>>> Hi all,<br>
>> >>>>><br>
>> >>>>> I'm spending a bit of time today looking over the Boxlib frontends<br>
>> >>>>> and<br>
>> >>>>> identifying commonalities and differences. I wanted to write with<br>
>> >>>>> some of my initial findings as well as some specific questions.<br>
>> >>>>><br>
>> >>>>> Casey, Andrew, and Jeff I would particularly like your feedback, but<br>
>> >>>>> I<br>
>> >>>>> also intend to submit this for detailed review and collaboration.<br>
>> >>>>> My<br>
>> >>>>> general plan is to consolidate the data_structures, IO and<br>
>> >>>>> definitions<br>
>> >>>>> into a single Boxlib frontend, with subclasses that cover each of<br>
>> >>>>> the<br>
>> >>>>> specific differences.<br>
>> >>>>><br>
>> >>>>> The main differences I am seeing:<br>
>> >>>>><br>
>> >>>>> * Castro was originally going to be a frontend, but morphed into<br>
>> >>>>> the<br>
>> >>>>> Nyx frontend, and I don't believe anything Castro-specific is left<br>
>> >>>>> anymore. I am inclined to remove it and in the future add on any<br>
>> >>>>> subclass-specific items when Castro comes back into the fold.<br>
>> >>>>> * Nyx and Orion handle particles completely differently.<br>
>> >>>>> * Nyx has optimized IO, particularly for fluids, which we should<br>
>> >>>>> use<br>
>> >>>>> everywhere.<br>
>> >>>>> * Some weird differences like Level_%i and Level_%02i for level<br>
>> >>>>> filenames.<br>
>> >>>>> * Units will need to be set individually.<br>
>> >>>>> * Parsing the Fortran and non-Fortran parameter files (i.e.,<br>
>> >>>>> Maestro<br>
>> >>>>> and everyone else) will be tricky.<br>
>> >>>>><br>
>> >>>>> There were a few other things I wanted to get feed back on.<br>
>> >>>>><br>
>> >>>>> * Is it okay to get rid of the old enzo parameter mappings?<br>
>> >>>>> * Do we need to have all of the paranoid IO still?<br>
>> >>>>> * Do you mind if I reword some of the names?<br>
>> >>>>><br>
>> >>>>> What do you all think? If anybody wants to help out, I'll be in IRC<br>
>> >>>>> working on this for a while today, but I'll also try to submit a PR<br>
>> >>>>> as<br>
>> >>>>> early as possible to iterate on and get feedback from.<br>
>> >>>>><br>
>> >>>>> -Matt<br>
>> >>>>> _______________________________________________<br>
>> >>>>> yt-dev mailing list<br>
>> >>>>> <a href="mailto:yt-dev@lists.spacepope.org" target="_blank">yt-dev@lists.spacepope.org</a><br>
>> >>>>> <a href="http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org" target="_blank">http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org</a><br>
>> >>>><br>
>> >>>><br>
>> >>>><br>
>> >>>> _______________________________________________<br>
>> >>>> yt-dev mailing list<br>
>> >>>> <a href="mailto:yt-dev@lists.spacepope.org" target="_blank">yt-dev@lists.spacepope.org</a><br>
>> >>>> <a href="http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org" target="_blank">http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org</a><br>
>> >>>><br>
>> >>><br>
>> >><br>
>> >><br>
>> >><br>
>> >> --<br>
>> >> Michael Zingale<br>
>> >> Associate Professor<br>
>> >><br>
>> >> Dept. of Physics & Astronomy • Stony Brook University • Stony Brook, NY<br>
>> >> 11794-3800<br>
>> >> phone: <a href="tel:631-632-8225" value="+16316328225" target="_blank">631-632-8225</a><br>
>> >> e-mail: <a href="mailto:Michael.Zingale@stonybrook.edu" target="_blank">Michael.Zingale@stonybrook.edu</a><br>
>> >> web: <a href="http://www.astro.sunysb.edu/mzingale" target="_blank">http://www.astro.sunysb.edu/mzingale</a><br>
_______________________________________________<br>
yt-dev mailing list<br>
<a href="mailto:yt-dev@lists.spacepope.org" target="_blank">yt-dev@lists.spacepope.org</a><br>
<a href="http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org" target="_blank">http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org</a><br>
</div></div></blockquote></div><br></div>
</div></div><br>_______________________________________________<br>
yt-dev mailing list<br>
<a href="mailto:yt-dev@lists.spacepope.org">yt-dev@lists.spacepope.org</a><br>
<a href="http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org" target="_blank">http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org</a><br>
<br></blockquote></div><br></div>