New issue 1010: Covering Grid fails on fields requiring ValidateSpatial
https://bitbucket.org/yt_analysis/yt/issue/1010/covering-grid-fails-on-fiel…
J.S. Oishi:
Attempting to access a field that requires derivatives in a Covering Grid gives the error below. I've attached a simple script that reproduces the problem with the MHDSloshing test dataset. It includes the field definitions.
```
#!python
jj = data1['CurrentDensityMagnitude']
File "/home/oishij/build/yt-x86_64/src/yt-hg/yt/data_objects/data_containers.py", line 325, in __getitem__
self.get_data(key)
File "/home/oishij/build/yt-x86_64/src/yt-hg/yt/data_objects/data_containers.py", line 3758, in get_data
self._generate_field(field)
File "/home/oishij/build/yt-x86_64/src/yt-hg/yt/data_objects/data_containers.py", line 3789, in _generate_field
self.pf.field_info[field].check_available(self)
File "/home/oishij/build/yt-x86_64/src/yt-hg/yt/data_objects/field_info_container.py", line 356, in check_available
validator(data)
File "/home/oishij/build/yt-x86_64/src/yt-hg/yt/data_objects/field_info_container.py", line 486, in __call__
raise NeedsGridType(self.ghost_zones,self.fields)
yt.data_objects.field_info_container.NeedsGridType: (1, ['Bx', 'By', 'Bz'])
```
Responsible: MatthewTurk
_______________________________________________
yt-dev mailing list
yt-dev(a)lists.spacepope.org
http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
Hi all,
I created a pull request a while back:
https://bitbucket.org/yt_analysis/yt/pull-request/1384/wip-grid-visitors-in…
which contains a slight refactoring of the Grid Tree by John ZuHone,
as well as a bitarray implementation and a first set of "grid visitor"
functions, similar in spirit to the octree visitor functions.
I was hoping to request a review with an aim to get it merged in
before turning it on. The grid visitor functions haven't been turned
on yet, but I think it's worth getting feedback in advance of that,
and also so that the bitarray code (which should have been its own PR,
sadly) can get used elsewhere.
A while back, Sam and I looked for performance regressions; the
biggest one was in the generic chunking system and its impact on patch
based data. This should both improve the speed of that system for
grid patch datasets as well as reduce the memory overhead. Getting
this PR landed, and then turning it on at a later date will be a big
step forward in getting performance improvements as well as memory
reduction.
Thanks,
Matt
_______________________________________________
yt-dev mailing list
yt-dev(a)lists.spacepope.org
http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
New issue 1009: Streamline plot callback may be transposed
https://bitbucket.org/yt_analysis/yt/issue/1009/streamline-plot-callback-ma…
Matthew Turk:
In debugging the streamline plot callback, I've run into something odd. I'm hoping @jwise77 , who wrote it originally, might be able to chime in.
It's not clear to me that we are doing "the right thing" since we have an image plot which is using `origin='lower'` and a streamline plot that is not. Additionally, the x, y ordering requires us *not* to transpose the resultant image buffers to get the right shape of our array, if we have a non-unitary input buffer.
In short, I think the inputs may be transposed but shouldn't be, and I'm not sure the streamplot is right.
Responsible: MatthewTurk
_______________________________________________
yt-dev mailing list
yt-dev(a)lists.spacepope.org
http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
Hi all, especially Nathan and Cameron,
In the plot callbacks, there are a few (quiver / cutting quiver,
streamline, and clump contour) where we call [C]Pixelize directly.
If we're specifying a skip parameter, that reduces the resolution and
I can see why we do it. But is there a good reason, if skip is set to
do every value, why we wouldn't use the plot.frb object itself?
-Matt
_______________________________________________
yt-dev mailing list
yt-dev(a)lists.spacepope.org
http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
New issue 1008: Difficulties with particle data sets
https://bitbucket.org/yt_analysis/yt/issue/1008/difficulties-with-particle-…
Adam Ginsburg:
I have a particle data set I am loading with `yt.load_particles`:
```
ds = yt.load_particles(data,
length_unit=udisti*centimeter,
mass_unit=umassi*gram, n_ref=n_ref,
velocity_unit=udisti/utimei*centimeter/second,
time_unit=utimei*second,
sim_time=gt*utimei*second,
periodicity=(False,False,False),
bbox=bbox)
```
In this case, `n_ref=8` and everything else is loaded from the simulation.
I'm trying to do a few things that don't work. I can successfully create a projection, but - at some point in the very recent past - I was unable to add contours to that projection, getting an error like "YTFieldNotFound: Could not find field '('all', 'density')' in ParticleData.". That problem seems to have disappeared, though - I can't explain why, as I didn't change anything.
If I try to make an isosurface contour for uploading to sketchfab, I get a `NotImplementedError`. Is there any way to grid the data first, then make isosurface contours?
If I try to make a volume rendering projection using the camera, I get the following segfault:
```
>>> ds = yt_from_jim(os.path.join(root_path, fn))
>>> ad = ds.all_data()
>>> mi, ma = ad.quantities.extrema("all_density")
>>> tf = yt.ColorTransferFunction((np.log10(mi)+1, np.log10(ma)))
>>> tf.add_layers(5, w=0.02, colormap="spectral")
>>> c = [0.5, 0.5, 0.5]
>>> L = [0.5, 0.2, 0.7]
>>> W = 1.0
>>> Npixels=512
>>> cam = ds.camera(c, L, W, Npixels, tf, fields='all_density')
Failed to split grids.
Failed to split grids.
Failed to split grids.
Failed to split grids.
Failed to split grids.
/Users/adam/anaconda/envs/astropy27/bin/python.app: line 3: 13569 Segmentation fault: 11 /Users/adam/anaconda/envs/astropy27/python.app/Contents/MacOS/python "$@"
```
The data are here:
https://www.dropbox.com/s/922kurz8vusa6pj/RUNI180?dl=0
and the loading script is here:
https://github.com/keflavich/jimpy/blob/master/yt/to_yt.py
I'll be trying a few more things (e.g., off-axis projection), so I'll add to this issue as I run into more problems.
_______________________________________________
yt-dev mailing list
yt-dev(a)lists.spacepope.org
http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
