[yt-dev] Consolidating Boxlib frontends

[Casey W. Stark]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.spacepope.org/pipermail/yt-dev-spacepope.org/attachments/20130515/510a5c59/attachment.html>