Mailman 3 March 2014 - yt-dev

Issue #817: Astropy raises LoggingError in fits module (yt_analysis/yt)
by Kacper Kowalik 26 Mar '14

26 Mar '14

New issue 817: Astropy raises LoggingError in fits module https://bitbucket.org/yt_analysis/yt/issue/817/astropy-raises-loggingerror-… Kacper Kowalik: Revision d919c3c6e81f causes: ``` #!text $ python -c 'import yt.frontends.fits.data_structures' Traceback (most recent call last): File "<string>", line 1, in <module> File "yt/__init__.py", line 123, in <module> frontends = _frontend_container() File "yt/frontends/api.py", line 40, in __init__ setattr(self, frontend, importlib.import_module(_mod)) File "/home/xarth/yt-x86_64/lib/python2.7/importlib/__init__.py", line 37, in import_module __import__(name) File "yt/frontends/fits/api.py", line 13, in <module> from .data_structures import \ File "yt/frontends/fits/data_structures.py", line 17, in <module> log.disable_exception_logging() File "/home/xarth/yt-x86_64/lib/python2.7/site-packages/astropy-0.4.dev6674-py2.7-linux-x86_64.egg/astropy/logger.py", line 340, in disable_exception_logging raise LoggingError("Exception logging has not been enabled") astropy.logger.LoggingError: Exception logging has not been enabled ``` Responsible: xarthisius

2 1

Issue #819: Octree is not a true depth first traversal (yt_analysis/yt)
by Anonymous 26 Mar '14

26 Mar '14

New issue 819: Octree is not a true depth first traversal https://bitbucket.org/yt_analysis/yt/issue/819/octree-is-not-a-true-depth-f… Anonymous: In order to make yt's octree compatible with Hyperion (and other codes: Sunrise, Turtlebeach), it would be best created in a true depth first manner, rather than pseudo-depth first as it currently is. i.e. http://docs.hyperion-rt.org/en/stable/advanced/indepth_oct.html#indepth-oct Responsible: MatthewTurk

1 0

Issue #818: Test failure in test_particle_octree_counts (yt_analysis/yt)
by Kacper Kowalik 26 Mar '14

26 Mar '14

New issue 818: Test failure in test_particle_octree_counts https://bitbucket.org/yt_analysis/yt/issue/818/test-failure-in Kacper Kowalik: Experimental branch (revision 75033f476463) fails in one of the octree's tests: ``` #!text $ nosetests -v geometry/tests/test_particle_octree.py:test_particle_octree_counts Failure: YTUnitConversionError (Unit dimensionalities do not match. Tried to convert between dimensionless (dim 1) and code_length (dim (length)).) ... ERROR ====================================================================== ERROR: Failure: YTUnitConversionError (Unit dimensionalities do not match. Tried to convert between dimensionless (dim 1) and code_length (dim (length)).) ---------------------------------------------------------------------- Traceback (most recent call last): File ".../nose/loader.py", line 253, in generate for test in g(): File "yt/geometry/tests/test_particle_octree.py", line 94, in test_particle_octree_counts bi2 = dd["all", "mesh_id"] File "yt/data_objects/data_containers.py", line 212, in __getitem__ self.get_data(f) File "yt/data_objects/data_containers.py", line 621, in get_data self._generate_fields(fields_to_generate) File "data_objects/data_containers.py", line 638, in _generate_fields fd = self._generate_field(field) File "yt/data_objects/data_containers.py", line 247, in _generate_field tr = self._generate_particle_field(field) File "yt/data_objects/data_containers.py", line 310, in _generate_particle_field size = self._count_particles(ftype) File "yt/data_objects/data_containers.py", line 341, in _count_particles self.selector, x, y, z) File "yt/data_objects/octree_subset.py", line 250, in count_particles count = selector.count_points(x,y,z) File "selection_routines.pyx", line 459, in yt.geometry.selection_routines.SelectorObject.count_points (yt/geometry/selection_routines.c:7513) File "selection_routines.pyx", line 56, in yt.geometry.selection_routines._ensure_code (yt/geometry/selection_routines.c:2599) File "yt/units/yt_array.py", line 331, in convert_to_units new_units = self._unit_repr_check_same(units) File "yt/units/yt_array.py", line 317, in _unit_repr_check_same self.units, self.units.dimensions, units, units.dimensions) YTUnitConversionError: Unit dimensionalities do not match. Tried to convert between dimensionless (dim 1) and code_length (dim (length)). ``` Responsible: MatthewTurk

1 0

Issue #816: mpi4py is not imported properly in parallel_analysis_interface.py (yt_analysis/yt)
by Kacper Kowalik 26 Mar '14

26 Mar '14

New issue 816: mpi4py is not imported properly in parallel_analysis_interface.py https://bitbucket.org/yt_analysis/yt/issue/816/mpi4py-is-not-imported-prope… Kacper Kowalik: Revision fec39112bec causes: ``` #!text $ python -c 'import yt.utilities.parallel_tools.parallel_analysis_interface' Traceback (most recent call last): File "<string>", line 1, in <module> File "yt/__init__.py", line 116, in <module> from yt.data_objects.api import \ File "yt/data_objects/api.py", line 16, in <module> from grid_patch import \ File "yt/data_objects/grid_patch.py", line 25, in <module> from yt.data_objects.data_containers import \ File "yt/data_objects/data_containers.py", line 32, in <module> from yt.utilities.parallel_tools.parallel_analysis_interface import \ File "yt/utilities/parallel_tools/parallel_analysis_interface.py", line 1015, in <module> communication_system = CommunicationSystem() File "yt/utilities/parallel_tools/parallel_analysis_interface.py", line 587, in __init__ self.communicators.append(Communicator(MPI.COMM_WORLD)) NameError: global name 'MPI' is not defined ``` Responsible: xarthisius

1 0

Issue #815: Tipsy: Plots fail if index, etc. aren't called first (yt_analysis/yt)
by Ben Keller 26 Mar '14

26 Mar '14

New issue 815: Tipsy: Plots fail if index, etc. aren't called first https://bitbucket.org/yt_analysis/yt/issue/815/tipsy-plots-fail-if-index-et… Ben Keller: SlicePlot and ProjectionPlot will fail unless the smoothed fields are setup (I think?). So if field_list or index, etc. are called before the plot routine. If they aren't the plot fails with an indexError thrown. I think this should be a quick fix...

1 0

Issue #814: NMSU-ART periodicity (yt_analysis/yt)
by karraki 26 Mar '14

26 Mar '14

New issue 814: NMSU-ART periodicity https://bitbucket.org/yt_analysis/yt/issue/814/nmsu-art-periodicity karraki: NMSU-ART may have some periodicity issues. Found by examining the number of particles returned after some operation versus the total number of particles in the data set. This occurs within io.py in the read_particle_selection definition comparing the mask and arr sizes. One particle gets masked out. For dd['specie3','particle_mass'].size it should be 2093021 but returns 2093020. version: 19a50ff63350 Responsible: MatthewTurk

1 0

Issue #813: Mass units (yt_analysis/yt)
by Andrew Elvin 26 Mar '14

26 Mar '14

New issue 813: Mass units https://bitbucket.org/yt_analysis/yt/issue/813/mass-units Andrew Elvin: Reads in Bolshoi Planck particle data and prints out maximum value for field ('deposit', 'all_mass'). Value output is on the order of Msun/h and units assigned are grams. current version: 2052f06e3786 Responsible: MatthewTurk

1 0

Importing yt versus importing yt.mods
by Matthew Turk 25 Mar '14

25 Mar '14

Hi all, Some of this was hashed out before on the YTEP-0019 discussion, but I am going through and re-implementing some of that now and I wanted to bring it back to the group. What we had come up with was: * import yt => gets most of the items used in yt in the main namespace * import yt.mods => treats yt more like an application, gets everything but *also* does "startup tasks" Now, the big benefit to making it like this is that you can do: import yt and get everything. The *downside* is that we will no longer be able to do: import yt.something.something_else and *avoid* importing all of yt. I've experimented with the import times and came up with this. All times were computed by running 10 cycles, dividing total time by 10. * 2.6 (current @ bookmark) => 0.45s per import * 3.0, "development" => 0.47s per import * My YTEP-0019 bookmark => 0.97s per import * Import numpy and matplotlib => 0.22s per import * Importing numpy, matplotlib, *and* sympy => 0.78s per import So I think we're doing okay on import times, although I must confess when I initial ran it and saw how slow importing the unitrefactor branch was I was a bit worried. But most of that is sucked up into numpy, matplotlib and sympy. I guess it's not so bad. Here's my PR: https://bitbucket.org/yt_analysis/yt/pull-request/729/ytep-0019/diff (bookmark: ytep0019, which I will delete later.) -Matt

2 3

Old halo objects
by Matthew Turk 24 Mar '14

24 Mar '14

Hi all, With the new halo analysis machinery that Britton, Brian C and Hilary have been working on getting integrated into mainline, do we still need the old halo objects machinery? It seems to me that if we are able to replicate all the functionality, *and* call the old halo finders, we don't need the actual code for "class Halo" and "class HaloFinder" and the like. This is the stuff that's mostly in halo_objects.py in yt/analysis_modules/halo_finding/ . Britton, Brian and Hilary -- does that sound okay to you? -Matt

4 3

Issue #812: Derived quantities on cut_regions don't work (yt_analysis/yt)
by Nathan Goldbaum 24 Mar '14

24 Mar '14

New issue 812: Derived quantities on cut_regions don't work https://bitbucket.org/yt_analysis/yt/issue/812/derived-quantities-on-cut_re… Nathan Goldbaum: This came up while updating the docs. Take a look at the following test script: ``` #!python from yt.mods import * ds = load("enzo_tiny_cosmology/DD0046/DD0046") ad = ds.all_data() total_mass = ad.quantities.total_mass() # now select only gas with 1e5 K < T < 1e7 K. new_region = ad.cut_region(['obj["temperature"] > 1e5', 'obj["temperature"] < 1e7']) cut_mass = new_region.quantities.total_mass() print "The fraction of mass in this temperature range is %f." % \ (cut_mass / total_mass) ``` Running this on the current `experimental` bookmark returns the following traceback: ``` #!python ERROR: ValueError: too many boolean indices [yt.units.yt_array] Traceback (most recent call last): File "test.py", line 7, in <module> cut_mass = new_region.quantities.total_mass() File "/Users/goldbaum/Documents/yt-hg/yt/data_objects/derived_quantities.py", line 194, in __call__ rv = super(TotalMass, self).__call__(fields) File "/Users/goldbaum/Documents/yt-hg/yt/data_objects/derived_quantities.py", line 163, in __call__ rv = super(TotalQuantity, self).__call__(fields) 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 169, in process_chunk for field in fields] 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/selection_data_containers.py", line 696, in get_data self.field_data[field] = self.base_object[field][ind] File "/Users/goldbaum/Documents/yt-hg/yt/units/yt_array.py", line 721, in __getitem__ ret = super(YTArray, self).__getitem__(item) ValueError: too many boolean indices ```

1 0