Data features

[marjanfamili]

In the example of the heart emulator researchers use the following features from their output to train their emulator

min, max , average and n number of PCA components.

For Autoemulate we can change the setup flags to allow people to choose what features to include in the training. for example :

em.setup(sample_df, results, y_features_for_training = ["min, "max", "average", "outcome of preprocessing technique we just performed"] , models=["gp"], scale_output = True, reduce_dim_output=True, preprocessing_methods=preprocessing_methods)

This should still allow for preprocessing grid search as well as adding additional statistically important features

This could be extended to writing own processing function and import function as one of the features

[radka-j]

My worry is that how the users summarise their outputs is going to be highly domain specific and hard to generalise. For example, in the 3D cardiac example they don't just get summary statistics like min, max, range, they measure the length of a very specific interval within the time signal. I'd therefore lean toward expecting the users to handle this. They either give us a dataset of those summary statistics or implement this as the output returned by their simulator.

We also touched on this in the discussion yesterday, where it was pointed out that in the battery case the summary statistics aren't just domain specific but researcher specific.

[marjanfamili]

The problem is that this approach stops the user from using our preprocessing tools. I think at the very least, it should be possible to not apply preprocessing to all y, but add to whatever output the user provide, if they didn't provide extra features, it would be applied to all. The suggestion of taking in function provided by the user, is to address domain specific needs.

[marjanfamili]

In the current state, the preprocessing method is only useful in very few scenarios

[sgreenbury]

Adding notes from discussion today with @marjanfamili @radka-j @ContiPaolo:

• As described above, an example use case is where we the user provides y data (n_samples, n_time_steps) and would like an emulator to do predictions on PCA reduced y output concatenated along columns with summary statistics such as mean, min, max, mean of y
• The output prediction from the pipeline could be in the original untransformed space y but the emulator would be fit on the transformed version concatenated with summary statistics (e.g. y_prime has transformed and concatenated columns (PC1, PC2, PC3, mean, min, max) with un-transformed columns y of the original data. An option to consider is if the summary statistics predicted by the emulator could also be returned along with the untransformed prediction.
• Two possible options discussed:
  1. Implement concatenated transforms and summary statistics (possibly concatenated list of transforms more generally list[list[AutoEmulateTransform]]).
  2. Implement concatenated emulators that predict on PCA part and summary statistic part independently but provide framework for generating the independent emulators and combining outputs. Correlations between emulators would be more challenging to capture.

Next step discussed is to explore further a design that would be work well for application to heart emulator.

[radka-j]

After working on the patient calibration case study, it is my understanding that in the cardiac workflows they either use PCA to reduce the dimensionality of the output data or they use summary statistics but not both at the same time so we should only implement this once we have a clear use case for it.