On Sun, Jun 12, 2016 at 6:47 PM, Rasmi Elasmar email@example.com wrote:
I'm running into more issues with Halo Catalogs and units. I'm not sure if the last PR https://bitbucket.org/yt_analysis/yt/pull-requests/2208/ is causing this or not.
It might very well be.
I'm running the latest code from the repo as of right now (fd8796c8e06d). Here's the error, generated on this data https://drive.google.com/open?id=0BwK-7Z3S5X_yMDNyZ1RTcG56SFU with this script https://gist.github.com/rasmi/6cf6017b50277390735dd484c120855f.
Thanks! If you don't spot the fix, I'll try to take a look at this tomorrow.
RuntimeWarning: divide by zero encountered in divide return super(YTArray, self).__div__(ro) Traceback (most recent call last): File "/work/03330/tg826294/applications/scripts/findhalos.py", line 65, in <module> hc.create() File "/work/03330/tg826294/applications/pythonenv/lib/python2.7/site-packages/yt-3.3.dev0-py2.7-linux-x86_64.egg/yt/analysis_modules/halo_analysis/halo_catalog.py", line 335, in create self._run(save_halos, save_catalog, njobs=njobs, dynamic=dynamic) File "/work/03330/tg826294/applications/pythonenv/lib/python2.7/site-packages/yt-3.3.dev0-py2.7-linux-x86_64.egg/yt/utilities/parallel_tools/parallel_analysis_interface.py", line 302, in barrierize return func(args, **kwargs) File "/work/03330/tg826294/applications/pythonenv/lib/python2.7/site-packages/yt-3.3.dev0-py2.7-linux-x86_64.egg/yt/analysis_modules/halo_analysis/halo_catalog.py", line 427, in _run action(new_halo) File "/work/03330/tg826294/applications/pythonenv/lib/python2.7/site-packages/yt-3.3.dev0-py2.7-linux-x86_64.egg/yt/analysis_modules/halo_analysis/halo_callbacks.py", line 60, in __call__ self.function(halo, self.args, **self.kwargs) File "/work/03330/tg826294/applications/pythonenv/lib/python2.7/site-packages/yt-3.3.dev0-py2.7-linux-x86_64.egg/yt/analysis_modules/halo_analysis/halo_callbacks.py", line 571, in iterative_center_of_mass sphere = halo.halo_catalog.data_ds.sphere(center_orig, halo.quantities[radius_field]) File "/work/03330/tg826294/applications/pythonenv/lib/python2.7/site-packages/yt-3.3.dev0-py2.7-linux-x86_64.egg/yt/data_objects/selection_data_containers.py", line 649, in __init__ if radius < self.index.get_smallest_dx(): File "/work/03330/tg826294/applications/pythonenv/lib/python2.7/site-packages/yt-3.3.dev0-py2.7-linux-x86_64.egg/yt/units/yt_array.py", line 1095, in __lt__ return super(YTArray, self).__lt__(oth) File "/work/03330/tg826294/applications/pythonenv/lib/python2.7/site-packages/yt-3.3.dev0-py2.7-linux-x86_64.egg/yt/units/yt_array.py", line 1225, in __array_wrap__ raise YTUfuncUnitError(context, unit1, unit2) yt.utilities.exceptions.YTUfuncUnitError: The NumPy <ufunc 'less'> operation is only allowed on objects with identical units. Convert one of the arrays to the other's units first. Received units (code_length) and (code_length).
This means you're directly comparing units from two different datasets (maybe the halo catalog dataset and the original dataset?). If these two are identical, this should work, but maybe there's a bug in the handling for that.
is supposed to take care of this case - so I guess the bug is there? I
don't think users should hit this exception unless they're using a ufunc
directly. (i.e. np.less, not a < b).
Has anyone run into this before? yt seems to think these two units aren't the same -- is it possible the HaloCatalog unit import is being done incorrectly? At this point, I haven't written anything to the disk, so I'm not sure what the issue might be.
Sorry for the trouble and thanks for the careful report. If you file an issue to track this we can move further discussion there:
yt-dev mailing list firstname.lastname@example.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org