On Mon, Jun 15, 2015 at 5:07 PM, Brian O'Shea <bwoshea@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_gr...
I hope this helps!
Regards, Brian
On Mon, Jun 15, 2015 at 5:02 PM, Junhwan Choi (최준환) < choi.junhwan@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@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@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@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
_______________________________________________ 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