Tracebacks in test output

[mdickinson]

When running the test suite under unittest, there are tracebacks printed to the console. We should discover why those tracebacks are being printed, and either suppress the output (if it's harmless), or fix it (if not).

Steps to reproduce:

1. Create and activate a new Python 3.11 venv with python -m venv --clear ~/.venvs/scimath && source ~/.venvs/scimath/bin/activate (with the venv location of your choice, of course)
2. Install scimath into the venv with python -m pip install -e .
3. Run the test suite with python -m unittest

For me, this gives the following output:

(scimath) mdickinson@mirzakhani scimath % python -m unittest
1d block_average_above (sec): 8.917192462831736e-05
.scipy interp1d (sec): 0.013110005063936114
.1d interp (sec): 0.00018173002172261477
.fast interpolate (sec): 0.012866706005297601
..........................................................................................................................................................................................................................................................................................................................................................................................Unrecognized unit system m
Traceback (most recent call last):
  File "/Users/mdickinson/Enthought/ETS/scimath/scimath/units/unit_manager.py", line 207, in get_unit_system
    raise Exception
Exception
Unrecognized unit system m
Traceback (most recent call last):
  File "/Users/mdickinson/Enthought/ETS/scimath/scimath/units/unit_manager.py", line 207, in get_unit_system
    raise Exception
Exception
.....................
----------------------------------------------------------------------
Ran 402 tests in 0.337s

OK

[homosapien-lcy]

I found that the Exception comes from get_unit_system function in scimath.unit.unit_manager. The cause is the function is given an instance from the scimath.units.smart_unit.SmartUnit which cannot be handled by the current get_unit_system method.

With further traceback (using traceback.print_stack()), the problem happens in class Quantity function propagate_data_changes, line new_quantity = self.change_unit_system(predecessor.units). Here, the change_unit_system expects a system or str, but given a unit.

[homosapien-lcy]

It seems that the neither the scimath.units.smart_unit nor the scimath.units.unit class has a unit system associate with it. And I haven't find any function that can infer the unitsystem from a unit. Maybe we can just give None to this self.change_unit_system (i.e., quantity.py line 306: new_quantity = self.change_unit_system(predecessor.units) -> new_quantity = self.change_unit_system(None)) that is causing the problem? This will uses the default_system (which works the same as right now)

[mdickinson]

Maybe we can just give None to this self.change_unit_system

I doubt that would work as intended. Here's another test case that should work, but I think will break with current code.
(So indeed those tracebacks indicate a real bug, not just a problem with the tests.)

    def test_propagation2(self):
        """ Tests data propagation for a single converted quantity. """

        q1 = Quantity(10.0, units='ft', family_name='depth')
        q2 = q1.change_unit_system('METRIC')
        q2.data = 2 * q2.data
        q2.propagate_data_changes()
        self.assertAlmostEqual(q1.data, 20.0)

When I add the above test method to the test_units class and run the test suite, I get the following failure:

======================================================================
FAIL: test_propagation2 (scimath.units.tests.test_units.test_units)
Tests data propagation for a single converted quantity.
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/mdickinson/Enthought/ETS/scimath/scimath/units/tests/test_units.py", line 207, in test_propagation2
    self.assertAlmostEqual(q1.data, 20.0)
AssertionError: 6.096 != 20.0 within 7 places (13.904 difference)

----------------------------------------------------------------------

[mdickinson]

@homosapien-lcy I think you can fix this by avoiding unit systems entirely in propagate_data_changes: instead, simply use the units of the current Quantity instance (self, in the propagate_data_changes method) and the units of the predecessor to compute the new data value for the predecessor. You should be able to use the units.convert function for this.

Please also add the new test that appeared in my previous comment (possibly with a better name for the test method).

[homosapien-lcy]

Thanks for the comment, I made the update in PR #174. I also checked the other change_unit_system function calls, I think they are either using str unit system or None, so seems to be fine.