Hi all, While performing projections of the density ?field in a cosmological zoom-in simulation, I noticed sudden fluctuations between the projected density of consecutive snapshots. I thought the fluctuations were due to interlopers entering the field of view (I was looking at the zoom-in region of the box). However, regardless what region of the cosmological box I plot (below I project the whole cosmological box), the fluctuation remains. Note that the fluctuation is not seen in the particle data. Please let me know if this issue is reproducible by others (I'm using yt 3.4-dev) and how I could go about solving it. I've linked a simple sample script and the projection output. The projections are made using Arepo data, but I am treating the data as a Gadget Dataset in yt. The data is available at: http://use.yt/upload/44604f23 and http://use.yt/upload/a5e7f213 Output: - snapshot1: http://i.imgur.com/a3w6vVn.png - snapshot2: http://i.imgur.com/Bq5xlOB.png? Sample script: ``` # importing libraries import yt from yt.frontends.gadget.data_structures import GadgetHDF5Dataset # reading snapshot data ds1 = GadgetHDF5Dataset('../data/1605-2/snapshot_052.hdf5') ds2 = GadgetHDF5Dataset('../data/1605-2/snapshot_053.hdf5') # density un-weighted projections proj1 = yt.ProjectionPlot(ds1, 'z', ('gas','density')) proj2 = yt.ProjectionPlot(ds2, 'z', ('gas','density')) proj1.set_zlim('density', 1.E-4, 1.E-2) proj2.set_zlim('density', 1.E-4, 1.E-2) proj1.save() proj2.save() ``` Thanks, Maan??
Hi Maan, First, thanks for the detailed report, and sorry for taking a couple of days to respond. The basic issue is illustrated by running the following code snippet for both datasets: ad = ds.all_data() mass= ad['gas', 'density'] * ad['index', 'cell_volume'] print(mass.sum().to('Msun')) For snapshot_52, this prints ~2.6*10^15 Msun, but for snapshot_53 it prints 4.1*10^15 Msun. This implies that the SPH smoothing operation used by yt isn't conserving mass very well for your arepo data. One possible cause might be that for Gadget data, yt uses the ('PartType0', 'SmoothingLength') field to evaluate the smoothing kernel during the projection. I don't actually know how arepo generates this field, since presumably not actually doing any SPH smoothing. Perhaps using this field is a bad estimate for arepo data and we should be trying to generate SPH smoothing lengths self-consistently inside yt, like we do for tipsy data? Finally, I went ahead and calculated the smoothed projection using a version of yt that partially implements the "demeshening" effort, where we are trying to eliminate the global octree mesh for particle data. This will hopefully be part of what will be called yt either yt 3.4 or yt 4.0 (we haven't discussed yet whether this change is big enough to warrant a major version bump). This is an in-development version of yt that is partially broken - I had to add some ugly hacks to produce these images - and is unfortunately not yet ready for general use. That said, it gives you an idea of what we're working toward here. Here's what the projections look like in the demeshening: snapshot_052: http://i.imgur.com/z9fhN7R.png snapshot_053: http://i.imgur.com/ZWZIW3B.png Note that the demeshening work will also make it much easier to add a slice and projection pixelizer that is aware of the voronoi mesh. In fact, if you're interested in contributing, I think that would be a great place to start hacking on yt for someone who works with arepo data. Sorry to not have a conclusive, satisfying answer for you. I hope that gives you some more context on the limitations of the current support for arepo data in yt. -Nathan On Wed, Nov 2, 2016 at 3:17 PM, Maan Hani <mhani@uvic.ca> wrote:
...
[Message clipped] _______________________________________________ yt-users mailing list yt-users@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
participants (2)
-
Maan Hani
-
Nathan Goldbaum