[yt-dev] Consolidating Boxlib frontends
Matthew Turk
matthewturk at gmail.com
Fri May 17 12:09:48 PDT 2013
Hi all,
I've opened a PR:
https://bitbucket.org/yt_analysis/yt/pull-request/501/consolidation-of-boxlib-frontends
As noted, I've started with the Orion frontend (except for IO, which
was grabbed from Nyx) so if you want to compare this to old code,
check the yt/frontends/orion/data_structures.py file. Feedback inline
or here would be appreciated.
-Matt
On Thu, May 16, 2013 at 5:15 PM, Matthew Turk <matthewturk at gmail.com> wrote:
> Hi Mike,
>
> That definitely helps.
>
> I've pushed a few changesets up to my fork. I've rewritten nearly all
> of the parameter file parsing and hierarchy parsing, and what limited
> tests I have been able to do (on Orion and Maestro data) suggest that
> it is currently working. If anyone would like to take a look, clone
> the bookmark with:
>
> hg clone -r boxlib https://bitbucket.org/MatthewTurk/yt
>
> or look at the diffs here:
>
> https://bitbucket.org/MatthewTurk/yt/compare/boxlib..yt_analysis/yt:yt#diff
>
> There are a few other general clean ups to make in the fields.py,
> definitions.py and io.py for boxlib, but I think this puts us on a
> good footing to unify the various frontends in the near term. Andrew,
> Casey and Jeff, since you've all been in the guts of the Boxlib
> frameworks, and comments on the code style or assumptions about the
> header (which I have commented) would be helpful. Among the bigger
> changes I made is to get rid of field_indexes on the grid-by-grid
> basis, which all seemed to be identical, as well as to go for a single
> filename per grid rather than filenames per field per grid. I also
> found that grids only had a single offset independent of the field
> being requested, which makes sense with how offsets are calculated
> anyway, so I think that's been fixed as well.
>
> The next steps will be to test and run with Nyx, with the new Castro
> data that Chris sent me, and then to come up with a strategy for
> sending the correct particles/IO systems to the correct frontends so
> that load() works properly.
>
> I can also open a PR if that's easier for providing feedback, but
> coarse feedback here is useful as well. Thanks all,
>
> -Matt
>
> On Thu, May 16, 2013 at 2:59 PM, Michael Zingale
> <michael.zingale at stonybrook.edu> wrote:
>> not sure if this helps of not, but this is from plotfile.f90 in BoxLib:
>>
>> ! NavierStokes-V1.1 Plotfile Formats
>> ! Record
>> ! : c : NavierStokes-V1.1/HyperClaw-V1.1
>> ! : c : Numbers of fields = n
>> ! n: i : Field Names
>> ! : i : Dimension = dm
>> ! : r : Time
>> ! : i : Number of Levels - 1 : nl
>> ! : r : Physical domain lo end [1:dm]
>> ! : r : Physical domain hi end [1:dm]
>> ! : i : Refinement Ratios [1:nl-1]
>> ! : b : Prob domains per level [1:nl]
>> ! : i : unused [1:nl]
>> ! nl: r : grid spacing, per level, [1:dm]
>> ! : i : unused :
>> ! : i : unused
>> ! For each level
>> ! [
>> ! : iiri : dummy, nboxes, dummy, dummy
>> ! For each box, j
>> ! [
>> ! : r : plo[1:dm,j], phi[1:dm, j]
>> ! ]
>> ! : c : level directory
>> ! ]
>> ! Close Header File
>> ! For each level
>> ! [
>> ! Open Header of sub-directory
>> ! : iiii: dummy, dummy, ncomponents, dummy
>> ! : i ; '(', nboxes dummy
>> ! For each box, j
>> ! [
>> ! : b : bx[j]
>> ! ]
>> ! : : ')'
>> ! For each box, j
>> ! [
>> ! : ci : 'FabOnDisk: ' Filename[j], Offset[j]
>> ! ]
>> ! : i : nboxes, ncomponents
>> ! For each box, j
>> ! [
>> ! : r : min[j]
>> ! ]
>> ! : i : nboxes, ncomponents
>> ! For each box, j
>> ! [
>> ! : r : man[j]
>> ! ]
>> ! Close subgrid file
>> ! ]
>>
>>
>>
>> On Thu, May 16, 2013 at 2:56 PM, Matthew Turk <matthewturk at gmail.com> wrote:
>>>
>>> Thanks, everybody!
>>>
>>> On Thu, May 16, 2013 at 2:55 PM, Michael Zingale
>>> <michael.zingale at stonybrook.edu> wrote:
>>> > just to be clear, that is the number of MPI tasks, not the number of
>>> > processors (# pros = # MPI * OMP_NUM_THREADS)
>>> >
>>> > I just looked at a big run I did for a paper on > 10,000 cores, and
>>> > there is
>>> > just a single line:
>>> >
>>> > Level_00/Cell
>>> >
>>> >
>>> >
>>> > On Thu, May 16, 2013 at 2:52 PM, Matthew Turk <matthewturk at gmail.com>
>>> > wrote:
>>> >>
>>> >> On Thu, May 16, 2013 at 2:47 PM, Chris Malone
>>> >> <chris.m.malone at gmail.com>
>>> >> wrote:
>>> >> > Yes, the comoving bit is not in the Castro anymore - or at least no
>>> >> > one
>>> >> > uses
>>> >> > it that I'm aware of.
>>> >> >
>>> >> > The number of Level_*/Cell_D_* files for each level is actually based
>>> >> > on
>>> >> > the
>>> >> > number of processors set to do IO. This can be changed with a
>>> >> > runtime
>>> >> > parameter; Maestro also does this. The simple problems for which you
>>> >> > have
>>> >> > Castro data (like the one I just uploaded to dickenson) were run on a
>>> >> > single
>>> >> > core, so there is only one Cell_D file per level.
>>> >>
>>> >> The number of processors is also in the Cell_H file on the third line,
>>> >> to my understanding of the format. But I think I'm still not making
>>> >> myself clear: will there ever be a data file that isn't
>>> >> Cell_Something. Let me give an example. In RadTube's global Header
>>> >> file we have:
>>> >>
>>> >> 0 8 7.26154130223839759212753081768e-07
>>> >> 500
>>> >> 0 16
>>> >> 0 16
>>> >> 0 16
>>> >> 112 128
>>> >> 0 16
>>> >> 0 16
>>> >> 96 112
>>> >> 0 16
>>> >> 0 16
>>> >> 80 96
>>> >> 0 16
>>> >> 0 16
>>> >> 64 80
>>> >> 0 16
>>> >> 0 16
>>> >> 48 64
>>> >> 0 16
>>> >> 0 16
>>> >> 32 48
>>> >> 0 16
>>> >> 0 16
>>> >> 16 32
>>> >> 0 16
>>> >> 0 16
>>> >> Level_0/Cell
>>> >> 1 36 7.26154130223839970970989895344e-07
>>> >>
>>> >> I am currently parsing this by getting each lo/hi/dimension pair, then
>>> >> assuming there is a *single* line following the set that describes the
>>> >> prefix for the level header, in this case Level_0/Cell , which is then
>>> >> followed by the *next level*. The original frontend code was much
>>> >> more lenient, and in fact allowed for *multiple* filenames to be
>>> >> displayed there -- for instance, it would allow something like:
>>> >>
>>> >> Level_0/Cell
>>> >> Level_0/Dinosaurs
>>> >> Level_0/BlahBlah
>>> >>
>>> >> where it expects Level_0/Dinosaurs_H and Level_0/BlahBlah_H as well as
>>> >> their corresponding processor files. *Is this real* or can I just
>>> >> assume there will only be one type of data file, in this case
>>> >> Level_0/Cell and its corresponding data?
>>> >>
>>> >> >
>>> >> > Chris
>>> >> >
>>> >> >
>>> >> >
>>> >> > On Thu, May 16, 2013 at 11:38 AM, Casey W. Stark
>>> >> > <caseywstark at gmail.com>
>>> >> > wrote:
>>> >> >>
>>> >> >> Hi Matt.
>>> >> >>
>>> >> >> I think castro.use_comoving was removed once Nyx was ripped out.
>>> >> >>
>>> >> >> It sounds like there are more inconsistencies... Nyx datasets always
>>> >> >> have
>>> >> >> the structure plt%05i/Level_%i, then in each level directory, the
>>> >> >> Cell_H
>>> >> >> file and 64 data files Cell_D_%04d from 0000 to 0063.
>>> >> >>
>>> >> >>
>>> >> >> On Thu, May 16, 2013 at 11:29 AM, Matthew Turk
>>> >> >> <matthewturk at gmail.com>
>>> >> >> wrote:
>>> >> >>>
>>> >> >>> On Thu, May 16, 2013 at 10:06 AM, Michael Zingale
>>> >> >>> <michael.zingale at stonybrook.edu> wrote:
>>> >> >>> > Yes, that is correct.
>>> >> >>> >
>>> >> >>> > Also, orion is C++ Box lib, not Fortran.
>>> >> >>>
>>> >> >>> Oops, thanks.
>>> >> >>>
>>> >> >>> >
>>> >> >>> > Finally, because of how C++ boxlib works, it isn't easy to store
>>> >> >>> > runtime
>>> >> >>> > parameters if the default was unchanged. In Fortran box lib, a
>>> >> >>> > python
>>> >> >>> > script parses parameter files and writes f90 code at compile
>>> >> >>> > time,
>>> >> >>> > making it
>>> >> >>> > easy.
>>> >> >>>
>>> >> >>> Ah, okay, great. That is helpful, and something we can do.
>>> >> >>>
>>> >> >>> >
>>> >> >>> > So for Castro and Nyx, if you tell me exactly what info you might
>>> >> >>> > need
>>> >> >>> > from
>>> >> >>> > the runtime paramters, I can add a section to job_info that
>>> >> >>> > provides
>>> >> >>> > the
>>> >> >>> > info
>>> >> >>>
>>> >> >>> I will look into this, but I think right now it comes down to:
>>> >> >>>
>>> >> >>> amr.n_cell (We might be able to get this in the Header?)
>>> >> >>> amr.ref_ratio (which I think we can get elsewhere?)
>>> >> >>> Prob.lo_bc
>>> >> >>> castro.use_comoving
>>> >> >>> comoving_OmL
>>> >> >>> comoving_OmM
>>> >> >>> comoving_h
>>> >> >>> comoving_a (Which is currently in a different file)
>>> >> >>>
>>> >> >>> One thing I'm also wondering about is looking at the Header file,
>>> >> >>> it
>>> >> >>> seems that all of the examples I have only have a single data file
>>> >> >>> for
>>> >> >>> each level, of the form:
>>> >> >>>
>>> >> >>> Level_*/Cell
>>> >> >>>
>>> >> >>> with a corresponding Cell_H that contains the necessary header
>>> >> >>> info.
>>> >> >>> Is this how it always is -- as in, only one data file per Header?
>>> >> >>> Is
>>> >> >>> there a way to read, from the header, how many types of data files
>>> >> >>> there will be? It would make things considerably easier if I knew
>>> >> >>> how
>>> >> >>> many types of data files.
>>> >> >>>
>>> >> >>> >
>>> >> >>> > On May 16, 2013 9:53 AM, "Matthew Turk" <matthewturk at gmail.com>
>>> >> >>> > wrote:
>>> >> >>> >>
>>> >> >>> >> As a quick followup, I have noticed that in many cases we
>>> >> >>> >> default
>>> >> >>> >> to
>>> >> >>> >> using the "inputs" values over the values in the Header file.
>>> >> >>> >> For
>>> >> >>> >> instance, the domain edges and the index space. I'd rather use
>>> >> >>> >> the
>>> >> >>> >> Header file since it's a fundamental component, whereas the
>>> >> >>> >> inputs
>>> >> >>> >> should not strictly be necessary to orient the data, if I
>>> >> >>> >> understand
>>> >> >>> >> Boxlib correctly.
>>> >> >>> >>
>>> >> >>> >> On Thu, May 16, 2013 at 9:18 AM, Matthew Turk
>>> >> >>> >> <matthewturk at gmail.com>
>>> >> >>> >> wrote:
>>> >> >>> >> > Hi all,
>>> >> >>> >> >
>>> >> >>> >> > Okay, from reading this I think I see a few things to address:
>>> >> >>> >> >
>>> >> >>> >> > * We should certainly ensure that the Fortran/C++ frontends
>>> >> >>> >> > both
>>> >> >>> >> > work. I believe -- but may be wrong -- that Maestro and Orion
>>> >> >>> >> > are
>>> >> >>> >> > the
>>> >> >>> >> > "Boxlib Fortran" frontends, and Nyx and Castro are the "Boxlib
>>> >> >>> >> > C++"
>>> >> >>> >> > frontends. The differences seem to be in how level files are
>>> >> >>> >> > stored
>>> >> >>> >> > and a bit about the parameters.
>>> >> >>> >> > * A clear message: make as many of the inputs files optional
>>> >> >>> >> > as
>>> >> >>> >> > possible, and once the job_info changes have been deployed,
>>> >> >>> >> > that
>>> >> >>> >> > will
>>> >> >>> >> > only leave Orion without job_info.
>>> >> >>> >> > * Particles should be delegated to subclasses.
>>> >> >>> >> > * Almost none of the Enzo-isms are necessary anymore, and we
>>> >> >>> >> > can
>>> >> >>> >> > work
>>> >> >>> >> > around the gamma/refine_by stuff.
>>> >> >>> >> > * Get rid of paranoia mode
>>> >> >>> >> > * Put off changes to the Pluto/Chombo frontends
>>> >> >>> >> >
>>> >> >>> >> > For what it's worth, I've gotten a "boxlib" frontend that can
>>> >> >>> >> > load
>>> >> >>> >> > up
>>> >> >>> >> > the example Orion data as well as a Maestro dataset that Mike
>>> >> >>> >> > provided
>>> >> >>> >> > me. The biggest issue was with the fortran-formatted numbers
>>> >> >>> >> > we
>>> >> >>> >> > corrected for previously, but I think I've got a workaround.
>>> >> >>> >> >
>>> >> >>> >> > In digging through the code I also found a number of routines
>>> >> >>> >> > that
>>> >> >>> >> > have been largely unchanged since their first implementation
>>> >> >>> >> > some
>>> >> >>> >> > years ago, which I'm going to try to clean up.
>>> >> >>> >> >
>>> >> >>> >> > Thanks everyone. I've been using the bookmark "boxlib" in my
>>> >> >>> >> > repo
>>> >> >>> >> > at
>>> >> >>> >> > https://bitbucket.org/MatthewTurk/yt .
>>> >> >>> >> >
>>> >> >>> >> > -Matt
>>> >> >>> >> >
>>> >> >>> >> >
>>> >> >>> >> >
>>> >> >>> >> > On Wed, May 15, 2013 at 8:36 PM, Michael Zingale
>>> >> >>> >> > <michael.zingale at stonybrook.edu> wrote:
>>> >> >>> >> >> Maestro particles are also their own thing, and we shouldn't
>>> >> >>> >> >> worry
>>> >> >>> >> >> about
>>> >> >>> >> >> them. We use them for postprocessing, and not really
>>> >> >>> >> >> visualization.
>>> >> >>> >> >>
>>> >> >>> >> >> 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.
>>> >> >>> >> >>
>>> >> >>> >> >>
>>> >> >>> >> >> On Wed, May 15, 2013 at 7:30 PM, Andrew Myers
>>> >> >>> >> >> <atmyers2 at gmail.com>
>>> >> >>> >> >> wrote:
>>> >> >>> >> >>>
>>> >> >>> >> >>> Hi Folks,
>>> >> >>> >> >>>
>>> >> >>> >> >>> 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:
>>> >> >>> >> >>>
>>> >> >>> >> >>> 1. The base class should be agnostic about particles and
>>> >> >>> >> >>> particle
>>> >> >>> >> >>> readers
>>> >> >>> >> >>> get implemented in each subclass, or
>>> >> >>> >> >>> 2. The base class should implement the Nyx-style particles
>>> >> >>> >> >>> and
>>> >> >>> >> >>> the
>>> >> >>> >> >>> Orion
>>> >> >>> >> >>> subclass should overwrite this.
>>> >> >>> >> >>>
>>> >> >>> >> >>> Matt, on your specific questions:
>>> >> >>> >> >>>
>>> >> >>> >> >>>
>>> >> >>> >> >>> * Is it okay to get rid of the old enzo parameter mappings?
>>> >> >>> >> >>>
>>> >> >>> >> >>> If I'm reading the code correctly, this is currently needed
>>> >> >>> >> >>> for
>>> >> >>> >> >>> "Gamma"
>>> >> >>> >> >>> and "Refineby" to get set correctly, but nothing else.
>>> >> >>> >> >>>
>>> >> >>> >> >>> * Do we need to have all of the paranoid IO still?
>>> >> >>> >> >>>
>>> >> >>> >> >>> 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.
>>> >> >>> >> >>>
>>> >> >>> >> >>> * Do you mind if I reword some of the names?
>>> >> >>> >> >>>
>>> >> >>> >> >>> Not at all.
>>> >> >>> >> >>>
>>> >> >>> >> >>> -Andrew
>>> >> >>> >> >>>
>>> >> >>> >> >>> On Wed, May 15, 2013 at 3: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
>>> >> >>> >> >>>>
>>> >> >>> >> >>>>
>>> >> >>> >> >>>>
>>> >> >>> >> >>>> _______________________________________________
>>> >> >>> >> >>>> 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
>>> >> >>> _______________________________________________
>>> >> >>> yt-dev mailing list
>>> >> >>> yt-dev at lists.spacepope.org
>>> >> >>> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>>> >> >>
>>> >> >>
>>> >> >>
>>> >> >> _______________________________________________
>>> >> >> yt-dev mailing list
>>> >> >> yt-dev at lists.spacepope.org
>>> >> >> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>>> >> >>
>>> >> >
>>> >> >
>>> >> > _______________________________________________
>>> >> > 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
>>
>>
>>
>>
>> --
>> 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
More information about the yt-dev
mailing list