<div dir="ltr">Hi Mike.<div><br></div><div style>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!</div>
<div style><br></div><div style>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?</div></div><div class="gmail_extra">
<br><br><div class="gmail_quote">On Wed, May 15, 2013 at 3:38 PM, Michael Zingale <span dir="ltr"><<a href="mailto:michael.zingale@stonybrook.edu" target="_blank">michael.zingale@stonybrook.edu</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">The Level_%02i bit is for Maestro, I believe, looking at a Maestro plotfile, level 0 is stored as Level_00/<div>
<br></div><div>Castro and Nyx are quite similar, since they are both C++ BoxLib</div><div>
Maestro uses Fortran BoxLib, and has some differences. </div><div>Orion is being ported to Chombo, as best as I understand.</div><div><br></div><div>We want to use yt with both Castro and Maestro.</div>
<div><br></div><div>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.</div>
<div><br></div><div>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).</div>
<div><br></div><div>Mike</div></div><div class="gmail_extra"><div><div class="h5"><br><br><div class="gmail_quote">On Wed, May 15, 2013 at 6:32 PM, 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>That all sounds right.</div><div><br></div><div>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.</div>
<div>
<div><br></div><div><span style="font-family:arial,sans-serif;font-size:13px">> * Castro was originally going to be a frontend</span><br></div><div><br></div></div><div>Nyx was originally part of Castro, but we ripped it out around the same time. Is anyone using yt with Castro data now?</div>
<div>
<div><br></div><div>> <span style="font-family:arial,sans-serif;font-size:13px"> * Some weird differences like Level_%i and Level_%02i for level filenames.</span></div><div><br></div></div><div>Hm, I don't know about this one since we never use more than a few levels, and that's rare.</div>
<div>
<div><br></div><div>> <span style="font-family:arial,sans-serif;font-size:13px"> * Is it okay to get rid of the old enzo parameter mappings?</span></div><div>> <span style="font-size:13px;font-family:arial,sans-serif">* Do we need to have all of the paranoid IO still?</span></div>
<div><span style="font-size:13px;font-family:arial,sans-serif"><br></span></div></div><div><font face="arial, sans-serif">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.</font></div>
<div>
<div><br></div><div>> <span style="font-family:arial,sans-serif;font-size:13px"> * Do you mind if I reword some of the names?</span></div><div><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div>
</div><div><font face="arial, sans-serif">Go for it.</font></div><div><font face="arial, sans-serif"><br></font></div></div><div class="gmail_extra"><br><br><div class="gmail_quote"><div><div>On Wed, May 15, 2013 at 11:50 AM, Matthew Turk <span dir="ltr"><<a href="mailto:matthewturk@gmail.com" target="_blank">matthewturk@gmail.com</a>></span> wrote:<br>
</div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div>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 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></div></div>
_______________________________________________<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>
</blockquote></div><br></div>
</blockquote></div><br><br clear="all"><div><br></div></div></div><span class="HOEnZb"><font color="#888888">-- <br><div>Michael Zingale</div><div>Associate Professor</div><div><br></div><div>Dept. of Physics & Astronomy • Stony Brook University • Stony Brook, NY 11794-3800</div>
<div><i>phone</i>: <a href="tel:631-632-8225" value="+16316328225" target="_blank">631-632-8225</a></div><div><i>e-mail</i>: <a href="mailto:Michael.Zingale@stonybrook.edu" target="_blank">Michael.Zingale@stonybrook.edu</a></div>
<div><i>web</i>: <a href="http://www.astro.sunysb.edu/mzingale" target="_blank">http://www.astro.sunysb.edu/mzingale</a></div>
</font></span></div>
</blockquote></div><br></div>