<div dir="ltr">not sure if this helps of not, but this is from plotfile.f90 in BoxLib:<div><br></div><div><div> ! NavierStokes-V1.1 Plotfile Formats</div><div> ! Record</div><div> ! : c : NavierStokes-V1.1/HyperClaw-V1.1</div>
<div> ! : c : Numbers of fields = n</div><div> ! n: i : Field Names</div><div> ! : i : Dimension = dm</div><div> ! : r : Time</div><div> ! : i : Number of Levels - 1 : nl</div><div> ! : r : Physical domain lo end [1:dm]</div>
<div> ! : r : Physical domain hi end [1:dm]</div><div> ! : i : Refinement Ratios [1:nl-1]</div><div> ! : b : Prob domains per level [1:nl]</div><div> ! : i : unused [1:nl]</div><div> ! nl: r : grid spacing, per level, [1:dm]</div>
<div> ! : i : unused :</div><div> ! : i : unused</div><div> ! For each level</div><div> ! [</div><div> ! : iiri : dummy, nboxes, dummy, dummy</div><div> ! For each box, j</div>
<div> ! [</div><div> ! : r : plo[1:dm,j], phi[1:dm, j]</div><div> ! ]</div><div> ! : c : level directory</div><div> ! ]</div><div> ! Close Header File</div><div> ! For each level</div>
<div> ! [</div><div> ! Open Header of sub-directory</div><div> ! : iiii: dummy, dummy, ncomponents, dummy</div><div> ! : i ; '(', nboxes dummy</div><div> ! For each box, j</div>
<div> ! [</div><div> ! : b : bx[j]</div><div> ! ]</div><div> ! : : ')'</div><div> ! For each box, j</div><div> ! [</div><div> ! : ci : 'FabOnDisk: ' Filename[j], Offset[j]</div>
<div> ! ]</div><div> ! : i : nboxes, ncomponents</div><div> ! For each box, j</div><div> ! [</div><div> ! : r : min[j]</div><div> ! ]</div><div> ! : i : nboxes, ncomponents</div>
<div> ! For each box, j</div><div> ! [</div><div> ! : r : man[j]</div><div> ! ]</div><div> ! Close subgrid file</div><div> ! ]</div><div><br></div></div></div><div class="gmail_extra">
<br><br><div class="gmail_quote">On Thu, May 16, 2013 at 2:56 PM, 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">
Thanks, everybody!<br>
<br>
On Thu, May 16, 2013 at 2:55 PM, Michael Zingale<br>
<div class="HOEnZb"><div class="h5"><<a href="mailto:michael.zingale@stonybrook.edu">michael.zingale@stonybrook.edu</a>> wrote:<br>
> just to be clear, that is the number of MPI tasks, not the number of<br>
> processors (# pros = # MPI * OMP_NUM_THREADS)<br>
><br>
> I just looked at a big run I did for a paper on > 10,000 cores, and there is<br>
> just a single line:<br>
><br>
> Level_00/Cell<br>
><br>
><br>
><br>
> On Thu, May 16, 2013 at 2:52 PM, Matthew Turk <<a href="mailto:matthewturk@gmail.com">matthewturk@gmail.com</a>> wrote:<br>
>><br>
>> On Thu, May 16, 2013 at 2:47 PM, Chris Malone <<a href="mailto:chris.m.malone@gmail.com">chris.m.malone@gmail.com</a>><br>
>> wrote:<br>
>> > Yes, the comoving bit is not in the Castro anymore - or at least no one<br>
>> > uses<br>
>> > it that I'm aware of.<br>
>> ><br>
>> > The number of Level_*/Cell_D_* files for each level is actually based on<br>
>> > the<br>
>> > number of processors set to do IO. This can be changed with a runtime<br>
>> > parameter; Maestro also does this. The simple problems for which you<br>
>> > have<br>
>> > Castro data (like the one I just uploaded to dickenson) were run on a<br>
>> > single<br>
>> > core, so there is only one Cell_D file per level.<br>
>><br>
>> The number of processors is also in the Cell_H file on the third line,<br>
>> to my understanding of the format. But I think I'm still not making<br>
>> myself clear: will there ever be a data file that isn't<br>
>> Cell_Something. Let me give an example. In RadTube's global Header<br>
>> file we have:<br>
>><br>
>> 0 8 7.26154130223839759212753081768e-07<br>
>> 500<br>
>> 0 16<br>
>> 0 16<br>
>> 0 16<br>
>> 112 128<br>
>> 0 16<br>
>> 0 16<br>
>> 96 112<br>
>> 0 16<br>
>> 0 16<br>
>> 80 96<br>
>> 0 16<br>
>> 0 16<br>
>> 64 80<br>
>> 0 16<br>
>> 0 16<br>
>> 48 64<br>
>> 0 16<br>
>> 0 16<br>
>> 32 48<br>
>> 0 16<br>
>> 0 16<br>
>> 16 32<br>
>> 0 16<br>
>> 0 16<br>
>> Level_0/Cell<br>
>> 1 36 7.26154130223839970970989895344e-07<br>
>><br>
>> I am currently parsing this by getting each lo/hi/dimension pair, then<br>
>> assuming there is a *single* line following the set that describes the<br>
>> prefix for the level header, in this case Level_0/Cell , which is then<br>
>> followed by the *next level*. The original frontend code was much<br>
>> more lenient, and in fact allowed for *multiple* filenames to be<br>
>> displayed there -- for instance, it would allow something like:<br>
>><br>
>> Level_0/Cell<br>
>> Level_0/Dinosaurs<br>
>> Level_0/BlahBlah<br>
>><br>
>> where it expects Level_0/Dinosaurs_H and Level_0/BlahBlah_H as well as<br>
>> their corresponding processor files. *Is this real* or can I just<br>
>> assume there will only be one type of data file, in this case<br>
>> Level_0/Cell and its corresponding data?<br>
>><br>
>> ><br>
>> > Chris<br>
>> ><br>
>> ><br>
>> ><br>
>> > On Thu, May 16, 2013 at 11:38 AM, Casey W. Stark <<a href="mailto:caseywstark@gmail.com">caseywstark@gmail.com</a>><br>
>> > wrote:<br>
>> >><br>
>> >> Hi Matt.<br>
>> >><br>
>> >> I think castro.use_comoving was removed once Nyx was ripped out.<br>
>> >><br>
>> >> It sounds like there are more inconsistencies... Nyx datasets always<br>
>> >> have<br>
>> >> the structure plt%05i/Level_%i, then in each level directory, the<br>
>> >> Cell_H<br>
>> >> file and 64 data files Cell_D_%04d from 0000 to 0063.<br>
>> >><br>
>> >><br>
>> >> On Thu, May 16, 2013 at 11:29 AM, Matthew Turk <<a href="mailto:matthewturk@gmail.com">matthewturk@gmail.com</a>><br>
>> >> wrote:<br>
>> >>><br>
>> >>> On Thu, May 16, 2013 at 10:06 AM, Michael Zingale<br>
>> >>> <<a href="mailto:michael.zingale@stonybrook.edu">michael.zingale@stonybrook.edu</a>> wrote:<br>
>> >>> > Yes, that is correct.<br>
>> >>> ><br>
>> >>> > Also, orion is C++ Box lib, not Fortran.<br>
>> >>><br>
>> >>> Oops, thanks.<br>
>> >>><br>
>> >>> ><br>
>> >>> > Finally, because of how C++ boxlib works, it isn't easy to store<br>
>> >>> > runtime<br>
>> >>> > parameters if the default was unchanged. In Fortran box lib, a<br>
>> >>> > python<br>
>> >>> > script parses parameter files and writes f90 code at compile time,<br>
>> >>> > making it<br>
>> >>> > easy.<br>
>> >>><br>
>> >>> Ah, okay, great. That is helpful, and something we can do.<br>
>> >>><br>
>> >>> ><br>
>> >>> > So for Castro and Nyx, if you tell me exactly what info you might<br>
>> >>> > need<br>
>> >>> > from<br>
>> >>> > the runtime paramters, I can add a section to job_info that provides<br>
>> >>> > the<br>
>> >>> > info<br>
>> >>><br>
>> >>> I will look into this, but I think right now it comes down to:<br>
>> >>><br>
>> >>> amr.n_cell (We might be able to get this in the Header?)<br>
>> >>> amr.ref_ratio (which I think we can get elsewhere?)<br>
>> >>> Prob.lo_bc<br>
>> >>> castro.use_comoving<br>
>> >>> comoving_OmL<br>
>> >>> comoving_OmM<br>
>> >>> comoving_h<br>
>> >>> comoving_a (Which is currently in a different file)<br>
>> >>><br>
>> >>> One thing I'm also wondering about is looking at the Header file, it<br>
>> >>> seems that all of the examples I have only have a single data file for<br>
>> >>> each level, of the form:<br>
>> >>><br>
>> >>> Level_*/Cell<br>
>> >>><br>
>> >>> with a corresponding Cell_H that contains the necessary header info.<br>
>> >>> Is this how it always is -- as in, only one data file per Header? Is<br>
>> >>> there a way to read, from the header, how many types of data files<br>
>> >>> there will be? It would make things considerably easier if I knew how<br>
>> >>> many types of data files.<br>
>> >>><br>
>> >>> ><br>
>> >>> > On May 16, 2013 9:53 AM, "Matthew Turk" <<a href="mailto:matthewturk@gmail.com">matthewturk@gmail.com</a>><br>
>> >>> > wrote:<br>
>> >>> >><br>
>> >>> >> As a quick followup, I have noticed that in many cases we default<br>
>> >>> >> to<br>
>> >>> >> using the "inputs" values over the values in the Header file. For<br>
>> >>> >> instance, the domain edges and the index space. I'd rather use the<br>
>> >>> >> Header file since it's a fundamental component, whereas the inputs<br>
>> >>> >> should not strictly be necessary to orient the data, if I<br>
>> >>> >> understand<br>
>> >>> >> Boxlib correctly.<br>
>> >>> >><br>
>> >>> >> On Thu, May 16, 2013 at 9:18 AM, Matthew Turk<br>
>> >>> >> <<a href="mailto:matthewturk@gmail.com">matthewturk@gmail.com</a>><br>
>> >>> >> wrote:<br>
>> >>> >> > Hi all,<br>
>> >>> >> ><br>
>> >>> >> > Okay, from reading this I think I see a few things to address:<br>
>> >>> >> ><br>
>> >>> >> > * We should certainly ensure that the Fortran/C++ frontends both<br>
>> >>> >> > work. I believe -- but may be wrong -- that Maestro and Orion<br>
>> >>> >> > are<br>
>> >>> >> > the<br>
>> >>> >> > "Boxlib Fortran" frontends, and Nyx and Castro are the "Boxlib<br>
>> >>> >> > C++"<br>
>> >>> >> > frontends. The differences seem to be in how level files are<br>
>> >>> >> > stored<br>
>> >>> >> > and a bit about the parameters.<br>
>> >>> >> > * A clear message: make as many of the inputs files optional as<br>
>> >>> >> > possible, and once the job_info changes have been deployed, that<br>
>> >>> >> > will<br>
>> >>> >> > only leave Orion without job_info.<br>
>> >>> >> > * Particles should be delegated to subclasses.<br>
>> >>> >> > * Almost none of the Enzo-isms are necessary anymore, and we can<br>
>> >>> >> > work<br>
>> >>> >> > around the gamma/refine_by stuff.<br>
>> >>> >> > * Get rid of paranoia mode<br>
>> >>> >> > * Put off changes to the Pluto/Chombo frontends<br>
>> >>> >> ><br>
>> >>> >> > For what it's worth, I've gotten a "boxlib" frontend that can<br>
>> >>> >> > load<br>
>> >>> >> > up<br>
>> >>> >> > the example Orion data as well as a Maestro dataset that Mike<br>
>> >>> >> > provided<br>
>> >>> >> > me. The biggest issue was with the fortran-formatted numbers we<br>
>> >>> >> > corrected for previously, but I think I've got a workaround.<br>
>> >>> >> ><br>
>> >>> >> > In digging through the code I also found a number of routines<br>
>> >>> >> > that<br>
>> >>> >> > have been largely unchanged since their first implementation some<br>
>> >>> >> > years ago, which I'm going to try to clean up.<br>
>> >>> >> ><br>
>> >>> >> > Thanks everyone. I've been using the bookmark "boxlib" in my<br>
>> >>> >> > repo<br>
>> >>> >> > at<br>
>> >>> >> > <a href="https://bitbucket.org/MatthewTurk/yt" target="_blank">https://bitbucket.org/MatthewTurk/yt</a> .<br>
>> >>> >> ><br>
>> >>> >> > -Matt<br>
>> >>> >> ><br>
>> >>> >> ><br>
>> >>> >> ><br>
>> >>> >> > On Wed, May 15, 2013 at 8:36 PM, Michael Zingale<br>
>> >>> >> > <<a href="mailto:michael.zingale@stonybrook.edu">michael.zingale@stonybrook.edu</a>> wrote:<br>
>> >>> >> >> Maestro particles are also their own thing, and we shouldn't<br>
>> >>> >> >> worry<br>
>> >>> >> >> about<br>
>> >>> >> >> them. We use them for postprocessing, and not really<br>
>> >>> >> >> visualization.<br>
>> >>> >> >><br>
>> >>> >> >> Looking in BoxLib, it is the case that the F90 BoxLib<br>
>> >>> >> >> (Src/F_BaseLib/fabio.f90) specifies Level_XX instead of Level_X<br>
>> >>> >> >> names<br>
>> >>> >> >> for<br>
>> >>> >> >> the directory.<br>
>> >>> >> >><br>
>> >>> >> >><br>
>> >>> >> >> On Wed, May 15, 2013 at 7:30 PM, Andrew Myers<br>
>> >>> >> >> <<a href="mailto:atmyers2@gmail.com">atmyers2@gmail.com</a>><br>
>> >>> >> >> wrote:<br>
>> >>> >> >>><br>
>> >>> >> >>> Hi Folks,<br>
>> >>> >> >>><br>
>> >>> >> >>> The Orion particles are completely independent of BoxLib. I<br>
>> >>> >> >>> don't<br>
>> >>> >> >>> know<br>
>> >>> >> >>> if<br>
>> >>> >> >>> new BoxLib specifies a way for particle data to be stored, or<br>
>> >>> >> >>> if<br>
>> >>> >> >>> all<br>
>> >>> >> >>> the<br>
>> >>> >> >>> 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<br>
>> >>> >> >>> particle<br>
>> >>> >> >>> readers<br>
>> >>> >> >>> get implemented in each subclass, or<br>
>> >>> >> >>> 2. The base class should implement the Nyx-style particles and<br>
>> >>> >> >>> the<br>
>> >>> >> >>> Orion<br>
>> >>> >> >>> subclass should overwrite this.<br>
>> >>> >> >>><br>
>> >>> >> >>> Matt, on your specific questions:<br>
>> >>> >> >>><br>
>> >>> >> >>><br>
>> >>> >> >>> * Is it okay to get rid of the old enzo parameter mappings?<br>
>> >>> >> >>><br>
>> >>> >> >>> If I'm reading the code correctly, this is currently needed for<br>
>> >>> >> >>> "Gamma"<br>
>> >>> >> >>> and "Refineby" to get set correctly, but nothing else.<br>
>> >>> >> >>><br>
>> >>> >> >>> * Do we need to have all of the paranoid IO still?<br>
>> >>> >> >>><br>
>> >>> >> >>> I'm not 100% sure what this does, but currently paranoid_read<br>
>> >>> >> >>> is<br>
>> >>> >> >>> False<br>
>> >>> >> >>> by<br>
>> >>> >> >>> default and I've never noticed a problem with that.<br>
>> >>> >> >>><br>
>> >>> >> >>> * Do you mind if I reword some of the names?<br>
>> >>> >> >>><br>
>> >>> >> >>> Not at all.<br>
>> >>> >> >>><br>
>> >>> >> >>> -Andrew<br>
>> >>> >> >>><br>
>> >>> >> >>> On Wed, May 15, 2013 at 3:32 PM, Casey W. Stark<br>
>> >>> >> >>> <<a href="mailto:caseywstark@gmail.com">caseywstark@gmail.com</a>><br>
>> >>> >> >>> wrote:<br>
>> >>> >> >>>><br>
>> >>> >> >>>> Hi Matt.<br>
>> >>> >> >>>><br>
>> >>> >> >>>> That all sounds right.<br>
>> >>> >> >>>><br>
>> >>> >> >>>> Really unifying the BoxLib codes sounds like tricky business<br>
>> >>> >> >>>> to<br>
>> >>> >> >>>> me. I<br>
>> >>> >> >>>> think the current boxlib codes castro, maestro, and nyx will<br>
>> >>> >> >>>> be<br>
>> >>> >> >>>> using<br>
>> >>> >> >>>> basically the same versions of boxlib, but orion could be<br>
>> >>> >> >>>> different<br>
>> >>> >> >>>> altogether. I haven't seen the code, so I can't say, but I bet<br>
>> >>> >> >>>> this<br>
>> >>> >> >>>> is the<br>
>> >>> >> >>>> reason for the particle difference.<br>
>> >>> >> >>>><br>
>> >>> >> >>>> > * Castro was originally going to be a frontend<br>
>> >>> >> >>>><br>
>> >>> >> >>>> Nyx was originally part of Castro, but we ripped it out around<br>
>> >>> >> >>>> the<br>
>> >>> >> >>>> same<br>
>> >>> >> >>>> time. Is anyone using yt with Castro data now?<br>
>> >>> >> >>>><br>
>> >>> >> >>>> > * Some weird differences like Level_%i and Level_%02i for<br>
>> >>> >> >>>> > level<br>
>> >>> >> >>>> > filenames.<br>
>> >>> >> >>>><br>
>> >>> >> >>>> Hm, I don't know about this one since we never use more than a<br>
>> >>> >> >>>> few<br>
>> >>> >> >>>> levels, and that's rare.<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>
>> >>> >> >>>><br>
>> >>> >> >>>> I'm not sure what these were for... If things like parameter<br>
>> >>> >> >>>> names<br>
>> >>> >> >>>> are<br>
>> >>> >> >>>> fine without the remapping, then great. The IO seems fine, so<br>
>> >>> >> >>>> I<br>
>> >>> >> >>>> doubt<br>
>> >>> >> >>>> we<br>
>> >>> >> >>>> need a paranoid option.<br>
>> >>> >> >>>><br>
>> >>> >> >>>> > * Do you mind if I reword some of the names?<br>
>> >>> >> >>>><br>
>> >>> >> >>>> Go for it.<br>
>> >>> >> >>>><br>
>> >>> >> >>>><br>
>> >>> >> >>>><br>
>> >>> >> >>>> On Wed, May 15, 2013 at 11:50 AM, Matthew Turk<br>
>> >>> >> >>>> <<a href="mailto:matthewturk@gmail.com">matthewturk@gmail.com</a>><br>
>> >>> >> >>>> wrote:<br>
>> >>> >> >>>>><br>
>> >>> >> >>>>> Hi all,<br>
>> >>> >> >>>>><br>
>> >>> >> >>>>> I'm spending a bit of time today looking over the Boxlib<br>
>> >>> >> >>>>> frontends<br>
>> >>> >> >>>>> and<br>
>> >>> >> >>>>> identifying commonalities and differences. I wanted to write<br>
>> >>> >> >>>>> with<br>
>> >>> >> >>>>> some of my initial findings as well as some specific<br>
>> >>> >> >>>>> questions.<br>
>> >>> >> >>>>><br>
>> >>> >> >>>>> Casey, Andrew, and Jeff I would particularly like your<br>
>> >>> >> >>>>> feedback,<br>
>> >>> >> >>>>> but<br>
>> >>> >> >>>>> I<br>
>> >>> >> >>>>> also intend to submit this for detailed review and<br>
>> >>> >> >>>>> collaboration.<br>
>> >>> >> >>>>> My<br>
>> >>> >> >>>>> general plan is to consolidate the data_structures, IO and<br>
>> >>> >> >>>>> definitions<br>
>> >>> >> >>>>> into a single Boxlib frontend, with subclasses that cover<br>
>> >>> >> >>>>> each<br>
>> >>> >> >>>>> of<br>
>> >>> >> >>>>> the<br>
>> >>> >> >>>>> specific differences.<br>
>> >>> >> >>>>><br>
>> >>> >> >>>>> The main differences I am seeing:<br>
>> >>> >> >>>>><br>
>> >>> >> >>>>> * Castro was originally going to be a frontend, but morphed<br>
>> >>> >> >>>>> into<br>
>> >>> >> >>>>> the<br>
>> >>> >> >>>>> Nyx frontend, and I don't believe anything Castro-specific is<br>
>> >>> >> >>>>> left<br>
>> >>> >> >>>>> anymore. I am inclined to remove it and in the future add on<br>
>> >>> >> >>>>> 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<br>
>> >>> >> >>>>> should<br>
>> >>> >> >>>>> use<br>
>> >>> >> >>>>> everywhere.<br>
>> >>> >> >>>>> * Some weird differences like Level_%i and Level_%02i for<br>
>> >>> >> >>>>> level<br>
>> >>> >> >>>>> filenames.<br>
>> >>> >> >>>>> * Units will need to be set individually.<br>
>> >>> >> >>>>> * Parsing the Fortran and non-Fortran parameter files (i.e.,<br>
>> >>> >> >>>>> 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<br>
>> >>> >> >>>>> in<br>
>> >>> >> >>>>> IRC<br>
>> >>> >> >>>>> working on this for a while today, but I'll also try to<br>
>> >>> >> >>>>> submit a<br>
>> >>> >> >>>>> PR<br>
>> >>> >> >>>>> 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">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>
>> >>> >> >>>><br>
>> >>> >> >>>><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>
>> >>> >> >>><br>
>> >>> >> >><br>
>> >>> >> >><br>
>> >>> >> >><br>
>> >>> >> >> --<br>
>> >>> >> >> Michael Zingale<br>
>> >>> >> >> Associate Professor<br>
>> >>> >> >><br>
>> >>> >> >> Dept. of Physics & Astronomy • Stony Brook University • Stony<br>
>> >>> >> >> Brook, NY<br>
>> >>> >> >> 11794-3800<br>
>> >>> >> >> phone: <a href="tel:631-632-8225" value="+16316328225">631-632-8225</a><br>
>> >>> >> >> e-mail: <a href="mailto:Michael.Zingale@stonybrook.edu">Michael.Zingale@stonybrook.edu</a><br>
>> >>> >> >> web: <a href="http://www.astro.sunysb.edu/mzingale" target="_blank">http://www.astro.sunysb.edu/mzingale</a><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>
>> >><br>
>> >><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>
>> ><br>
>> ><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>
><br>
><br>
><br>
><br>
> --<br>
> Michael Zingale<br>
> Associate Professor<br>
><br>
> Dept. of Physics & Astronomy • Stony Brook University • Stony Brook, NY<br>
> 11794-3800<br>
> phone: <a href="tel:631-632-8225" value="+16316328225">631-632-8225</a><br>
> e-mail: <a href="mailto:Michael.Zingale@stonybrook.edu">Michael.Zingale@stonybrook.edu</a><br>
> web: <a href="http://www.astro.sunysb.edu/mzingale" target="_blank">http://www.astro.sunysb.edu/mzingale</a><br>
</div></div></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>