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