<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>Sounds good to me as well. I may be a bit late as I will be getting back from lunch.</div><br><div>
<span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; "><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: medium; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; "><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: medium; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; "><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: medium; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; "><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Nathan Goldbaum<br>Graduate Student<br>Astronomy & Astrophysics, UCSC<br><a href="mailto:goldbaum@ucolick.org">goldbaum@ucolick.org</a><br>http://www.ucolick.org/~goldbaum</div></span></div></span></div></span></span>
</div>
<br><div><div>On Apr 2, 2012, at 10:54 AM, Casey W. Stark wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">Sounds good.<br><br><div class="gmail_quote">On Mon, Apr 2, 2012 at 10:47 AM, Matthew Turk <span dir="ltr"><<a href="mailto:matthewturk@gmail.com">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 Casey,<br>
<div class="im"><br>
On Mon, Apr 2, 2012 at 1:01 PM, Casey W. Stark <<a href="mailto:caseywstark@gmail.com">caseywstark@gmail.com</a>> wrote:<br>
> I think I forgot to reply -- Tuesday works for me and Wednesday is good<br>
> before 11 or after 12:30 Pacific.<br>
><br>
> We can sort this out during the hangout, but which issue are we focusing on?<br>
> Is this more for the units system, renaming fields in the 3.0 branch, or the<br>
> dataset change? (or maybe something else that was mentioned, there were a<br>
> lot)<br>
<br>
</div>How about 1:00PM pacific on Wednesday? And I was thinking we'd work<br>
in yt-refactor and change up the fields.<br>
<br>
-Matt<br>
<div class="HOEnZb"><div class="h5"><br>
><br>
> Best,<br>
> Casey<br>
><br>
><br>
> On Fri, Mar 30, 2012 at 12:59 PM, Matthew Turk <<a href="mailto:matthewturk@gmail.com">matthewturk@gmail.com</a>><br>
> wrote:<br>
>><br>
>> On Fri, Mar 30, 2012 at 1:22 PM, Nathan Goldbaum <<a href="mailto:goldbaum@ucolick.org">goldbaum@ucolick.org</a>><br>
>> wrote:<br>
>> >> 1) Get rid of accessing parameters with an implicit __getitem__ on the<br>
>> >> parameter file (i.e., pf["SomethingThatOnlyExistsInOneCode"]). I'm<br>
>> >> +10 on this.<br>
>> >> 2) Move units into the .units object (I'm mostly with Casey on this,<br>
>> >> but I think it should be a part of the field_info object)<br>
>> >> 3) Have things like current_time, domain_dimensions and so on move<br>
>> >> into basic_info and make them dict objects.<br>
>> >><br>
>> >> I think of those, I'm in favor of one and two, but somewhat opposed to<br>
>> >> #3. Right now we have these attributes mandated for subclasses of<br>
>> >> StaticOutput:<br>
>> ><br>
>> > I'd say #3 is the least important. I'd be fine with the dataset object<br>
>> > having some non-dict attributes that describe the nature of the dataset<br>
>> > rather than storing them all in a basic_info dict. One thing to think<br>
>> > about: if we want to support pure-particle datasets, then we should drop the<br>
>> > notion of refine_by as a basic dataset attribute.<br>
>><br>
>> I think whether refine_by sticks around depends on how we end up<br>
>> wanting to address fluid quantities in particle datasets. One<br>
>> possibility for handling SPH data is to grid it, and while I don't<br>
>> want to lock us into that (myopic at best) I don't want to exclude it<br>
>> as an ultimate possibility. But yes, in general, I agree. As I have<br>
>> been working on the geometry refactor, the number of times refine_by<br>
>> is access has been going down, as for the most part it relies on (for<br>
>> instance) the projection code knowing how to handle data from grids,<br>
>> which has been pshed back onto the grids instead. Now projections<br>
>> simply receive data that is ordered spatially, and that data is<br>
>> appropriately added.<br>
>><br>
>> ><br>
>> >> With the geometry_refactor, I'd like to consolidate functionality into<br>
>> >> the main "dataset" object. The geometry can still provide access to<br>
>> >> the individual grids (of course) but data objects, finding max,<br>
>> >> getting stats about the simulation, etc, should all go into the main<br>
>> >> dataset object, and the geometry handler can simply be created on the<br>
>> >> fly if necessary.<br>
>> ><br>
>> > Why not get access to objects through a geometry attribute that hangs<br>
>> > off of the dataset object. If I wanted to instantiate a sphere object, I<br>
>> > would just do:<br>
>> ><br>
>> > sp = ds.geometry.sphere()<br>
>> ><br>
>> > This is pretty much the same as the pf.h.sphere() syntax in place right<br>
>> > now but allows for arbitrary selection embedded inside of the new geometry<br>
>> > code.<br>
>><br>
>> That's how I was implementing it. I just wasn't sure this was as<br>
>> clean. Having the plots then hang off the geometry feels a little<br>
>> funny.<br>
>><br>
>> Also, I don't think I explicitly commented on Casey's hangout<br>
>> suggestion -- I am in favor. Could we do Tuesday afternoon (late<br>
>> morning CA time) or Wednesday same?<br>
>><br>
>> -Matt<br>
>><br>
>> ><br>
>> > Nathan Goldbaum<br>
>> > Graduate Student<br>
>> > Astronomy & Astrophysics, UCSC<br>
>> > <a href="mailto:goldbaum@ucolick.org">goldbaum@ucolick.org</a><br>
>> > <a href="http://www.ucolick.org/~goldbaum" target="_blank">http://www.ucolick.org/~goldbaum</a><br>
>> ><br>
>> > On Mar 30, 2012, at 3:48 AM, Matthew Turk wrote:<br>
>> ><br>
>> >> In general, I agree with the idea Nathan put out. (Also, I think this<br>
>> >> is a fine time to have a bikeshed discussion. Many of the underlying<br>
>> >> assumptions about how yt works were laid out a long time ago.) But,<br>
>> >> I'm not entirely sure I understand how different it would be --<br>
>> >> conceptually, yes, I see what you're getting at, that we'd have a set<br>
>> >> number of attributes. In what I was thinking of for the geometry<br>
>> >> refactor so far I'm trying to get rid of the "hierarchy" as existing<br>
>> >> for every data set, and instead relying on what amounts to an<br>
>> >> object-finder and io-coordinator, which I'm calling a geometry<br>
>> >> handler. It sounds like what you would like is:<br>
>> >><br>
>> >> 1) Get rid of accessing parameters with an implicit __getitem__ on the<br>
>> >> parameter file (i.e., pf["SomethingThatOnlyExistsInOneCode"]). I'm<br>
>> >> +10 on this.<br>
>> >> 2) Move units into the .units object (I'm mostly with Casey on this,<br>
>> >> but I think it should be a part of the field_info object)<br>
>> >> 3) Have things like current_time, domain_dimensions and so on move<br>
>> >> into basic_info and make them dict objects.<br>
>> >><br>
>> >> I think of those, I'm in favor of one and two, but somewhat opposed to<br>
>> >> #3. Right now we have these attributes mandated for subclasses of<br>
>> >> StaticOutput:<br>
>> >><br>
>> >> refine_by<br>
>> >> dimensionality<br>
>> >> current_time<br>
>> >> domain_dimensions<br>
>> >> domain_left_edge<br>
>> >> domain_right_edge<br>
>> >> unique_identifier<br>
>> >> current_redshift<br>
>> >> cosmological_simulation<br>
>> >> omega_matter<br>
>> >> omega_lambda<br>
>> >> hubble_constant<br>
>> >><br>
>> >> The only ones here that I think would be okay to move out of<br>
>> >> properties would be the cosmology items, and even those I'm -0 on<br>
>> >> moving.<br>
>> >><br>
>> >> But, in general, the idea of moving from this two-stage system of<br>
>> >> parameter file (rather than dataset) and hierarchy (rather than an<br>
>> >> implicitly-handled geometry) is something I am in support of. The<br>
>> >> geometry is something that should nearly *always* be handled by the<br>
>> >> backend, rather than by the user. So having the library require<br>
>> >> pf.h.sphere(...) is less than ideal, since it's exposing something<br>
>> >> relatively unfortunate (that building a hundred thousand grid objects<br>
>> >> can take some time).<br>
>> >><br>
>> >> The main ways that the static output is interacted with:<br>
>> >><br>
>> >> * Parameter information specific to a simulation code<br>
>> >> * Properties that yt needs to know about<br>
>> >> * To get at the hierarchy<br>
>> >> * Input to plot collections<br>
>> >><br>
>> >> The main ways that the hierarchy is interacted with:<br>
>> >><br>
>> >> * Getting data objects<br>
>> >> * Finding max<br>
>> >> * Statistics about the simulation<br>
>> >> * Inspecting individual grids (much less common use case now that it<br>
>> >> was before)<br>
>> >><br>
>> >> All of these use cases are still valid, but I think it's clear that<br>
>> >> accessing individual grids and accessing simulation-specific<br>
>> >> parameters are not "generic" functions. What a lot of this discussion<br>
>> >> has really brought up for me is that we're talking about *generic*<br>
>> >> functionality, not code-specific functionality, and we right now do<br>
>> >> not have the best enumeration of functionality and where it lies.<br>
>> >><br>
>> >> With the geometry_refactor, I'd like to consolidate functionality into<br>
>> >> the main "dataset" object. The geometry can still provide access to<br>
>> >> the individual grids (of course) but data objects, finding max,<br>
>> >> getting stats about the simulation, etc, should all go into the main<br>
>> >> dataset object, and the geometry handler can simply be created on the<br>
>> >> fly if necessary.<br>
>> >><br>
>> >> This brings up two points, though --<br>
>> >><br>
>> >> 1) Does our method of instantiating objects still hold up? i.e.,<br>
>> >> ds.sphere(...) and so on? Or does our dataset object then become<br>
>> >> overcrowded? I would also like to move *all* plotting objects into<br>
>> >> whatever we end up deciding is the location data containers come from,<br>
>> >> which for instance could look like ds.plot("slice", "x") (for<br>
>> >> instance, although we can bikeshed that later), which would return a<br>
>> >> plot window.<br>
>> >> 2) Datasets and time series should behave, if not identically, at<br>
>> >> least consistently in their APIs. Moving to a completely ds-mediated<br>
>> >> mechanism for generating, accessing and inspecting data opens up the<br>
>> >> ability to then construct very nice and simply proxy objects. As an<br>
>> >> example, while something this is currently technically possible with<br>
>> >> the current Time Series API, it's a bit tricky:<br>
>> >><br>
>> >> ts = TimeSeriesData.from_filenames(...)<br>
>> >> plot = ts.plot("slice", "x", (100.0, 'au'))<br>
>> >> ts.seek(dt = (100, 'years'))<br>
>> >> plot.save()<br>
>> >> ts.seek(dt = (10, 'years'))<br>
>> >> plot.save()<br>
>> >><br>
>> >> (The time-slider, as Tom likes to call it ...)<br>
>> >><br>
>> >> In general, this idea of moving toward more thoughtful<br>
>> >> dataset-construction, rather than the hokey parameter file + hierarchy<br>
>> >> construction brings with it a mindset shift which I'd like to spread<br>
>> >> to the time series, which can continue to be a focus.<br>
>> >><br>
>> >> What do you think?<br>
>> >><br>
>> >> -Matt<br>
>> >><br>
>> >> On Thu, Mar 29, 2012 at 7:08 PM, Casey W. Stark <<a href="mailto:caseywstark@gmail.com">caseywstark@gmail.com</a>><br>
>> >> wrote:<br>
>> >>> +1 on datasets, although I would like to see the unit object(s) at the<br>
>> >>> field<br>
>> >>> level.<br>
>> >>><br>
>> >>><br>
>> >>> On Thu, Mar 29, 2012 at 4:04 PM, Cameron Hummels<br>
>> >>> <<a href="mailto:chummels@astro.columbia.edu">chummels@astro.columbia.edu</a>> wrote:<br>
>> >>>><br>
>> >>>> +1 on datasets.<br>
>> >>>><br>
>> >>>><br>
>> >>>> On 3/29/12 6:58 PM, Nathan Goldbaum wrote:<br>
>> >>>>><br>
>> >>>>> +1. I'd also be up to help out with the sprint. Doing a virtual<br>
>> >>>>> sprint<br>
>> >>>>> using a google hangout might help mitigate some of the distance<br>
>> >>>>> problems.<br>
>> >>>>><br>
>> >>>>> While we're brining up Enzo-isms that we should get rid of, I think<br>
>> >>>>> it<br>
>> >>>>> might be a good idea to make a conceptual shift in the basic python<br>
>> >>>>> UI.<br>
>> >>>>> Instead referring to the interface between the user and the data as<br>
>> >>>>> a<br>
>> >>>>> parameter file, I think instead we should be talking about datasets.<br>
>> >>>>> One<br>
>> >>>>> would instantiate a dataset just like we do now with parameter<br>
>> >>>>> files:<br>
>> >>>>><br>
>> >>>>> ds = load(filename)<br>
>> >>>>><br>
>> >>>>> A dataset would also have some universal attributes which would<br>
>> >>>>> present<br>
>> >>>>> themselves to the user as a dict, e.g. ds.units, ds.parameters,<br>
>> >>>>> ds.basic_info (like current_time, timestep, filename, and simulation<br>
>> >>>>> code),<br>
>> >>>>> and ds.hierarchy (not sure how that would interfere with the<br>
>> >>>>> geometry<br>
>> >>>>> refactor).<br>
>> >>>>><br>
>> >>>>> This may be a paintibg the bike shed discussion, but I think this<br>
>> >>>>> shift<br>
>> >>>>> will help new users understand how to access their data. Thoughts?<br>
>> >>>>><br>
>> >>>>> On Mar 29, 2012, at 3:40 PM, Matthew Turk<<a href="mailto:matthewturk@gmail.com">matthewturk@gmail.com</a>><br>
>> >>>>> wrote:<br>
>> >>>>><br>
>> >>>>>> Hi Nathan and Casey,<br>
>> >>>>>><br>
>> >>>>>> I agree with what both of you have said. The Orion/Nyx units<br>
>> >>>>>> should<br>
>> >>>>>> be made to be consistent, but more importantly I think we should<br>
>> >>>>>> continue breaking away from Enzo-isms in the code.<br>
>> >>>>>><br>
>> >>>>>> As it stands, all of the universal fields call underlying<br>
>> >>>>>> Enzo-named<br>
>> >>>>>> aliases -- Density, ThermalEnergy, etc etc. I hope we can have a<br>
>> >>>>>> 3.0<br>
>> >>>>>> out within a calendar year, hopefully by the end of this year.<br>
>> >>>>>> (I've<br>
>> >>>>>> been pushing on the geometry refactor, although recently other<br>
>> >>>>>> efforts<br>
>> >>>>>> have been paying off which has decreased my output there.) I am<br>
>> >>>>>> much,<br>
>> >>>>>> much less doubtful than Casey is that we cannot do this; in fact,<br>
>> >>>>>> I'm<br>
>> >>>>>> completely in favor of this and I think it would be relatively<br>
>> >>>>>> straightforward to implement.<br>
>> >>>>>><br>
>> >>>>>> In the existing system we have a mechanism for aliasing fields.<br>
>> >>>>>> What<br>
>> >>>>>> we can do is provide an additional translation system where we<br>
>> >>>>>> enumerate the fields that are available for items in<br>
>> >>>>>> UniversalFields,<br>
>> >>>>>> and then construct aliases to those. This would mean changing what<br>
>> >>>>>> is<br>
>> >>>>>> aliased in existing non-Enzo frontends, and adding aliases in Enzo.<br>
>> >>>>>> The style of name Casey proposes is what I woudl also agree with:<br>
>> >>>>>> underscores, lower cases, and erring on the side of verbosity. The<br>
>> >>>>>> fields off hand that we would need to do this for (in their current<br>
>> >>>>>> enzo-isms):<br>
>> >>>>>><br>
>> >>>>>> x-velocity => velocity_x (same for y, z)<br>
>> >>>>>> Density => density<br>
>> >>>>>> TotalEnergy => ?<br>
>> >>>>>> GasEnergy => thermal_energy_specific (and thermal_energy_density)<br>
>> >>>>>> Temperature => temperature<br>
>> >>>>>><br>
>> >>>>>> and so on.<br>
>> >>>>>><br>
>> >>>>>> Once we have these aliases in place, an overall cleanup of<br>
>> >>>>>> UniversalFields should take place. One place we should clean up is<br>
>> >>>>>> ensuring that there are no conditionals; rather than conditionals<br>
>> >>>>>> inside the functions, we should place those conditionals inside the<br>
>> >>>>>> parameter file types. So for instance, if you have a field that is<br>
>> >>>>>> calculated differently depending on the parameter HydroMethod (in<br>
>> >>>>>> Enzo<br>
>> >>>>>> for instance) you simply set a validator on the field requiring the<br>
>> >>>>>> parameter be set to a particular value, and then only the field<br>
>> >>>>>> which<br>
>> >>>>>> satisfies that validator will be called when requested.<br>
>> >>>>>><br>
>> >>>>>> So we've gotten rid of a bunch of enzo-isms in the parameter files;<br>
>> >>>>>> after fields, what else can we address? And, I'd be up for<br>
>> >>>>>> sprinting<br>
>> >>>>>> on this (which should take just a few hours) basically any time<br>
>> >>>>>> next<br>
>> >>>>>> week or after. I'd also be up for talking more about geometry<br>
>> >>>>>> refactoring, if anyone is interested, but it's not quite to the<br>
>> >>>>>> point<br>
>> >>>>>> that I think I am satisfied enough with the architecture to request<br>
>> >>>>>> input / contributions. Sometimes (especially with big<br>
>> >>>>>> architectural<br>
>> >>>>>> things like this) I think it's a shame we do all of our work<br>
>> >>>>>> virtually, as I think a lot of this would be easier to bang out in<br>
>> >>>>>> person for a couple hours.<br>
>> >>>>>><br>
>> >>>>>> -Matt<br>
>> >>>>>><br>
>> >>>>>> On Wed, Mar 28, 2012 at 6:14 PM, Casey W.<br>
>> >>>>>> Stark<<a href="mailto:caseywstark@gmail.com">caseywstark@gmail.com</a>><br>
>> >>>>>> wrote:<br>
>> >>>>>>><br>
>> >>>>>>> Hi Nathan.<br>
>> >>>>>>><br>
>> >>>>>>> I'm also worried about this and I agree that fields with the same<br>
>> >>>>>>> name<br>
>> >>>>>>> should all be consistent. I would support some sort of cleanup of<br>
>> >>>>>>> frontend<br>
>> >>>>>>> fields, and I can get the Nyx fields in line and help with Enzo.<br>
>> >>>>>>><br>
>> >>>>>>> I doubt we can do this, but I would prefer changing the field<br>
>> >>>>>>> names as<br>
>> >>>>>>> part<br>
>> >>>>>>> of the removing enzo-isms and geometry handling refactoring<br>
>> >>>>>>> pushes. For<br>
>> >>>>>>> instance, the field in Orion could be thermal_energy_density and<br>
>> >>>>>>> the<br>
>> >>>>>>> field<br>
>> >>>>>>> in Enzo could be specific_thermal_energy. I also noticed this<br>
>> >>>>>>> issue<br>
>> >>>>>>> when I<br>
>> >>>>>>> was using "Density" in Enzo (proper density in cgs) and "density"<br>
>> >>>>>>> in<br>
>> >>>>>>> Nyx<br>
>> >>>>>>> (comoving density in cgs).<br>
>> >>>>>>><br>
>> >>>>>>> Best,<br>
>> >>>>>>> Casey<br>
>> >>>>>>><br>
>> >>>>>>><br>
>> >>>>>>> On Wed, Mar 28, 2012 at 1:47 PM, Nathan<br>
>> >>>>>>> Goldbaum<<a href="mailto:goldbaum@ucolick.org">goldbaum@ucolick.org</a>><br>
>> >>>>>>> wrote:<br>
>> >>>>>>>><br>
>> >>>>>>>> Hi all,<br>
>> >>>>>>>><br>
>> >>>>>>>> On IRC today we noticed that Orion defines its ThermalEnergy<br>
>> >>>>>>>> field per<br>
>> >>>>>>>> unit volume but Enzo and FLASH define ThermalEnergy per unit<br>
>> >>>>>>>> mass. Is<br>
>> >>>>>>>> this<br>
>> >>>>>>>> a problem? Since yt defaults to the Enzo field names, should we<br>
>> >>>>>>>> try<br>
>> >>>>>>>> to make<br>
>> >>>>>>>> sure that all fields are defined using the same units as in Enzo?<br>
>> >>>>>>>> Is<br>
>> >>>>>>>> there<br>
>> >>>>>>>> a convention for how different codes should define derived fields<br>
>> >>>>>>>> that<br>
>> >>>>>>>> are<br>
>> >>>>>>>> aliased to Enzo fields?<br>
>> >>>>>>>><br>
>> >>>>>>>> One problem for this particular example is that the Pressure<br>
>> >>>>>>>> field is<br>
>> >>>>>>>> defined in terms of ThermalEnergy in universal_fields.py so the<br>
>> >>>>>>>> units<br>
>> >>>>>>>> of<br>
>> >>>>>>>> ThermalEnergy become important if a user merely wants the gas<br>
>> >>>>>>>> pressure<br>
>> >>>>>>>> in<br>
>> >>>>>>>> the simulation.<br>
>> >>>>>>>><br>
>> >>>>>>>> One possible solution for this issue would be the units overhaul<br>
>> >>>>>>>> we're<br>
>> >>>>>>>> planning. If all fields are associated with a unit object, we can<br>
>> >>>>>>>> simply<br>
>> >>>>>>>> query the units to ensure that units are taken care of correctly<br>
>> >>>>>>>> and<br>
>> >>>>>>>> code-to-code comparisons aren't sensitive to the units chosen for<br>
>> >>>>>>>> fields in<br>
>> >>>>>>>> the frontend.<br>
>> >>>>>>>><br>
>> >>>>>>>> Personally, I think it would be best if we could make sure that<br>
>> >>>>>>>> all of<br>
>> >>>>>>>> the<br>
>> >>>>>>>> fields aliased to Enzo fields have the same units.<br>
>> >>>>>>>><br>
>> >>>>>>>> Nathan Goldbaum<br>
>> >>>>>>>> Graduate Student<br>
>> >>>>>>>> Astronomy& Astrophysics, UCSC<br>
>> >>>>>>>><br>
>> >>>>>>>> <a href="mailto:goldbaum@ucolick.org">goldbaum@ucolick.org</a><br>
>> >>>>>>>> <a href="http://www.ucolick.org/~goldbaum" target="_blank">http://www.ucolick.org/~goldbaum</a><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>
>> >>>>>> 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>
>> >>>> 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>
>> >> 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>
>> > 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>
>> 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>
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>
</div></div></blockquote></div><br>
!DSPAM:10175,4f79e7e715204169418881!
_______________________________________________<br>yt-dev mailing list<br><a href="mailto:yt-dev@lists.spacepope.org">yt-dev@lists.spacepope.org</a><br>http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org<br><br><br>!DSPAM:10175,4f79e7e715204169418881!<br></blockquote></div><br></body></html>