<div dir="ltr">Maestro particles are also their own thing, and we shouldn't worry about them. We use them for postprocessing, and not really visualization.<div><br></div><div style>Looking in BoxLib, it is the case that the F90 BoxLib (Src/F_BaseLib/fabio.f90) specifies Level_XX instead of Level_X names for the directory.</div>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, May 15, 2013 at 7:30 PM, Andrew Myers <span dir="ltr"><<a href="mailto:atmyers2@gmail.com" target="_blank">atmyers2@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Folks,<br><br>The Orion particles are completely independent of BoxLib. I don't know if new BoxLib specifies a way for particle data to be stored, or if all the 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 get implemented in each subclass, or<br>2. The base class should implement the Nyx-style particles and the Orion subclass should overwrite this.<br>
<br>Matt, on your specific questions:<div class="im"><br><br> * Is it okay to get rid of the old enzo parameter mappings?<br><br></div><div style="margin-left:40px">If I'm reading the code correctly, this is currently needed for "Gamma" and "Refineby" to get set correctly, but nothing else. <br>
</div><div class="im"><br>
* Do we need to have all of the paranoid IO still?<br><br></div><div style="margin-left:40px">I'm not 100% sure what this does, but currently paranoid_read is False by default and I've never noticed a problem with that.</div>
<div class="im">
<br>
* Do you mind if I reword some of the names?<br><br></div><div style="margin-left:40px">Not at all. <br></div><span class="HOEnZb"><font color="#888888"><br>-Andrew<br><br></font></span><div class="gmail_quote"><div class="im">
On Wed, May 15, 2013 at 3:32 PM, Casey W. Stark <span dir="ltr"><<a href="mailto:caseywstark@gmail.com" target="_blank">caseywstark@gmail.com</a>></span> wrote:<br>
</div><div><div class="h5"><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><div><div class="gmail_extra"><br><br><div class="gmail_quote">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>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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>
_______________________________________________<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>
</div></div><br>_______________________________________________<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>
<br></blockquote></div></div></div><br>
</blockquote></div><br><br clear="all"><div><br></div>-- <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>: 631-632-8225</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>
</div>