[yt-dev] Consolidating Boxlib frontends

[Michael Zingale]

The Level_%02i bit is for Maestro, I believe, looking at a Maestro
plotfile, level 0 is stored as Level_00/

Castro and Nyx are quite similar, since they are both C++ BoxLib
Maestro uses Fortran BoxLib, and has some differences.
Orion is being ported to Chombo, as best as I understand.

We want to use yt with both Castro and Maestro.

For Maestro, the easiest way to get the input parameters is via the
job_info file in the pltXXXXX/ directory.  I can change the way they are
stored there, if desired, to make it easier to parse.  This has every
single runtime parameter (whether we overrode the default or not), and
eliminates the need to keep around the inputs file.

For Castro, the job_info file only lists the C++ parameters that overrode
the defaults, so it is not sufficient to replace the inputs file.  I plan
to add the Fortran parameters to the Castro job_info (and that will
probably be ported to Nyx like the other job_info stuff I did).

Mike


On Wed, May 15, 2013 at 6:32 PM, Casey W. Stark <caseywstark at gmail.com>wrote:

> Hi Matt.
>
> That all sounds right.
>
> Really unifying the BoxLib codes sounds like tricky business to me. I
> think the current boxlib codes castro, maestro, and nyx will be using
> basically the same versions of boxlib, but orion could be different
> altogether. I haven't seen the code, so I can't say, but I bet this is the
> reason for the particle difference.
>
> > * Castro was originally going to be a frontend
>
> Nyx was originally part of Castro, but we ripped it out around the same
> time. Is anyone using yt with Castro data now?
>
> >  * Some weird differences like Level_%i and Level_%02i for level
> filenames.
>
> Hm, I don't know about this one since we never use more than a few levels,
> and that's rare.
>
> >  * Is it okay to get rid of the old enzo parameter mappings?
> > * Do we need to have all of the paranoid IO still?
>
> I'm not sure what these were for... If things like parameter names are
> fine without the remapping, then great. The IO seems fine, so I doubt we
> need a paranoid option.
>
> >  * Do you mind if I reword some of the names?
>
> Go for it.
>
>
>
> On Wed, May 15, 2013 at 11:50 AM, Matthew Turk <matthewturk at gmail.com>wrote:
>
>> Hi all,
>>
>> I'm spending a bit of time today looking over the Boxlib frontends and
>> identifying commonalities and differences.  I wanted to write with
>> some of my initial findings as well as some specific questions.
>>
>> Casey, Andrew, and Jeff I would particularly like your feedback, but I
>> also intend to submit this for detailed review and collaboration.  My
>> general plan is to consolidate the data_structures, IO and definitions
>> into a single Boxlib frontend, with subclasses that cover each of the
>> specific differences.
>>
>> The main differences I am seeing:
>>
>>  * Castro was originally going to be a frontend, but morphed into the
>> Nyx frontend, and I don't believe anything Castro-specific is left
>> anymore.  I am inclined to remove it and in the future add on any
>> subclass-specific items when Castro comes back into the fold.
>>  * Nyx and Orion handle particles completely differently.
>>  * Nyx has optimized IO, particularly for fluids, which we should use
>> everywhere.
>>  * Some weird differences like Level_%i and Level_%02i for level
>> filenames.
>>  * Units will need to be set individually.
>>  * Parsing the Fortran and non-Fortran parameter files (i.e., Maestro
>> and everyone else) will be tricky.
>>
>> There were a few other things I wanted to get feed back on.
>>
>>  * Is it okay to get rid of the old enzo parameter mappings?
>>  * Do we need to have all of the paranoid IO still?
>>  * Do you mind if I reword some of the names?
>>
>> What do you all think?  If anybody wants to help out, I'll be in IRC
>> working on this for a while today, but I'll also try to submit a PR as
>> early as possible to iterate on and get feedback from.
>>
>> -Matt
>> _______________________________________________
>> yt-dev mailing list
>> yt-dev at lists.spacepope.org
>> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>>
>
>


-- 
Michael Zingale
Associate Professor

Dept. of Physics & Astronomy • Stony Brook University • Stony Brook, NY
11794-3800
*phone*:  631-632-8225
*e-mail*: Michael.Zingale at stonybrook.edu
*web*: http://www.astro.sunysb.edu/mzingale
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.spacepope.org/pipermail/yt-dev-spacepope.org/attachments/20130515/6832ad53/attachment.htm>