[yt-users] wired square in enzo DM slice map

Mon Jun 15 17:13:38 PDT 2015

On Mon, Jun 15, 2015 at 5:07 PM, Brian O'Shea <bwoshea at gmail.com> wrote:

> Dear Junhwan,
>
> Nathan is correct; this is an Enzo 'feature' and has to do with how Enzo
> treats dark matter particles at the boundary conditions.  Particles are
> smoothed onto a grid to calculate a density field using cloud-in-cell
> interpolation, which is necessary to solve Poisson's equation.  While the
> boundary conditions between grids (i.e., ghost zones where mass has been
> deposited) are exchanged when Poisson's equation is actually solved, this
> is NOT done prior to an Enzo output, so there's some missing mass along the
> grid boundaries.  Neither Enzo nor yt is broken - this is expected behavior
> for Enzo, although it does not translate to pretty pictures when you're
> looking at the dark matter density field, particularly at early times.
>
> With regards to why MUSIC displays this behavior more egregiously than
> CICASS, I believe that it has nothing to do with Enzo reading in particle
> displacements vs. actual positions, since the displacements are immediately
> converted to particle positions upon being read in.  Rather, there are
> three possible differences between MUSIC and CICASS that would both lean in
> the direction of MUSIC showing more of an effect than CICASS:
>
> 1) MUSIC allows the user to use 2nd order Lagrangian perturbation theory
> to calculate initial conditions and CICASS uses 1st order LPT.  Due to
> this, MUSIC probably results in the particles initially being moved further
> from their initial positions at the centers of cells, and thus the effect
> is substantially more pronounced.  You could test this by turning off 2LPT
> in MUSIC (use_2LPT = no) and check to see if there's a difference.  If
> you're already using 1st order LPT for both codes, then this is not your
> problem.
>
> 2) When MUSIC initially reads in the particle displacements, some
> particles could be initially displaced far enough from the center of the
> grid cell that their mass is mostly in the ghost zones, or moved into the
> ghost zones entirely. This means that a lot of mass will be missing around
> grid edges. This will show up if data is written out prior to the first
> timestep, but when you call RebuildHierarchy it will immediately get fixed
> and things should look fine - and I note that this should not affect the
> simulation evolution in any way!  If you read in the CICASS ICs - i.e,
> reading particle positions directly - the ring code will ensure that
> particles are in the correct grids at simulation initialization, which
> mitigates this effect.
>
> 3) You could have turned off parallel IO when you used the CICASS ICs,
> which would make everything look fine since there's just a single root grid
> tile.  If you'd like to send me the two Enzo IC files, I'd be happy to
> inspect them.
>
> Finally, if you are really concerned and want to double-check that the
> code is doing the right thing, I have an IPython notebook that makes simple
> dark matter density projections by depositing the particles directly onto a
> 2D uniform array, which I wrote due to precisely the 'feature' you're
> seeing.  This notebook is a rather ugly hack, uncommented, and presented
> without any promise of support; however, it gets the job done.
>

yt's "arbitrary_grid" feature might also be useful here.

http://yt-project.org/docs/dev/analyzing/objects.html?highlight=arbitrary_grid#arbitrary-grid

>
> I hope this helps!
>
> Regards,
> Brian
>
>
>
> On Mon, Jun 15, 2015 at 5:02 PM, Junhwan Choi (최준환) <
> choi.junhwan at gmail.com> wrote:
>
>> Thank you Nathan,
>>
>> As I mentioned in my original inquire, if I use other IC generator
>> such as CICASS, I do not get this wired square.
>> I found that the MUSIC generates ParticleDisplacements_x/y/z, while
>> the CICASS generates ParticlePositions for the DM particle position
>> information.
>> If this is the intrinsic enzo issue, there could be a subtle flaw for
>> the enzo's DM N-body calculation if one uses MUSIC output.
>> If this is a case, I had better report it to enzo user mailing list…
>>
>> Best,
>> Junhwan
>>
>>
>> On Mon, Jun 15, 2015 at 1:20 PM, Nathan Goldbaum <nathan12343 at gmail.com>
>> wrote:
>> > If this is a plot of the Enzo "Dark_Matter_Density" field that gets
>> written
>> > to Enzo output files, then the artifacts you're seeing are generated by
>> > Enzo. yt is just plotting whatever is in your output files.
>> >
>> > You should be able to see how Enzo generates this field by grepping the
>> > codebase for "OutputSmoothedDarkMatter" and looking at the relevant code
>> > sections. One key thing: I believe Enzo's CIC deposit machinery doesn't
>> > handle grid boundary conditions properly, so and particles that should
>> > contribute to the cells that are at a grid boundary will only
>> contribute if
>> > they are on one side of the grid boundary. This would lead to the
>> deficits
>> > you're seeing. I haven't looked at that code in a while so please
>> excuse me
>> > if I'm misremembering here.
>> >
>> > Hope that's helpful,
>> >
>> > Nathan
>> >
>> > On Mon, Jun 15, 2015 at 9:59 AM, Junhwan Choi (최준환) <
>> choi.junhwan at gmail.com>
>> > wrote:
>> >>
>> >> Hi yt users,
>> >>
>> >> I have asked a similar question previously but I did get partial
>> >> answer so that I ask again.
>> >> I have made cosmological IC from MUSIC and run with enzo.
>> >> I made the DM density map with velocity arrow at z=200 which is
>> >> initial redshift using yt (and attach the figure).
>> >> It shows the wired square feature.
>> >> Previously, John wise suggested me to use enzo SPH smoothing to remove
>> >> this issue and it worked.
>> >> But, after test a few more run, I have couple more fundamental
>> >> questions on this issue.
>> >>
>> >> 1) Is this wired square effect is real effect in enzo or visualization
>> in
>> >> yt?
>> >>     If this is an intrinsic enzo effect, we can say that DM gravity
>> >> calculation at high-z some kind of error.
>> >>     If this is an visualization effect, I found that other enzo
>> >> simulation using different IC generator does not show this effect (see
>> >> question 2).
>> >>     This difference makes me very confused.
>> >>
>> >> 2) I tested with other IC generator and I do not see the wired square
>> >> feature.
>> >>     I found that other IC generator output real DM position while
>> >> MUSIC IC generate displacement of DM particle position.
>> >>     Can it be the origin of issue?
>> >>
>> >>
>> >> I think this inquiry can go to enzo mailing list or MUSIC developer.
>> >> If it is necessary, I can ask it to other place.
>> >>
>> >> Thank you in advance,
>> >> Junhwan
>> >>
>> >> _______________________________________________
>> >> yt-users mailing list
>> >> yt-users at lists.spacepope.org
>> >> http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
>> >>
>> >
>> >
>> > _______________________________________________
>> > yt-users mailing list
>> > yt-users at lists.spacepope.org
>> > http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
>> >
>> _______________________________________________
>> yt-users mailing list
>> yt-users at lists.spacepope.org
>> http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
>>
>
>
> _______________________________________________
> yt-users mailing list
> yt-users at lists.spacepope.org
> http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.spacepope.org/pipermail/yt-users-spacepope.org/attachments/20150615/19bf8671/attachment.html>