Overwrite x_axis only during fitting #77

[patrick-austin]

Adds handling for x_axis and x_axis_values for fitting experiments. The WARNING for overwriting values has been downgraded to INFO, and will only be printed when the x_axis is set by the user (this checks the value for x_axis and also if the default value of time is altered without explicitly changing x_axis). If no values given, we use the experimental data for the final evaluation of the function, and saving the .dat file.

If however the user specifies values, then these will be used only for the final .dat evaluation.

Justification

Considered interpolation/overlapping of ranges provided by the user, but decided that this was not the right approach as the experimental data contains all our information, and we will either be upscaling (implying a precision we do not possess) or downscaling (discarding information prior to the fit). Neither of these is a good. Instead, we should use (all) the information we have for the fit, which defines our variables - then if the user wants to evaluate this on a range which differs from the experimental range, that is perfectly acceptable - and would be no different from if they just started a new experiment with the values that came out of the fit and a new x_axis. This approach is also a lot simpler than having to worry about how to interpolate arbitrarily.

TODO

• Update documentation/examples/tutorials to exaplain this funcationality
• Consider adding a warning if the user gives a range which does not overlap fully or at all with the experiment. I feel less strongly about this since a bad choice of range won't compromise the fit, (and as mentioned above, we can't stop them manually using the values in a future calculation anyway), but it might be helpful as a sanity check.

#77

[subindev-d]

Suggested change

	if self._x_range[xname] is None:
	if self._x_range.get(xname) is None:

if the xname key is not in the _x_range dict, it will return KeyError rather returning None.

[patrick-austin]

The behaviour's a bit counter-intuitive here I think. We initialize to have a value of None in the dict:

muspinsim/muspinsim/simconfig.py

Line 117 in 08a3430

self._x_range[x] = None

Which may get assigned an actual range (or not).

Then xname is taken directly from the dict, so must be present as a key:

muspinsim/muspinsim/simconfig.py

Line 186 in 08a3430

xname = list(self._x_range.keys())[0]

I'm naturally wary of changing things which aren't needed for the issue, to keep scope limited and for fear of breaking something accidentally. So while I think a lot of this could be rewritten to be clearer, at the time I left the lines I didn't need to change as is (e.g 186). But that means the new line 189 is confusing.

To make what's actually happening clearer, propose changing keys() to items() on 186 and assigning/using the value for the first key/value pair directly.

[codecov-commenter]

Codecov Report

❗ No coverage uploaded for pull request base (main@e57dfd3). Click here to learn what that means.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main      #90   +/-   ##
=======================================
  Coverage        ?   86.40%           
=======================================
  Files           ?       23           
  Lines           ?     2795           
  Branches        ?      538           
=======================================
  Hits            ?     2415           
  Misses          ?      248           
  Partials        ?      132