wired square in enzo DM slice map
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
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
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
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@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
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
yt's "arbitrary_grid" feature might also be useful here.
http://yt-project.org/docs/dev/analyzing/objects.html?highlight=arbitrary_gr...
I concur, though if the size of the grid or number of particles is large (as in the simulation I've been working with) this can result in memory issues. --Brian
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
_______________________________________________ yt-users mailing list yt-users@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
Hi Brian, On Mon, Jun 15, 2015 at 7:18 PM, Brian O'Shea <bwoshea@gmail.com> wrote:
yt's "arbitrary_grid" feature might also be useful here.
http://yt-project.org/docs/dev/analyzing/objects.html?highlight=arbitrary_gr...
I concur, though if the size of the grid or number of particles is large (as in the simulation I've been working with) this can result in memory issues.
I'm hesitating to push us further into the weeds here when you've given a very thoughtful and helpful reply to Junhwan, but arbitrary_grid can be flat along one dimension (i.e., NxMx1) and was designed for this use case. -Matt
--Brian
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
_______________________________________________ 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's "arbitrary_grid" feature might also be useful here.
http://yt-project.org/docs/dev/analyzing/objects.html?highlight=arbitrary_gr...
I concur, though if the size of the grid or number of particles is large (as in the simulation I've been working with) this can result in memory issues.
I'm hesitating to push us further into the weeds here when you've given a very thoughtful and helpful reply to Junhwan, but arbitrary_grid can be flat along one dimension (i.e., NxMx1) and was designed for this use case.
Oh, this is intriguing - I stumbled across this when I came up with my original (hacktacular) solution, but in my reading of the documentation (and, admittedly, a cursory skim of the source code) suggested that if I wanted to, say, project the density of *all* of the particles in a simulation onto a grid of [NxMx1] that it would not work - I'd only get particles that happened to intersect the one-cell-thick volume of that grid, which would give me a slice but not a projection. Did I misread that? If so, it is a much more elegant solution than mine. :-) --Brian
On Mon, Jun 15, 2015 at 7:30 PM, Brian O'Shea <bwoshea@gmail.com> wrote:
yt's "arbitrary_grid" feature might also be useful here.
http://yt-project.org/docs/dev/analyzing/objects.html?highlight=arbitrary_gr...
I concur, though if the size of the grid or number of particles is large (as in the simulation I've been working with) this can result in memory issues.
I'm hesitating to push us further into the weeds here when you've given a very thoughtful and helpful reply to Junhwan, but arbitrary_grid can be flat along one dimension (i.e., NxMx1) and was designed for this use case.
Oh, this is intriguing - I stumbled across this when I came up with my original (hacktacular) solution, but in my reading of the documentation (and, admittedly, a cursory skim of the source code) suggested that if I wanted to, say, project the density of *all* of the particles in a simulation onto a grid of [NxMx1] that it would not work - I'd only get particles that happened to intersect the one-cell-thick volume of that grid, which would give me a slice but not a projection. Did I misread that? If so, it is a much more elegant solution than mine. :-)
Yup, arbitrary_grid is more flexible than covering_grid. It accepts left edge, right edge, *and* dimensions. -Matt
--Brian
_______________________________________________ yt-users mailing list yt-users@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
OK folks, after a quick offline chat with Matt, I realized that I was being overly constrained in my assumption that grid cells need to be cubes - they do not. To that end, the arbitrary_grid thing works *perfectly* to make dark matter projections. To deposit all of the particles to a 2D grid, the following script (with a few comments to clarify what's going on) works great and is a vastly better solution than mine. Thanks to Matt for pointing this out! :-) import yt import numpy as np import matplotlib.pyplot as plt ds = yt.load("RD0009/RD0009") center = [0.5, 0.5, 0.5] left = [0.4, 0.4, 0.4] right = [0.6, 0.6, 0.6] # creates 512 x 512 x 1 grid, so the 3rd dimension of the cell is very long. my_reg = ds.arbitrary_grid(left, right, dims=[512, 512, 1]) # ("deposit", "all_density") in enzo is equivalent to depositing all particles, so dm, star, etc. # the ".value" part at the end strips off the units (maybe not necessary) dens = my_reg[("deposit", "all_density")].value # this reshapes the array from (512, 512, 1) to (512, 512), to make plt.imshow happy dens = dens.reshape( (512,512)) # sets a floor to the values which was chosen somewhat arbitrarily. dens += 1.0e-30 # plots the log of the density plt.imshow(np.log10(dens),cmap='algae') On Mon, Jun 15, 2015 at 8:32 PM, Matthew Turk <matthewturk@gmail.com> wrote:
On Mon, Jun 15, 2015 at 7:30 PM, Brian O'Shea <bwoshea@gmail.com> wrote:
yt's "arbitrary_grid" feature might also be useful here.
http://yt-project.org/docs/dev/analyzing/objects.html?highlight=arbitrary_gr...
I concur, though if the size of the grid or number of particles is large (as in the simulation I've been working with) this can result in memory issues.
I'm hesitating to push us further into the weeds here when you've given a very thoughtful and helpful reply to Junhwan, but arbitrary_grid can be flat along one dimension (i.e., NxMx1) and was designed for this use case.
Oh, this is intriguing - I stumbled across this when I came up with my original (hacktacular) solution, but in my reading of the documentation (and, admittedly, a cursory skim of the source code) suggested that if I wanted to, say, project the density of *all* of the particles in a simulation onto a grid of [NxMx1] that it would not work - I'd only get particles that happened to intersect the one-cell-thick volume of that grid, which would give me a slice but not a projection. Did I misread that? If so, it is a much more elegant solution than mine. :-)
Yup, arbitrary_grid is more flexible than covering_grid. It accepts left edge, right edge, *and* dimensions.
-Matt
--Brian
_______________________________________________ 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
Thank you Brian, Nathan and Matt, I will test what you guys suggested soon and will report the progress. Thank you for your kind suggestions. Junhwan On Mon, Jun 15, 2015 at 7:57 PM, Brian O'Shea <bwoshea@gmail.com> wrote:
OK folks, after a quick offline chat with Matt, I realized that I was being overly constrained in my assumption that grid cells need to be cubes - they do not. To that end, the arbitrary_grid thing works *perfectly* to make dark matter projections. To deposit all of the particles to a 2D grid, the following script (with a few comments to clarify what's going on) works great and is a vastly better solution than mine. Thanks to Matt for pointing this out! :-)
import yt import numpy as np import matplotlib.pyplot as plt
ds = yt.load("RD0009/RD0009")
center = [0.5, 0.5, 0.5] left = [0.4, 0.4, 0.4] right = [0.6, 0.6, 0.6]
# creates 512 x 512 x 1 grid, so the 3rd dimension of the cell is very long. my_reg = ds.arbitrary_grid(left, right, dims=[512, 512, 1])
# ("deposit", "all_density") in enzo is equivalent to depositing all particles, so dm, star, etc. # the ".value" part at the end strips off the units (maybe not necessary) dens = my_reg[("deposit", "all_density")].value
# this reshapes the array from (512, 512, 1) to (512, 512), to make plt.imshow happy dens = dens.reshape( (512,512))
# sets a floor to the values which was chosen somewhat arbitrarily. dens += 1.0e-30
# plots the log of the density plt.imshow(np.log10(dens),cmap='algae')
On Mon, Jun 15, 2015 at 8:32 PM, Matthew Turk <matthewturk@gmail.com> wrote:
On Mon, Jun 15, 2015 at 7:30 PM, Brian O'Shea <bwoshea@gmail.com> wrote:
yt's "arbitrary_grid" feature might also be useful here.
http://yt-project.org/docs/dev/analyzing/objects.html?highlight=arbitrary_gr...
I concur, though if the size of the grid or number of particles is large (as in the simulation I've been working with) this can result in memory issues.
I'm hesitating to push us further into the weeds here when you've given a very thoughtful and helpful reply to Junhwan, but arbitrary_grid can be flat along one dimension (i.e., NxMx1) and was designed for this use case.
Oh, this is intriguing - I stumbled across this when I came up with my original (hacktacular) solution, but in my reading of the documentation (and, admittedly, a cursory skim of the source code) suggested that if I wanted to, say, project the density of *all* of the particles in a simulation onto a grid of [NxMx1] that it would not work - I'd only get particles that happened to intersect the one-cell-thick volume of that grid, which would give me a slice but not a projection. Did I misread that? If so, it is a much more elegant solution than mine. :-)
Yup, arbitrary_grid is more flexible than covering_grid. It accepts left edge, right edge, *and* dimensions.
-Matt
--Brian
_______________________________________________ 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
participants (4)
-
Brian O'Shea -
Junhwan Choi (최준환) -
Matthew Turk -
Nathan Goldbaum