Test failures on Python 3.5

[fcooper8472]

Describe the bug
Some tests are failing on Python 3.5 (but not 3.6 or 3.7). Examples are in this build:
https://travis-ci.org/tinosulzer/PyBaMM/jobs/503052350

To Reproduce
Steps to reproduce the behaviour:
python3.5 tests/test_discretisations/test_discretisation.py

[fcooper8472]

This seems to be related to the order of items in a dictionary. From Python 3.6 onward, the order appears to be the order of insertion, but this is not guaranteed before.

[fcooper8472]

There's still one test failure:

======================================================================
FAIL: test_process_model_ode (__main__.TestDiscretise)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "tests/test_discretisations/test_discretisation.py", line 384, in test_process_model_ode
    8 * np.ones_like(mesh["negative electrode"].nodes),
  File "/home/fergus/GitRepos/PyBaMM/venv35/lib/python3.5/site-packages/numpy/testing/_private/utils.py", line 896, in assert_array_equal
    verbose=verbose, header='Arrays are not equal')
  File "/home/fergus/GitRepos/PyBaMM/venv35/lib/python3.5/site-packages/numpy/testing/_private/utils.py", line 819, in assert_array_compare
    raise AssertionError(msg)
AssertionError: 
Arrays are not equal

Mismatch: 44.4%
Max absolute difference: 3.
Max relative difference: 1.5
 x: array([5., 5., 5., 5., 5., 5., 5., 5., 5., 5., 5., 5., 5., 5., 5., 5., 5.,
       5., 5., 5., 5., 5., 5., 5., 5., 5., 5., 5., 5., 5., 5., 5., 5., 5.,
       5., 5., 5., 5., 5., 5., 2., 2., 2., 2., 2., 2., 2., 2., 2., 2., 2.,...
 y: array([2., 2., 2., 2., 2., 2., 2., 2., 2., 2., 2., 2., 2., 2., 2., 2., 2.,
       2., 2., 2., 2., 2., 2., 2., 2., 2., 2., 2., 2., 2., 2., 2., 2., 2.,
       2., 2., 2., 2., 2., 2., 2., 2., 2., 2., 2., 2., 2., 2., 2., 2., 2.,...

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

I don't understand what's going on here...

[fcooper8472]

Aah - there's a dictionary of initial conditions

model.initial_conditions = {
            c: pybamm.Scalar(2),
            T: pybamm.Scalar(5),
            S: pybamm.Scalar(8),
        }

so the concatenation isn't guaranteed to be in the order 2 -> 5 -> 8.

[fcooper8472]

There's more:

c0, T0, S0 = np.split(
    y0, np.cumsum([combined_submesh.npts, mesh["negative electrode"].npts])
)

assumes that y0 has the ordering c -> T -> S, which is not (guaranteed) to be the case before Python 3.7.

This is going to be difficult to get around in general.

[valentinsulzer]

Is the issue just fixing the tests in test_discretise.py? One workaround instead of using np.split would be to use the slices, e.g.

c0 = c.evaluate(0,y0)

but that might make the test redundant.

I don't think there's any reason why the rhs dict needs to be ordered, except the concatenation needs to happen in the same order as the concatenation of the initial conditions, but it seems _concatenate_init takes care of that (might be worth an extra test to make sure).

Stupid idea: would something like from future import dict work? Or is that only a Python2 -> Python3 thing?

[martinjrobins]

note, looks like numpy v 1.16 is required to install scikits.odes?

numpy/numpy#11871 (comment)