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
...
[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