On Thu, Jan 20, 2011 at 7:12 AM, Matthew Turk <matthewturk@gmail.com> wrote:

Hi John,

On Thu, Jan 20, 2011 at 3:08 AM, John ZuHone <jzuhone@cfa.harvard.edu> wrote:
> Hello all,
>
> It appears from a cursory look at the source code that CICDeposit_3 does not automatically convert the mapped "mass" to a density itself... that the volume must be divided by after the fact. Is this correct?

Britton might have more to say about this (as he wrote CICDeposit_3)
but I believe you are correct in some cases. The Enzo field
particle_mass is actually a density, name notwithstanding. From my
reading of the field definitions, CICDeposit_3 shows up in these
fields, where the parenthetical note is the type of field:

particle_density (universal)
star_density (enzo)
dm_density (enzo)
star_metallicity_fraction (via star_field) (enzo)
star_creation_time (via star_field) (enzo)
star_dynamical_time (via star_field) (enzo)

As long as particle_mass is defined as a density (and looking at
yt/frontends/flash/fields.py, I see that there it is not) this should
work fine for the particle_density field. The last field, star_field,
is the only one that doesn't use exclusively particle_mass, and it is
careful about depositing both the field requested and then dividing by
the particle mass deposited, giving a weighted average.

I think perhaps a good solution here would be to move particle_density
to being Enzo specific, and then having individual codes define their
own version of those fields, to avoid any problems. What do you
think?

-Matt

>
> Best,
>
> John Z
> _______________________________________________
> 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