New issue 1197: YTPositionArray doesn't work
I don't think this is explicitly the fault of `YTArray`, but I don't know how to get around it. Right now, creating a `yt.data_objects.octree_subset.YTPositionArray` just returns `YTArray`. I'm not sure how to make sure that it returns the right class, but I suspect something in the `YTArray` code doesn't pass down subclasses. (It used to, I promise!)
Here's example code:
from yt.data_objects.octree_subset import YTPositionArray
ds = yt.load("enzo_tiny_cosmology/DD0043/DD0043")
pos = ds.r["particle_position"]
ppos = YTPositionArray(pos)
At this point, `ppos` should have `to_octree` as a method, but it doesn't. Not sure how to fix this -- @ngoldbaum do you know how I could make sure that the subclass is correctly handled?
As many of you may have noticed, Cameron and I followed through on our plan
to triage the issue tracker and identify issues that should block the 3.3
release. Apologies for the inbox damage this may have caused today.
This was a qualitative process based on our judgement calls, so if you feel
we made any mistakes on issues that you get notifications for, please feel
free to re-open or edit issues you have opinions about.
In the end, there are now 63 issues marked with a version of 3.3.
Provisionally, these are the blockers for the 3.3 release. You can see the
issues for yourself in this bitbucket search:
They vary in difficulty and we will probably end up deciding to punt on a
number of them, but as a rule of thumb, these issues are generally:
* not new features or feature requests
* documentation improvements
* probably solvable in a maximum of a few hours
Hopefully now that there are a finite number of things to do before 3.3,
rather than an undefined number of things to do, this will help us in
identifying things to work on, and aid in making progress on the release.
I'd like to request from the community that you take on these issues and
try to fix as many of them as we can before 3.3 goes out. I expect that we
will likely have another sprint on our slack channel within the next month
or so to try to get the bulk of them done, but please feel free to take any
of them on and issue a pull request at any time.
To ease managing closing the issues, include the phrase "Closes #XXXX" in
your pull request title (where XXXX is the issue number), so that when the
pull request is merged, the issue will also be closed.
Please reply to this thread if you have concerns about the general strategy
I've outlined here for releasing 3.3, or anything else related to the
issues or the 3.3 release itself.
Note that the deadline is in less than 22 hours!
You have to submit the application (in pdf format) to the Google summer of
code website before March 25th at 19'00 UTC . Google docs or
applications on the wiki are not the official submission though required by
some of the sub-organisations.
I've read in other mailing lists that you can upload the PDF and replace it
if needed up until the deadline.
Besides having a very good project plan and desciption I would encourage
you to pay attention to the presentation too. With that I don't mean only
how the text is formatted in the pdf submitted but also the orthography and
grammar of the text written, including punctuation, spaces and proper
capitalisation of the words. Check that the pdf you upload looks perfect -
that will be what we will use to evaluate your application!!
I also encourage students to write a first blog post about their experience
so far, no need to do that before the deadline, but it will be nice for us
to read your experiences so far while checking that the link to your blog
Good luck to everyone!!
New issue 1193: Add a default particle filter for Enzo
Right now (as pointed out by @rthompson ) particle filters for Star particles from "old" Enzo aren't set up. We may want to do this, so that they show up in particle types. For reference:
```#define PARTICLE_TYPE_GAS 0
#define PARTICLE_TYPE_DARK_MATTER 1
#define PARTICLE_TYPE_STAR 2
#define PARTICLE_TYPE_TRACER 3
#define PARTICLE_TYPE_MUST_REFINE 4
#define PARTICLE_TYPE_SINGLE_STAR 5
#define PARTICLE_TYPE_BLACK_HOLE 6
#define PARTICLE_TYPE_CLUSTER 7
#define PARTICLE_TYPE_MBH 8
#define PARTICLE_TYPE_COLOR_STAR 9
#define PARTICLE_TYPE_SIMPLE_SOURCE 10
This would likely come in around the time that default particle unions are set up.
New issue 1192: Rotating function for datasets
I would like to request a feature that allows for an arbitrary rotation in 3D around a chosen origin, for all particles in a loaded HDF5 dataset:
e.g. ds_rotated = yt.rotate(ds,[x_angle,y_angle,z_angle],origin)
(The example above should change the positions and velocities of particles in 'ds' and save in a new dataset called ds_rotated)
Pull requests are piling up. Right now we have 42 waiting for the review
(in reality much less, cause there many WIPs, but I wanted to sound more
dramatic). Even though we didn't have official PR triage today I'd
encourage you to look at them if have a spare time today.
New issue 1191: covering_grid with RAMSES dataset
When using covering_grid with RAMSES datasets the cells refined beyond the level of the grid are left unfilled. This is not the case with e.g. ENZO datasets.
You can verify this using:
import matplotlib.pyplot as plt
ds = yt.load('output_00080/info_00080.txt')
cgrid = ds.covering_grid(0, left_edge=ds.domain_left_edge, dims=ds.domain_dimensions)
density_field = cgrid["density"]
print (density_field == 0.0).any() #should be False but it is True
plt.imshow(numpy.log10(density_field[:,:,48].v), interpolation='none') #log10 to highlight the zeros in density_field
plt.show() #holes with zero-density corresponding to refined regions
resulting in the following:
Another (related?) issue is that smoothed_covering_grids fails with RAMSES datasets (raising a RuntimeError because tot != 0, line 880 of construction_data_containers.pyc)