Mailman 3 March 2013 - yt-dev

chunk size undefined before fill
by Douglas Harvey Rudd March 14, 2013

March 14, 2013

Hi Matt, I just pushed a change to my fork that changes the way the data_size property of our ARTIOChunk (same as old DomainSubset) is exposed. This catches cases when .data_size is read before a fill is called. You reordered calls somewhere in the main code that was causing this to fail for SlicePlot, but now I am running into it for ProjectionPlot. from yt.mods import * pf = load("tests/artdat/… [View More]sizmbhloz-clref04SNth-rs9_a0.9011.art") ProjectionPlot(pf, "x", "Density", width = (100,'kpc') ).save() leads to yt : [ERROR ] 2013-03-14 10:39:05,002 ARTIOChunk.data_size called before fill I've tracked it back to this line in YTSelectionContainer._chunked_read old_size, self.size = self.size, chunk.data_size Here is the traceback: File "./testprojection.py", line 4, in <module> ProjectionPlot(pf, "x", "Density", width = (100,'kpc') ).save() File "/Users/drudd/Programs/yt-x86_64/src/yt-hg/yt/visualization/plot_window.py", line 1336, in __init__ center=center, field_parameters = field_parameters) File "/Users/drudd/Programs/yt-x86_64/src/yt-hg/yt/data_objects/construction_data_containers.py", line 243, in __init__ self.get_data(field) File "/Users/drudd/Programs/yt-x86_64/src/yt-hg/yt/data_objects/construction_data_containers.py", line 283, in get_data for chunk in self.data_source.chunks(None, "io"): File "/Users/drudd/Programs/yt-x86_64/src/yt-hg/yt/data_objects/data_containers.py", line 448, in chunks with self._chunked_read(chunk): File "/Users/drudd/Programs/yt-x86_64/lib/python2.7/contextlib.py", line 17, in __enter__ return self.gen.next() File "/Users/drudd/Programs/yt-x86_64/src/yt-hg/yt/data_objects/data_containers.py", line 525, in _chunked_read import traceback; traceback.print_stack() It looks like the problem is the attempt to save state in _chunked_read while _chunk iterates to call .get_data. Since size is just a wrapper around the chunk.data_size, would it be better to have something like this: _size = None @property def size(self) : if self._size is None : if not self._current_chunk is None : self._size = self._current_chunk.data_size return self._size and def _chunked_read(self, chunk): # There are several items that need to be swapped out # field_data, size, shape old_field_data, self.field_data = self.field_data, YTFieldData() old_chunk, self._current_chunk = self._current_chunk, chunk self._size = None old_locked, self._locked = self._locked, False yield self.field_data = old_field_data self._current_chunk = old_chunk self._size = None self._locked = old_locked That may just push the problem further down the call stack, but at least means this code won't ask for .get_size until needed. Douglas Rudd Scientific Computing Consultant Research Computing Center drudd(a)uchicago.edu [View Less]

2 3

yt-3.0 derived fields
by Christopher Moody March 14, 2013

March 14, 2013

Hi everyone, Fields in yt-3.0 are now defined like (field_type,field_name) but for backwards-compatibility still maintains a field_name -> ("all",field_name) mapping. Consider a few use cases: keys = ["ParticleMassMsun", ("all","ParticleMassMsun"), ("stars","particle_mass"), ("stars","ParticleMassMsun") ]#broken I think we all have natural expectations for what should happen, but at the moment the last key in the series is broken. particle_mass is a native field, … [View More]

6 14

YTArray YTEP
by Matthew Turk March 13, 2013

March 13, 2013

Hi all, Last week the units stuff really took off -- great work on that front! I was wondering if I might solicit a YTEP? As I have been going through the YTArray changes to get the unit tests passing, I'm realizing just how invasive it is in some ways. I think having an enumeration of the behavior of the YTArray under ufuncs as well as common operations will be pretty essential. That is something we should also probably discuss on this list. I'll be submitting a few changes for review by … [View More]

5 16

Fwd: [AstroPy] Astronomy & Astrophysics Mini-Symposium at SciPy2013
by Matthew Turk March 13, 2013

March 13, 2013

Hi all, I'm not sure that this has made it here before, but I wanted to forward it with a note that the SciPy conference is really a lot of fun. I'll be there, and co-organizing some of the Birds of a Feather sessions, and there should also be ample opportunity to learn about other Python projects both in astronomy and out of astronomy. I'd highly encourage attending, as it's really a fun conference with lots of diverse domains represented. The call for abstracts is *very* soon, and if you … [View More]have something you'd like to present I would encourage you to submit! -Matt ---------- Forwarded message ---------- From: Tom Aldcroft <aldcroft(a)head.cfa.harvard.edu> Date: Thu, Feb 28, 2013 at 4:08 PM Subject: [AstroPy] Astronomy & Astrophysics Mini-Symposium at SciPy2013 To: astropy <astropy(a)scipy.org> Dear colleagues, We are planning to have an Astronomy & Astrophysics Mini-Symposium at the SciPy2013 conference in Austin, TX in June 2013 [1]. The use of Python for astronomy research is growing rapidly, and we have seen the emergence of large and well-organized community efforts to develop analysis packages for astronomy. I'm excited to have the opportunity to organize and chair this mini-symposium. This is timely moment for the astronomy Python community to get together and present what's new and exciting, as well as to discuss and define future priorities. This will be an evening session taking 1.5 hours and consisting of 4 - 6 talks and some form of open discussion. I'd like to encourage everybody to attend SciPy2013 this year and participate in the overall discussion. We need viewpoints not only from people deeply involved in development, but also newcomers and those who are just trying to get their research done. I also want to specifically invite people to submit a talk or poster abstract so we can make the mini-symposium interesting. The abstract deadline is March 20. If you have questions or suggestions please contact me or post to this list as appropriate. Please forward this message to your colleagues who may not be on this list. I'm interested in ideas for discussion topics that would be productive. One possibility is examining some of the large community efforts (e.g. yt, SunPy, Astropy, etc) to look for opportunities for cross-project coordination. Best regards, Tom Aldcroft [1] http://conference.scipy.org/scipy2013/ _______________________________________________ AstroPy mailing list AstroPy(a)scipy.org http://mail.scipy.org/mailman/listinfo/astropy [View Less]

1 0

Clarification of particle fields
by Douglas Harvey Rudd March 13, 2013

March 13, 2013

Hi all, We've been working on adding particle support to our ARTIO frontend and matching ART particle species to YT. I'd like a clarification of the expected behavior of "all" when dealing with particles. In ART, there are some variables (fields) that are only associated with a subset of particles. Mainly this happens for stars, of course, but might also occur for hydrodynamic tracers, etc. The current behavior, if I understand it, is to load 0 for any particle that does not have the … [View More]

2 1

[yt_analysis/yt] setup.py install fails if fortran kd tree isn't built (issue #524)
by Nathan Goldbaum March 12, 2013

March 12, 2013

--- you can reply above this line --- New issue 524: setup.py install fails if fortran kd tree isn't built https://bitbucket.org/yt_analysis/yt/issue/524/setuppy-install-fails-if-for… Nathan Goldbaum: As discovered by JC Passy found on the user's list, the setup script will fail if the fortran KD tree isn't built. This will only break builds that try to install yt via setup.py install rather than setup.py develop. Responsible: ngoldbaum -- This is an issue notification from bitbucket.org. … [View More]

1 0

[yt_analysis/yt] unable to control colorbar as log or linear with set_log() (issue #523)
by gsiisg March 9, 2013

March 9, 2013

--- you can reply above this line --- New issue 523: unable to control colorbar as log or linear with set_log() https://bitbucket.org/yt_analysis/yt/issue/523/unable-to-control-colorbar-a… gsiisg: I first encountered this bug because I wanted to show a derived field as log scale, but unable to using ProjectionPlot. But it turns out I'm unable to specify the colorbar scale as log or linear using the keyword argument set_log() From G.S. -- This is an issue notification from bitbucket.org. … [View More]

1 0

[yt_analysis/yt] Unified Halo Analysis (issue #522)
by Britton Smith March 8, 2013

March 8, 2013

--- you can reply above this line --- New issue 522: Unified Halo Analysis https://bitbucket.org/yt_analysis/yt/issue/522/unified-halo-analysis Britton Smith: Currently, all the components of halo analysis (halo finding, merger tree generation, and halo profiling) are separate entities that don't really talk to each other. For example, analyzing how a single halo evolves in various properties over time requires a lot code from the user to connect all of these components. There needs to be … [View More]

1 0

YTEP-0002
by Matthew Turk March 8, 2013

March 8, 2013

Hi all, Just a note that in the current yt-3.0 branch, we have *not* implemented YTEP-0003: https://ytep.readthedocs.org/en/latest/YTEPs/YTEP-0003.html However, in the units refactor branch, it *has*. Additionally, note that the units YTEP is still under development, but the implementation has preceded the specification at this time. Currently the main yt-3.0 fork (yt_analysis/yt-3.0) includes a full suite of passing unit tests; this will form the basis of yt-3.0a1, which is slated for … [View More]

1 0

[yt_analysis/yt] YTSlice no longer has a data_source argument (issue #521)
by Matthew Turk March 8, 2013

March 8, 2013

--- you can reply above this line --- New issue 521: YTSlice no longer has a data_source argument https://bitbucket.org/yt_analysis/yt/issue/521/ytslice-no-longer-has-a-data… Matthew Turk: In 3.0 the YTSlice needs to have a `data_source` argument. This will require chaining selectors. Responsible: MatthewTurk -- This is an issue notification from bitbucket.org. You are receiving this either because you are the owner of the issue, or you are following the issue.

1 0