New issue 837: Deposited Particle filter fields do not show up in derived_field_list
https://bitbucket.org/yt_analysis/yt/issue/837/deposited-particle-filter-...
Nathan Goldbaum:
Take the following example script:
```
#!python
import yt
import numpy as np
import pprint
from yt.data_objects.particle_filters import add_particle_filter
from matplotlib import pyplot as plt
def star(pfilter, data):
filter = data["all", "particle_type"] == 2
return filter
add_particle_filter("star", function=star, filtered_type="all",
requires=["particle_type"])
filename = "IsolatedGalaxy/galaxy0030/galaxy0030"
ds = yt.load(filename)
ds.add_particle_filter("star")
pprint.pprint(ds.derived_field_list)
```
While the particle fields for the "star" particle types do show up, only the deposit fields for `"io"` and `"all"` show up under the deposit ptype. The deposit fields for the `"star"` ptype can be accessed through a data object, so the issue seems to be with the way deposit fields are added to the `derived_field_list` rather than the deposit fields themselves.
Hi all,
It looks like bitbucket has adjusted the way updating pull requests works.
Now, if you have an open pull request, if you push changes to the head
corresponding to the open pull request, the PR will be updated
automatically. More detail here:
http://blog.bitbucket.org/2014/04/22/bitbucket-now-auto-updates-pull-requ...
I think this is a good change for the most part, but it's something to keep
in mind when pushing to your repositories.
Happy hacking,
Nathan
Hi all,
We're getting perilously close to a beta release of 3.0 -- I think at this
point we have most major functionality in place, answer testing is back
online, and the number of cards left for a release is dropping
precipitously. The *major* thing holding us back is documentation.
I'd like to have a "virtual sprint." This would be where people can drop
in at any time during the day, for however long they can stay, and we chat
about things and knock a few items off the todo list. Mostly -- it's a
time when people can spend ten minutes reading docs and making some edits.
I've set up a doodle here:
http://doodle.com/7ymg5bw7nq5mrmxg
If you want to participate, fill out which days work for you. I'll set up
the hangout on the day of and keep it going as long as people are around.
I've added a list to the board for sprints about this:
https://trello.com/b/FH69aXps/sprints-and-workshops
-Matt
New issue 835: Field detection issue for Tipsy datasets
https://bitbucket.org/yt_analysis/yt/issue/835/field-detection-issue-for-...
Nathan Goldbaum:
The following script:
```
#!python
from yt.mods import *
ds = load('TipsyGalaxy/galaxy.00300', n_ref=8)
ds.derived_field_list
dd = ds.all_data()
xcoord = dd['Gas','Coordinates'][:,0].v
ycoord = dd['Gas','Coordinates'][:,1].v
slc = SlicePlot(ds, 'z', ('gas','density'), width=(40, 'kpc'), center='m')
slc.save()
```
Produces the following traceback:
```
#!python traceback
Traceback (most recent call last):
File "test.py", line 7, in <module>
slc = SlicePlot(ds, 'z', ('gas','density'), width=(40, 'kpc'), center='m')
File "/Users/goldbaum/Documents/yt-hg/yt/visualization/plot_window.py", line 1749, in SlicePlot
return AxisAlignedSlicePlot(pf, normal, fields, *args, **kwargs)
File "/Users/goldbaum/Documents/yt-hg/yt/visualization/plot_window.py", line 972, in __init__
(bounds, center) = get_window_parameters(axis, center, width, pf)
File "/Users/goldbaum/Documents/yt-hg/yt/visualization/plot_window.py", line 166, in get_window_parameters
center = get_sanitized_center(center, pf)
File "/Users/goldbaum/Documents/yt-hg/yt/visualization/plot_window.py", line 146, in get_sanitized_center
v, center = pf.h.find_max("density")
File "/Users/goldbaum/Documents/yt-hg/yt/data_objects/static_output.py", line 533, in find_max
source.quantities["MaxLocation"](field)
File "/Users/goldbaum/Documents/yt-hg/yt/data_objects/derived_quantities.py", line 527, in __call__
rv = super(MaxLocation, self).__call__(field)
File "/Users/goldbaum/Documents/yt-hg/yt/data_objects/derived_quantities.py", line 59, in __call__
sto.result = self.process_chunk(ds, *args, **kwargs)
File "/Users/goldbaum/Documents/yt-hg/yt/data_objects/derived_quantities.py", line 538, in process_chunk
if data[field].size > 0:
File "/Users/goldbaum/Documents/yt-hg/yt/data_objects/data_containers.py", line 205, in __getitem__
f = self._determine_fields([key])[0]
File "/Users/goldbaum/Documents/yt-hg/yt/data_objects/data_containers.py", line 453, in _determine_fields
finfo = self.pf._get_field_info(ftype, fname)
File "/Users/goldbaum/Documents/yt-hg/yt/data_objects/static_output.py", line 493, in _get_field_info
raise YTFieldNotFound((ftype, fname), self)
yt.utilities.exceptions.YTFieldNotFound: Could not find field '('all', 'density')' in galaxy.00300.
```
When I remove the call to `ds.derived_field_list` I get a different failure:
```
#!python traceback
Traceback (most recent call last):
File "test.py", line 4, in <module>
xcoord = dd['Gas','Coordinates'][:,0].v
File "/Users/goldbaum/Documents/yt-hg/yt/data_objects/data_containers.py", line 212, in __getitem__
self.get_data(f)
File "/Users/goldbaum/Documents/yt-hg/yt/data_objects/data_containers.py", line 556, in get_data
self.index._identify_base_chunk(self)
File "/Users/goldbaum/Documents/yt-hg/yt/geometry/particle_geometry_handler.py", line 140, in _identify_base_chunk
self.regions.identify_data_files(dobj.selector)]
File "/Users/goldbaum/Documents/yt-hg/yt/data_objects/data_containers.py", line 512, in selector
self._selector = sclass(self)
File "selection_routines.pyx", line 626, in yt.geometry.selection_routines.RegionSelector.__init__ (yt/geometry/selection_routines.c:9845)
File "/Users/goldbaum/Documents/yt-hg/yt/units/yt_array.py", line 753, in __getitem__
ret = super(YTArray, self).__getitem__(item)
IndexError: 0-d arrays can't be indexed
```
Finally, when I remove the lines that create and access data inside the `all_data` object, the script runs successfully and the plot is saved to disk.
This uses the TipsyGalaxy dataset which will be uploaded to yt-project.org/data shortly.
Are there any plans to natively support single-precision datasets?
(sometimes we store 32-bit instead of 64-bit to save space). If I access
my data and then create a covering grid, in the YTCoveringGridBase code,
when it makes the grid for the data, it hardcodes in "float64" -- ideally
it would keep the precision of the dataset all the way through.
Mike
--
Michael Zingale
Associate Professor
Dept. of Physics & Astronomy * Stony Brook University * Stony Brook, NY
11794-3800
*phone*: 631-632-8225
*e-mail*: Michael.Zingale(a)stonybrook.edu
*web*: http://www.astro.sunysb.edu/mzingale
Hi all,
I don't recall when I first noticed this, but I'm finding that the
parallel_root_only decorator doesn't seem to be working. A simple test is
to run a script that only loads a dataset. The print_key_parameters
function is inside of a parallel_root_only decorator, so all that should
only be printed by the root processor, but when I run that script in
parallel it is printed by all processors. I am still looking into this,
but so far I have found that printing the value of parallel_capable inside
this decorator always gives False even when running in parallel.
Can someone confirm this? If so, does anyone know what's going on?
Britton
New issue 833: parallel_capable getting reset to False running in parallel
https://bitbucket.org/yt_analysis/yt/issue/833/parallel_capable-getting-r...
Britton Smith:
The parallel_capable global variable is getting reset to False somewhere, causing decorators like parallel_root_only not to work correctly. This can be reproduced by either of the following scripts run in parallel:
```
#!python
import yt
yt.enable_parallelism()
pf = yt.load("DD0064/DD0064")
from yt.mods import *
pf = load("DD0064/DD0064")
```
New issue 832: In Enzo data 'dynamical_time' field returns inconsistent results
https://bitbucket.org/yt_analysis/yt/issue/832/in-enzo-data-dynamical_tim...
jmoloney:
For Enzo datasets, using the field name 'dynamical_time' instead of the full field ('all', 'dynamical_time'), ('io', 'dynamical_time'), or ('gas', dynamical_time') produces inconsistent results. As far as I can tell, this is because it is the only field that is defined with the same name for both particles and gas. Depending on which fields have been called previously, the field returned by 'dynamical_time' may be either one or the other. I haven't been able to figure out a clear pattern for when each is returned.
The attached example.py should help illustrate what I mean as long as you have an Enzo dataset to give it. When I run this, using 'density' vs 'Density' produces consistently different results, while the first use of 'cooling_time' is different than subsequent calls.
