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

Brian O'Shea bwoshea at gmail.com
Mon Jun 15 17:07:34 PDT 2015


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.

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.spacepope.org/pipermail/yt-users-spacepope.org/attachments/20150615/e4d6e3a1/attachment.htm>


More information about the yt-users mailing list