Inconsistently appearing exception with conversion_plus technologies

[sjpfenninger]

Shows up in test_model_conversion.py and in test_model_export.py, but not always. Running tests over and over again will eventually lead to an exception:

calliope/test/test_model_conversion.py:52: in create_and_run_model
    model.run()
calliope/core.py:1416: in run
    self.load_solution()
calliope/core.py:1588: in load_solution
    self.process_solution()
calliope/core.py:1550: in process_solution
    md = self.get_metadata()
calliope/core.py:1774: in get_metadata
    lambda y: self.get_carrier(y, direction='in', all_carriers=True))
../../../../Anaconda/envs/calliope/lib/python3.6/site-packages/pandas/core/indexes/base.py:2780: in map
    names=attributes.get('name'))
../../../../Anaconda/envs/calliope/lib/python3.6/site-packages/pandas/core/indexes/multi.py:1144: in from_tuples
    arrays = list(lib.tuples_to_object_array(tuples).T)
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

>   ???
E   TypeError: Expected tuple, got str

tuples contains :

(Pdb) p tuples
array([('power', 'heat', 'gas'), 'resource', 'heat', 'low_T', 'resource',
       'resource', 'power', 'resource', 'resource', 'resource', 'V_low_T',
       'power'], dtype=object)

[sjpfenninger]

Appears to be limited to pandas 0.20.

[sjpfenninger]

Downgrading to pandas 0.19 for now in 901dff4

[sjpfenninger]

Related to the random order of technologies set, y.

If a conversion plus tech is first, e.g. test_conversion_plus in the test cases, a tuple is returned for self.get_carrier(y, direction='in', all_carriers=True). This trips up a pandas helper function which then expects more tuples, but gets only strings.

[brynpickering]

This causes issues with saving to a NetCDF solution file (if using the newest version of Pyomo), as the tuples in the metadata DataArray trip it up. Solution file fails to save, which only comes up as an issue after optimisation (so there is no solution file available after several hours of computational work...)

[brynpickering]

Temporarily solved by keeping Pandas version below 0.20.0. Long term solution is to avoid mixed dtypes in the input.output xarray Dataset