[yt-dev] Consolidating Boxlib frontends

Casey W. Stark caseywstark at gmail.com
Wed May 15 15:57:22 PDT 2013


Hi Mike.

Having the Fortran parameters saved in the plotfile would be awesome. It's
a small thing, but carrying around the inputs/probin files everywhere is
annoying. Thanks!

I should have been clearer about the level directory names. Nyx uses
Level_0, Level_1, ... so maybe this is a subtle difference between the
boxlib c++ and fortran interfaces?


On Wed, May 15, 2013 at 3:38 PM, Michael Zingale <
michael.zingale at stonybrook.edu> wrote:

> 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/4dd55f52/attachment.html>


More information about the yt-dev mailing list