<p dir="ltr">Yes, that is correct.</p>
<p dir="ltr">Also, orion is C++ Box lib, not Fortran.</p>
<p dir="ltr">Finally, because of how C++ boxlib works, it isn't easy to store runtime parameters if the default was unchanged.  In Fortran box lib, a python script parses parameter files and writes f90 code at compile time, making it easy.</p>

<p dir="ltr">So for Castro and Nyx, if you tell me exactly what info you might need from the runtime paramters, I can add a section to job_info that provides the info</p>
<div class="gmail_quote">On May 16, 2013 9:53 AM, "Matthew Turk" <<a href="mailto:matthewturk@gmail.com">matthewturk@gmail.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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">matthewturk@gmail.com</a>> 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">michael.zingale@stonybrook.edu</a>> wrote:<br>
>> Maestro particles are also their own thing, and we shouldn't worry 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 for<br>
>> the directory.<br>
>><br>
>><br>
>> On Wed, May 15, 2013 at 7:30 PM, Andrew Myers <<a href="mailto:atmyers2@gmail.com">atmyers2@gmail.com</a>> wrote:<br>
>>><br>
>>> Hi Folks,<br>
>>><br>
>>> The Orion particles are completely independent of BoxLib. I don't know if<br>
>>> new BoxLib specifies a way for particle data to be stored, or if all 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 readers<br>
>>> get implemented in each subclass, or<br>
>>> 2. The base class should implement the Nyx-style particles and the 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 "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 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 <<a href="mailto:caseywstark@gmail.com">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 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 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 are<br>
>>>> fine without the remapping, then great. The IO seems fine, so I doubt 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 <<a href="mailto:matthewturk@gmail.com">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 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 I<br>
>>>>> also intend to submit this for detailed review and collaboration.  My<br>
>>>>> general plan is to consolidate the data_structures, IO and definitions<br>
>>>>> into a single Boxlib frontend, with subclasses that cover each of 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 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 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., 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 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">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">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">631-632-8225</a><br>
>> e-mail: <a href="mailto:Michael.Zingale@stonybrook.edu">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>
</blockquote></div>