yt-dev November 2013

yt-dev@python.org

16 participants
44 discussions

Issue #725: off_axis_projection example gives blank image (yt_analysis/yt)

by Kacper Kowalik

New issue 725: off_axis_projection example gives blank image https://bitbucket.org/yt_analysis/yt/issue/725/off_axis_projection-example-… Kacper Kowalik: Following receipe: ``` #!python 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` ;-) Responsible: ngoldbaum

7 years, 8 months

Fw: Re: [numfocus] Community build service (starting with Windows)

by Nathan Goldbaum

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: Hello All, 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 [1]. 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! Be Well Anthony 1. https://groups.google.com/d/topic/pyne-dev/RxNCHvZAAEQ/discussion

7 years, 8 months

Issue #724: Incorrect colorbar placement for non-square plots. (yt_analysis/yt)

by Nathan Goldbaum

New issue 724: Incorrect colorbar placement for non-square plots. https://bitbucket.org/yt_analysis/yt/issue/724/incorrect-colorbar-placement… Nathan Goldbaum: ```python from yt.mods import * pf = load('IsolatedGalaxy/galaxy0030/galaxy0030') sp = SlicePlot(pf,2, "KineticEnergy") sp.set_width((1,'unitary'),(0.5,'unitary')) sp.save() ``` ![](http://imgur.com/yFHVN5W) Responsible: ngoldbaum

7 years, 8 months

Issue #723: add_grad and length units (yt_analysis/yt)

by John ZuHone

New issue 723: add_grad and length units https://bitbucket.org/yt_analysis/yt/issue/723/add_grad-and-length-units John ZuHone: The units for derivatives calculated using ``add_grad`` don't convert the length units of the derivative to centimeters first. Responsible: jzuhone

7 years, 8 months

Issue #722: create_profile does not recognize field_parameters (yt_analysis/yt)

by Britton Smith

New issue 722: create_profile does not recognize field_parameters https://bitbucket.org/yt_analysis/yt/issue/722/create_profile-does-not-reco… Britton Smith: 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): http://paste.yt-project.org/show/4050/ But gives: 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 obj.add_fields(fields) 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__ self.get_data(key) File "/Users/britton/Documents/work/yt/yt-x86_64/src/yt-britton/yt/data_objects/grid_patch.py", line 190, in get_data self._generate_field(field) File "/Users/britton/Documents/work/yt/yt-x86_64/src/yt-britton/yt/data_objects/grid_patch.py", line 122, in _generate_field self.pf.field_info[field].check_available(self) File "/Users/britton/Documents/work/yt/yt-x86_64/src/yt-britton/yt/data_objects/field_info_container.py", line 356, in check_available validator(data) File "/Users/britton/Documents/work/yt/yt-x86_64/src/yt-britton/yt/data_objects/field_info_container.py", line 432, in __call__ raise NeedsParameter(doesnt_have) yt.data_objects.field_info_container.NeedsParameter: (['center']) Responsible: MatthewTurk

7 years, 8 months

Issue #721: PlotCollection mentioned in "Sharing Data" docs (yt_analysis/yt)

by Britton Smith

New issue 721: PlotCollection mentioned in "Sharing Data" docs https://bitbucket.org/yt_analysis/yt/issue/721/plotcollection-mentioned-in-… Britton Smith: 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? Responsible: brittonsmith

7 years, 8 months

Issue #720: create cookbook recipe for making a multiplot image incorporating PlotWindow (yt_analysis/yt)

by Cameron Hummels

New issue 720: create cookbook recipe for making a multiplot image incorporating PlotWindow https://bitbucket.org/yt_analysis/yt/issue/720/create-cookbook-recipe-for-m… Cameron Hummels: Responsible: chummels

7 years, 8 months

Issue #719: Remove all references to PlotCollection (yt_analysis/yt)

by Cameron Hummels

New issue 719: Remove all references to PlotCollection https://bitbucket.org/yt_analysis/yt/issue/719/remove-all-references-to-plo… Cameron Hummels: 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?

7 years, 8 months

yt-fido on the rampage

by Kacper Kowalik

Hi, Please ignore recent comments by yt-fido. Atlassian devs changed their API and for a brief moment testing went wild. Cheers, Kacper

7 years, 8 months

Issue #718: Convenience method to get the number of particles in a simulation (yt_analysis/yt)

by Nathan Goldbaum

New issue 718: Convenience method to get the number of particles in a simulation https://bitbucket.org/yt_analysis/yt/issue/718/convenience-method-to-get-th… Nathan Goldbaum: It should be possible to do something like: ``` #!python 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?

7 years, 8 months

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

yt-dev November 2013