Error if use number-like unit name when adding timeseries

[zikolach]

Code sample or context

Add timeseries to the scenario with unit names represented by numbers (e.g. 1).

Expected result

Timeseries added to the scenario without error.

Problem description

TypeError: No matching overloads found for at.ac.iiasa.ixmp.objects.TimeSeries.addTimeseries(str,str,str,java.util.LinkedHashMap,int,bool), options are:
	public void at.ac.iiasa.ixmp.objects.TimeSeries.addTimeseries(java.lang.String,java.lang.String,java.lang.String,java.util.Map,java.lang.String,int) throws at.ac.iiasa.ixmp.exceptions.IxException
	public void at.ac.iiasa.ixmp.objects.TimeSeries.addTimeseries(java.lang.String,java.lang.String,java.lang.String,java.lang.Integer,java.lang.Double,java.lang.String,int) throws at.ac.iiasa.ixmp.exceptions.IxException

Test added to the feature/number-like-units branch.

Versions

Most recent version is affected.

[khaeru]

Some points we discussed on Slack:

• All dimension/attribute labels, except for 'year' (int), are str: this includes 'region', 'unit', 'variable'.

• It's fine for these strings to contain number-like values, e.g. the string '1'.

  One reason is that certain applications might choose to use well-known numbered codes, and we don't wish to exclude this without reason. E.g. in China, the official number code for Beijing is 11, so this might be stored as region='11'.

  For 'unit' in particular, ixmp has not enforced anything about the contents, except that they were previously added with Platform.add_unit(). The value for this attribute could e.g. be 'cheeseburger123.4' which is neither an SI unit, interpretable as a unit, nor parseable by Pint. Following the principle of minimum disruption/surprise, we won't change this at the moment.

• If the user provides non-str input for any of these dimensions, there are some options:

  1. Raise TypeError immediately.
  2. Try to convert str(label) and only raise an exception if that fails.

• Either way, this must be done in ixmp.core, because it is related to sanitizing user inputs. (Backends are only responsible for storing data that is already in the canonical format.)

[khaeru]

@zikolach will you tackle this?

[zikolach]

We discussed at dev meeting today and @danielhuppmann will try to assist fixing this bug.