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? Best, John Z
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
Matt's correct, if you're using density fields that come from cic_deposit, the particle "masses" are already actually densities, so the dx^3 has already been divided out. It's probably not a given that all codes will store the particle masses as densities, so it is probably worth it to make those enzo specific. Britton 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
participants (3)
-
Britton Smith -
John ZuHone -
Matthew Turk