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:<br><br> * Is it okay to get rid of the old enzo parameter mappings?<br><br><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><br>
* Do we need to have all of the paranoid IO still?<br><br><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>
<br>
* Do you mind if I reword some of the names?<br><br><div style="margin-left:40px">Not at all. <br></div><br>-Andrew<br><br><div class="gmail_quote">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>
<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 class="im">
<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 class="im">
<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 class="im">
<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 class="im">
<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="HOEnZb"><div class="h5"><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">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><br>