Fixed Key-Error when looking up values by time and added some typehints

[KwentiN-ui]

This fork started with me not being able to run sensitivity analyses inside my OMEdit client because of a lookup issue inside the varAnalysisForPerturbedParam function. In my case the float 0.1000000001 was compared against 0.1 resulting in a key error. I fixed this by looking up the nearest datapoint to the query. There were similar issues with the rootMeanSquareForVar function. Both of these are inside indiv_sens.py and are the only change that can be noticed from the user side.

Every other change just adds typehints that make working with the code a lot more managable. I verified types by purposfully raising exceptions, then printing the type inside the error message. While doing this I noticed a lot of dead code, meaning classes that never get called during the analysis (from inside OMEdit), which are bloating up the module quite a bit.

I work with Python professionally and am eager to contribute more to this tool, as I see a lot of value in it. I'd also love to add more functionality in the future that I personally use in the field (i.e. an FFT Tool, Campbell plots, etc.).

(I couldn't get the tests to actually run, but I tested the 2 changes with live models inside OMEdit)

Related Issues

I couldn't find an issue relating to the key error crash yet

[adeas31]

@rodrigodcastro anyone in your group who can review these changes?

[rodrigodcastro]

Thanks for detecting these issues and providing the candidate fixes.
From a numerical and software-engineering perspective, the argument presented in the PR is coherent.
Sensitivity analyses typically assume continuous or quasi-continuous parameter spaces, in which selecting the nearest available sampled value is often the correct semantic interpretation.
The fix is sound provided that:
-the independent variable is monotonic or otherwise ordered;
-the sampling grid is sufficiently dense; and
-the distance metric used to define “nearest” (absolute vs. relative) is well defined.
The current implementation does not appear to use an explicit tolerance (eps) or a guard against large distance mismatches. This does not invalidate the fix, but it is an aspect that future reviews should inspect more closely.

[KwentiN-ui]

I added an assertion to check if the time axes are strictly monotonous (which should always be the case anyways). Otherwise the np.interp function I use for resampling could fail silently (it just spits out wrong results). Other than that the changes don't make any assumptions about the shape of the data.