New issue 725: off_axis_projection example gives blank image
from yt.mods import *
pf = load("HiresIsolatedGalaxy/DD0044/DD0044")
L = [1,1,0] # vector normal to cutting plane
north_vector = [-1,1,0]
W = [0.02, 0.02, 0.02]
c = [0.53, 0.53, 0.53]
N = 512
image = off_axis_projection(pf, c, L, W, N, "Density")
write_image(na.log10(image), "%s_offaxis_projection.png" % pf)
produce blank image and fails on `log10`. This snippet is a part of `source/visualizing/plots.rst`. I think the problem is caused by `W` but haven't investigated this in details. Also `na` should be changed to `np` ;-)
There is a very interesting conversation going on over on the numfocus list about a distributed build service for the numfocus ecosystem: https://groups.google.com/forum/#!topic/numfocus/mVNakFqfpZg
I’m forwarding this message from Anthony since he mentions yt. I’m hopeful that in the end this discussion leads to something concrete and useful for our users.
On November 14, 2013 at 12:16:44 AM, Anthony Scopatz (scopatz(a)gmail.com) wrote:
I'd like to volunteer to be the person to spearhead this effort, or at least be the manager/organizer of this effort. Normally I wouldn't do this (I have enough on my plate) but the build and distribution problems have become the central issue for PyNE in the past 10 days . On Monday Nov. 4th, Katy hosted a PyNE workshop at UC Berkeley. Out of the ~15 attendees, 2 could successfully install PyNE...even using anaconda and/or canopy and ignoring our optional dependencies. We absolutely have to solve this problem for the project to survive. The PyNE stack fairly standard for this community. The fact that we have had such terrible install problems is really a serious issue. We are going to dedicate the next release to fixing this problem rather than doing any nuclear engineering.
Furthermore, I don't think that this is a wholly unique situation as I know other codes, such as yt, have experienced similar difficulties in this space.
I believe that to fix this problem sufficiently we must have empathy for our users, rather than for ourselves as developers. We need to be open to installing packages in the way the user is comfortable with even though it may make more work for us.
Many of the problems I feel stem from wanting to support a public API for many languages simultaneously (C/C++/Python/Fortran). PyNE is not unique in this way. NumPy also does this. However, the dependency pool for PyNE is much broader and deeper than for NumPy. Additionally as Aaron brings up, we aren't really just talking about supporting Python & Cython code. By virtue of our dependencies, we also have to support packages in these compiled libraries.
I have many ideas about how to go about this process, though it will require help from many people. I believe all of the pieces are there to do this right, but what we need is a coordinated strategy, someone to carve up tasks appropriately, and someone to make sure that this process doesn't take too long. Again, I am happy to be the cat-wrangler, if for no other reason than that PyNE will be going through this shortly.
Travis-ci, vms, etc, have come up quite a bit so far on this thread. As others have noted, this is the right idea but insufficiently executed. Therefore, I'd like to direct folks to the Build & Test Lab (BaTLab). This is an NSF funded organization whose purpose it is to provide an integrated suite of platforms for building and testing scientific software. Even though it is at UW-Madison, it is open to everyone and free to use. The advantage here is that BaTLab jobs can take as long as they need to and it already supports the platforms we need in many flavors: Windows, Mac, Linux. For another project (cyclus), I am working on a little web app which exposes Travis-CI-like functionality but is backended by BaTLab. Hopefully this will be in a working state by this weekend. Basically, there is no need for us to build the infrastructure! Or at lease no need to do so in the short- to medium-term.
I think if every project were able to donate a person or two to work on this for the next month we really could get something working that truly addressed or routed around some of the fundamental flaws with the current system.
In summary, we (PyNE +/- yt) can run off and solve this for ourselves -OR- we (NumFOCUS) can help pool our resources and try to create a quality solution that applies to everyone. Sorry if this is a bit ranty, but it has become difficult for me to sell Python & PyNE because of building and distribution. This is long overdue and I am willing to put my money where my mouth is. If someone has better ideas, I'd love to hear them!
New issue 722: create_profile does not recognize field_parameters
Making a profile using ``create_profile`` with a field that requires a field_parameter (such as Radius) does not work.
For example, the following script should work (with the new ProfilePlot functionality):
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/Users/britton/Documents/work/yt/yt-x86_64/src/yt-britton/yt/data_objects/profiles.py", line 1037, in create_profile
File "/Users/britton/Documents/work/yt/yt-x86_64/src/yt-britton/yt/data_objects/profiles.py", line 819, in add_fields
self._bin_grid(g, fields, temp_storage)
File "/Users/britton/Documents/work/yt/yt-x86_64/src/yt-britton/yt/data_objects/profiles.py", line 891, in _bin_grid
gd = self._get_data(grid, fields)
File "/Users/britton/Documents/work/yt/yt-x86_64/src/yt-britton/yt/data_objects/profiles.py", line 849, in _get_data
bin_fields = [grid[bf] for bf in self.bin_fields]
File "/Users/britton/Documents/work/yt/yt-x86_64/src/yt-britton/yt/data_objects/grid_patch.py", line 147, in __getitem__
File "/Users/britton/Documents/work/yt/yt-x86_64/src/yt-britton/yt/data_objects/grid_patch.py", line 190, in get_data
File "/Users/britton/Documents/work/yt/yt-x86_64/src/yt-britton/yt/data_objects/grid_patch.py", line 122, in _generate_field
File "/Users/britton/Documents/work/yt/yt-x86_64/src/yt-britton/yt/data_objects/field_info_container.py", line 356, in check_available
File "/Users/britton/Documents/work/yt/yt-x86_64/src/yt-britton/yt/data_objects/field_info_container.py", line 432, in __call__
New issue 721: PlotCollection mentioned in "Sharing Data" docs
This is mentioned in the context of using PlotCollection.hub_upload. Now that PlotCollection is being removed from every other place in the docs, we should figure out what to do with this.
I don't mind taking care of this, but I'd like to hear whether it's ok to just get rid of this. @MatthewTurk, what do you think?
New issue 719: Remove all references to PlotCollection
Now that PlotCollection has been phased out, we need to remove all the references in the docs to them, and substitute them with the appropriate replacement functions: SlicePlot, ProjectionPlot, PhasePlot, etc.
@MatthewTurk or @ngoldbaum are either of you up for this?
New issue 718: Convenience method to get the number of particles in a simulation
It should be possible to do something like:
pf = load(...)
nparticles = pf.h.number_of_particles
Right now (as far as I can tell with enzo data) one needs to iterate over all the grids, accumulating particle counts along the way. This data has to be known once the hierarchy is parsed so I think it should be straightforward to add this.
What do you think @MatthewTurk?