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.<br>
<br>Britton<br><br><div class="gmail_quote">On Thu, Jan 20, 2011 at 7:12 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: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Hi John,<br>
<div class="im"><br>
On Thu, Jan 20, 2011 at 3:08 AM, John ZuHone <<a href="mailto:jzuhone@cfa.harvard.edu">jzuhone@cfa.harvard.edu</a>> wrote:<br>
> Hello all,<br>
><br>
> 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?<br>

<br>
</div>Britton might have more to say about this (as he wrote CICDeposit_3)<br>
but I believe you are correct in some cases.  The Enzo field<br>
particle_mass is actually a density, name notwithstanding.  From my<br>
reading of the field definitions, CICDeposit_3 shows up in these<br>
fields, where the parenthetical note is the type of field:<br>
<br>
particle_density (universal)<br>
star_density (enzo)<br>
dm_density (enzo)<br>
star_metallicity_fraction (via star_field) (enzo)<br>
star_creation_time (via star_field) (enzo)<br>
star_dynamical_time (via star_field) (enzo)<br>
<br>
As long as particle_mass is defined as a density (and looking at<br>
yt/frontends/flash/fields.py, I see that there it is not) this should<br>
work fine for the particle_density field.  The last field, star_field,<br>
is the only one that doesn't use exclusively particle_mass, and it is<br>
careful about depositing both the field requested and then dividing by<br>
the particle mass deposited, giving a weighted average.<br>
<br>
I think perhaps a good solution here would be to move particle_density<br>
to being Enzo specific, and then having individual codes define their<br>
own version of those fields, to avoid any problems.  What do you<br>
think?<br>
<br>
-Matt<br>
<div><div></div><div class="h5"><br>
><br>
> Best,<br>
><br>
> John Z<br>
> _______________________________________________<br>
> yt-users mailing list<br>
> <a href="mailto:yt-users@lists.spacepope.org">yt-users@lists.spacepope.org</a><br>
> <a href="http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org" target="_blank">http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org</a><br>
><br>
_______________________________________________<br>
yt-users mailing list<br>
<a href="mailto:yt-users@lists.spacepope.org">yt-users@lists.spacepope.org</a><br>
<a href="http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org" target="_blank">http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org</a><br>
</div></div></blockquote></div><br>