Hi Geoffrey, Stephen, So there isn't currently a comoving density field. I think it can be added like so: def _ComovingDensity(field, data): ef = (1.0 + data.pf["CosmologyCurrentRedshift"])**3.0 return data["Density"]/ef add_field("ComovingDensity", function=_ComovingDensity) it won't need a conversion function because Density is already in CGS. Geoffrey, I think I'd prefer not to have a flag to swap things in and out -- globally turning on "comoving units" would likely end up having to add a lot of machinery to handle all of the comoving conversions. I think it's okay just to give them when requested. (Which, for what it's worth, is what Enzo does in the parameter file output.) -Matt On Sun, Feb 21, 2010 at 3:13 AM, wrote:

Is it possible to leave the default in proper units, but add a new feature using a flag that will set the data in either the co-moving, or proper units?  (or is it much easier for the user to multiply it by the right factors of 1+CurrentRedshift?)

From G.S.

...

Hi all,

I would like to make a phase plot that uses co-moving density, rather than proper density, something like this:

http://yt.enzotools.org/doc/cookbook/recipes.html#simple-phase

do I have to define a new field, or is there a built-in comoving density field (that I can't find)?

Thanks!  _______________________________________________________ sskory@physics.ucsd.edu           o__  Stephen Skory http://physics.ucsd.edu/~sskory/ _.>/ _Graduate Student ________________________________(_)_\(_)_______________

_______________________________________________ yt-users mailing list yt-users@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org

_______________________________________________ yt-users mailing list yt-users@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org

Hi all, I added this to trunk. There's now a "ComovingDensity" and a "Comoving_HI_Density" (for all species, not just HI) field spec. -Matt On Sun, Feb 21, 2010 at 10:00 AM, Britton Smith wrote:

Can we just set up auto field generation for comoving density fields, similar to the way the species fraction fields are set up?  For every density field that exists, we can simply create Something_Density_Comoving, or something similar. Britton

On Sun, Feb 21, 2010 at 11:35 AM, Matthew Turk wrote:

...

Hi Geoffrey, Stephen,

So there isn't currently a comoving density field.  I think it can be added like so:

def _ComovingDensity(field, data):    ef = (1.0 + data.pf["CosmologyCurrentRedshift"])**3.0    return data["Density"]/ef add_field("ComovingDensity", function=_ComovingDensity)

it won't need a conversion function because Density is already in CGS.

Geoffrey, I think I'd prefer not to have a flag to swap things in and out -- globally turning on "comoving units" would likely end up having to add a lot of machinery to handle all of the comoving conversions. I think it's okay just to give them when requested.  (Which, for what it's worth, is what Enzo does in the parameter file output.)

-Matt

On Sun, Feb 21, 2010 at 3:13 AM,   wrote:

...

Is it possible to leave the default in proper units, but add a new feature using a flag that will set the data in either the co-moving, or proper units?  (or is it much easier for the user to multiply it by the right factors of 1+CurrentRedshift?)

From G.S.

...

Hi all,

I would like to make a phase plot that uses co-moving density, rather than proper density, something like this:

http://yt.enzotools.org/doc/cookbook/recipes.html#simple-phase

do I have to define a new field, or is there a built-in comoving density field (that I can't find)?

Thanks!  _______________________________________________________ sskory@physics.ucsd.edu           o__  Stephen Skory http://physics.ucsd.edu/~sskory/ _.>/ _Graduate Student ________________________________(_)_\(_)_______________

_______________________________________________ yt-users mailing list yt-users@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org

_______________________________________________ yt-users mailing list yt-users@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org

_______________________________________________ yt-users mailing list yt-users@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org

_______________________________________________ yt-users mailing list yt-users@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org

Hi Geoffrey, By default, the phase plot takes the average and weighs that average by the mass in a cell. Both of your plots should have "weight=None" in the argument list, so that the total of the third quantity ("CellMassMsun" and "CellVolumeCode", but I think for the second your script must be different than what you copy/pasted) in each bin is displayed, rather than the average. For a unigrid simulation, the average CellVolumeCode will be constant everywhere, and the average Mass will increase with Density, as M = rho * V where V is a constant. -Matt On Tue, Feb 23, 2010 at 1:22 PM, wrote:

When I tried the following: p = pc.add_phase_object(dd, ["Density","IonizationFraction","CellMassMsun"], lazy_reader = True)

this gave me a phase plot of IonizationFraction vs Density, and the z axis colorbar shows a distribution of different masses, but if I used the following:

p = pc.add_phase_object(dd, ["Density","CellVolumeCode","IonizationFraction"], lazy_reader = True)

I get no distribution in the z colorbar at all.  The z values seem to be put into place but not accumulated when multiple y vs x have the same value.  Can anyone verify this behavior?  I was looking through the documentation

http://yt.enzotools.org/doc/modules/plotting.html?highlight=phase#yt.raven.P...

but the "accumulation" parameter sets whether the y values are summed along x instead of the z colorbar.

The plots are attached.

From G.S. _______________________________________________ yt-users mailing list yt-users@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org

Hi Geoffrey, Well, what do you -- and the rest of the users! -- think? Should, by default, the phase plot display the cumulative value in a bin, or should it report the average value? When I wrote this functionality a couple years ago I was using it to look at the average H2 fraction in a bin. Nowadays, though, I have been using it more and more for mass distribution. What does everybody think? -Matt On Tue, Feb 23, 2010 at 1:54 PM, wrote:

Yes the 2nd post should say in this order "Density","IonizationFraction","CellVolumeCode" and yes the weight=None fixed the plot, which I thought was on by default but when I checked again the default is actually "CellMassMsun"

From G.S.

...

Hi Geoffrey,

By default, the phase plot takes the average and weighs that average by the mass in a cell.  Both of your plots should have "weight=None" in the argument list, so that the total of the third quantity ("CellMassMsun" and "CellVolumeCode", but I think for the second your script must be different than what you copy/pasted) in each bin is displayed, rather than the average.  For a unigrid simulation, the average CellVolumeCode will be constant everywhere, and the average Mass will increase with Density, as M = rho * V where V is a constant.

-Matt

On Tue, Feb 23, 2010 at 1:22 PM,   wrote:

...

When I tried the following: p = pc.add_phase_object(dd, ["Density","IonizationFraction","CellMassMsun"], lazy_reader = True)

this gave me a phase plot of IonizationFraction vs Density, and the z axis colorbar shows a distribution of different masses, but if I used the following:

p = pc.add_phase_object(dd, ["Density","CellVolumeCode","IonizationFraction"], lazy_reader = True)

I get no distribution in the z colorbar at all.  The z values seem to be put into place but not accumulated when multiple y vs x have the same value.  Can anyone verify this behavior?  I was looking through the documentation

http://yt.enzotools.org/doc/modules/plotting.html?highlight=phase#yt.raven.P...

but the "accumulation" parameter sets whether the y values are summed along x instead of the z colorbar.

The plots are attached.

From G.S. _______________________________________________ yt-users mailing list yt-users@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org

_______________________________________________ yt-users mailing list yt-users@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org

_______________________________________________ yt-users mailing list yt-users@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org

Hi All,

I think the current default is fine. Really, the only two choices that make sense for a default is to weight by mass or 'None', and I see no reason to change it now that it's been this way for so long.

I concur. I often do non-mass weighting (for various reasons), but there is no reason to change the default at this stage. j

Keeping it as is is fine, as long as it's stated in the documentation, and it is, I just mis-read it the first time :-) From G.S.

I vote for keeping it as it is for the same reasons already given.

Britton

On Tue, Feb 23, 2010 at 3:43 PM, j s oishi wrote:

...

Hi All,

...

I think the current default is fine. Really, the only two choices that make sense for a default is to weight by mass or 'None', and I see no reason to change it now that it's been this way for so long.

I concur. I often do non-mass weighting (for various reasons), but there is no reason to change the default at this stage.

j _______________________________________________ yt-users mailing list yt-users@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org

_______________________________________________ yt-users mailing list yt-users@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org