Add ability to sort SolutionArray objects

[ischoegl]

Please fill in the issue number this pull request is fixing:

Fixes #625

Changes proposed in this pull request:

• implements sort method for 1D SolutionArray objects
• adds some simple type checks for an instantiation with states not None

Intended usage:

# create SolutionArray and add items with `tau` not following an increasing order
states = ct.SolutionArray(gas, extra=('tau',))
...
states.sort('tau')

Some observations:

• Sorting of higher-dimensional SolutionArray objects is not clearly defined
• Difference/necessity of apparently duplicate SolutionArray._extra_lists and SolutionArray._extra_arrays dictionaries is not clear
• SolutionArray._extra_lists is apparently only used in SolutionArray.__call__ (docstring is missing ... it works as copying constructor that extracts species, but usage is not clear)

[bryanwweber]

Does it make sense to add a kwarg to reverse the sort? Or does the [::-1] indexing work to reverse the SolutionArray?

[ischoegl]

[::-1] does not work, but implementing the kwarg is trivial. Can add this if there's a need.

[speth]

I realize this wasn't well documented, but the duplication of data between _extra_arrays and _extra_lists was meant as an optimization for accessing the "extra" variables. Data is initially stored in the list form so that appending to the SolutionArray is efficient. However, we want to return an array when those variables are accessed, and at the time I initially wrote this, I wanted to avoid the inefficiency of repeatedly converting the list to an array in the case where the data hadn't changed.

However, with the expansion of the features of the SolutionArray class, I think maintaining the duplicate data isn't worth the effort, so keeping just the list-based storage makes sense. It might be worth renaming it just _extra in that case, since there is no need to distinguish between that and the now-removed array version.

[ischoegl]

Data is initially stored in the list form so that appending to the SolutionArray is efficient.

That's how I interpreted this, and thought that np.array really only made sense for higher dimensions (which I don't believe need to be pre-empted at this point). Either way, I don't think it's necessary to keep duplicate data, and am happy that this can be simplified.

It might be worth renaming it just _extra in that case, since there is no need to distinguish between that and the now-removed array version.

Done.

[codecov]

Codecov Report

Merging #688 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #688   +/-   ##
=======================================
  Coverage   70.85%   70.85%           
=======================================
  Files         374      374           
  Lines       43668    43668           
=======================================
  Hits        30939    30939           
  Misses      12729    12729

Impacted Files	Coverage Δ
src/transport/GasTransport.cpp	90.58% <0%> (ø)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update f02ca90...85c2eba. Read the comment docs.