22.2. A sensitivity analysis module exists that permits to perturb one or multiple model parameters to quantify the sensitivity of one or multiple predicted model quantities of interest to these parameters. Y4M8
[x] EN will provide a demo notebook for this
Definition of done & User story:
A sensitivity analysis service exists. In it a number of variables can be defined and named (see S-D22.1), along with their typical value and the associated perturbation range (choice between linear and relative (dB) perturbations)
As a result corresponding output ports (or attached parameter nodes) are created that can be connected to input ports of a pipeline
Output ports of that pipeline that have the type scalar can be connected back to the sensitivity analysis service
When running the sensitivity analysis service, one reference pipeline execution and 2*n variations are run (increasing and decreasing always a single parameter according to its perturbation range)
The sensitivity analysis displays and provides as an output (at a port):
The sensitivities (in [-] and [dB] for linear perturbations, and as [1/dB] or [dB/dB] for relative ones) along with the R^2 value of the 3-point fit.
Note: In the above user story, the sensitivity analysis service acts as both an iterator and a collector object.
If it is too hard (or for some other reason undesirable) to create a single service that injects the variables and processes the results, this could be split into two services. A setup one that generates the pipeline input and forwards the sensitivity analysis setup related information and an analysis one that accepts the pipeline output and the setup information to produce the sensitivity analysis.
What i do not like about this approach is that it requires more steps and that the user is responsible for connecting the right sensitivity analysis setup service with the right sensitivity analysis analysis service. Alternatively, it would also be possible to always insert the setup and the analysis parts as two coupled nodes together (which cannot be unlinked), such that the user only needs to connect the desired output ports to the analysis part.
Furthermore, at the very latest when we implement optimizers, we will need the same object to act as iterator and collector.
22.2. A sensitivity analysis module exists that permits to perturb one or multiple model parameters to quantify the sensitivity of one or multiple predicted model quantities of interest to these parameters. Y4M8
Definition of done & User story:
A corresponding jupyterlab can be found here.
Note: In the above user story, the sensitivity analysis service acts as both an iterator and a collector object. If it is too hard (or for some other reason undesirable) to create a single service that injects the variables and processes the results, this could be split into two services. A setup one that generates the pipeline input and forwards the sensitivity analysis setup related information and an analysis one that accepts the pipeline output and the setup information to produce the sensitivity analysis. What i do not like about this approach is that it requires more steps and that the user is responsible for connecting the right sensitivity analysis setup service with the right sensitivity analysis analysis service. Alternatively, it would also be possible to always insert the setup and the analysis parts as two coupled nodes together (which cannot be unlinked), such that the user only needs to connect the desired output ports to the analysis part. Furthermore, at the very latest when we implement optimizers, we will need the same object to act as iterator and collector.