BUG: always cast enzo units to float

[chrishavlin]

PR Summary

In some cases, the mass units set in enzo's _set_code_unit_attributes can remain integers. and if that integer is too large, you end up with overflow errors during unyt operations. This PR ensures the base units are all floats.

original bug

Reported on slack, here's the stack trace:

IterableUnitCoercionError                 Traceback (most recent call last)
<ipython-input-2-415bc8b3c320> in <module>
----> 1 ds = yt.load("/scratch/p/pen/xinyuli/enzo_run/mTDE/DD0000/DD0000")

~/py3/lib/python3.8/site-packages/yt/_maintenance/deprecation.py in inner(*args, **kwargs)
     71                     **depr_kwargs,
     72                 )
---> 73             return func(*args, **kwargs)
     74 
     75         return inner

~/py3/lib/python3.8/site-packages/yt/loaders.py in load(fn, hint, *args, **kwargs)
    125 
    126     if len(candidates) == 1:
--> 127         return candidates[0](fn, *args, **kwargs)
    128 
    129     if len(candidates) > 1:

~/py3/lib/python3.8/site-packages/yt/frontends/enzo/data_structures.py in __init__(self, filename, dataset_type, parameter_override, conversion_override, storage_filename, units_override, unit_system, default_species_fields)
    698         self._conversion_override = conversion_override
    699         self.storage_filename = storage_filename
--> 700         Dataset.__init__(
    701             self,
    702             filename,

~/py3/lib/python3.8/site-packages/yt/data_objects/static_output.py in __init__(self, filename, dataset_type, units_override, unit_system, default_species_fields, axis_order)
    309 
    310         self._parse_parameter_file()
--> 311         self.set_units()
    312         self.setup_cosmology()
    313         self._assign_unit_system(unit_system)

~/py3/lib/python3.8/site-packages/yt/data_objects/static_output.py in set_units(self)
   1414                 self.unit_registry.modify("a", 1 / (1 + self.current_redshift))
   1415 
-> 1416         self.set_code_units()
   1417 
   1418     def setup_cosmology(self):

~/py3/lib/python3.8/site-packages/yt/data_objects/static_output.py in set_code_units(self)
   1469 
   1470         # set attributes like ds.length_unit
-> 1471         self._set_code_unit_attributes()
   1472 
   1473         self.unit_registry.modify("code_length", self.length_unit)

~/py3/lib/python3.8/site-packages/yt/frontends/enzo/data_structures.py in _set_code_unit_attributes(self)
    975             setdefaultattr(self, "velocity_unit", self.length_unit / self.time_unit)
    976 
--> 977         density_unit = self.mass_unit / self.length_unit**3
    978         magnetic_unit = np.sqrt(4 * np.pi * density_unit) * self.velocity_unit
    979         magnetic_unit = np.float64(magnetic_unit.in_cgs())

~/py3/lib/python3.8/site-packages/unyt/array.py in __array_ufunc__(self, ufunc, method, *inputs, **kwargs)
   1821             i1 = inputs[1]
   1822             # coerce inputs to be ndarrays if they aren't already
-> 1823             inp0 = _coerce_iterable_units(i0)
   1824             inp1 = _coerce_iterable_units(i1)
   1825             u0 = getattr(i0, "units", None) or getattr(inp0, "units", None)

~/py3/lib/python3.8/site-packages/unyt/array.py in _coerce_iterable_units(input_object, registry)
    284         ret = np.asarray(input_object)
    285     if ret.dtype.char in DISALLOWED_DTYPES:
--> 286         raise IterableUnitCoercionError(str(input_object))
    287     return ret
    288 

IterableUnitCoercionError: Received an input or operand that cannot be converted to a unyt_array with uniform units: 171601543693000000000000000000000000 g

The underlying problem is that 171601543693000000000000000000000000 is too big... e.g.,

x = np.array([171601543693000000000000000000000000,])
x.dtype
dtype('O')

if you force a type int you get an error:

x = np.array([171601543693000000000000000000000000,], dtype=int)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OverflowError: Python int too large to convert to C long

but casting to float is fine.

[chrishavlin]

oh, just realized the original bug was reported with python 3.8, so the yt version is probably old as well. might be that it's impossible for the mass unit to remain an int by the time it gets through all the unyt operations that happen, this fix might not be needed. will find out if the bug persists in current yt before un-drafting this (I was kinda surprised mass_unit could remain an int...).

[chrishavlin]

@neutrinoceros unrelated aside, but there's no frontend: enzo label, just enzo-e :)

[neutrinoceros]

I never got around to creating all these labels, feel free to add the ones you see missing !

[chrishavlin]

oh! i can add labels! didn't realize that. done.