CareamistV2: initialization cleanup

[veegalinova]

Description

Note

tldr: clean up CAREamistV2.__init__ implementation

---

Please ensure your PR meets the following requirements:

• Code builds and passes tests locally, including doctests
• New tests have been added (for bug fixes/features)
• Pre-commit passes
• PR to the documentation exists (for bug fixes / features)

[melisande-c]

Looks good, just a couple things.

Main thing is when loading from a checkpoint that was saved via the Lightning API but without CareamicsCheckpointInfo callback, so that there will be no experiment name saved, maybe we want to find a way that it can still be loaded by the CAREamist for predicting

[melisande-c]

Now that Joran merged #725 there is a default TrainingConfig so the configuration doesn't need it to be initialised. So now all that is missing is the experiment name.

As we were discussing before, if someone is trying to load a checkpoint for prediction but it doesn't have an experiment name, this is probably fine? Not sure what a good solution is though

Sorry if I didn't write this very clearly

[veegalinova]

@melisande-c @jdeschamps So following Milly's comment about checkpoint loading, I tried loading a checkpoint made with the current Careamist and ran into a few things I want to discuss.
The main issue is that the old HyperParametersCallback puts everything into hyper_parameters, but the new CareamicsCheckpointInfo callback writes to a separate careamics_info key. Should we just stick with hyper_parameters for consistency, or add extra logic to cover this?
And related to this, data_config also ends up in different places. The old format has it in hyper_parameters, now we also use save_hyperparameters() in DataModules that creates datamodule_hyper_parameters, which will be empty for old checkpoints.
And lastly, if the user trains with lightning api following current docs, we do not add the HyperParameters callback at all, so all of the keys will be empty. Do we want to cover this also?

[melisande-c]

And related to this, data_config also ends up in different places. The old format has it in hyper_parameters, now we also use save_hyperparameters() in DataModules that creates datamodule_hyper_parameters, which will be empty for old checkpoints.

So it is a bit unfortunate that all the config gets split up in the checkpoint this way, but I was trying to follow more closely how lightning expects a checkpoint to be organised. I did consider duplicating the entire config in a different checkpoint key, but ultimately thought it was unnecessary if we know where to extract the different parts of the config.

And lastly, if the user trains with lightning api following current docs, we do not add the HyperParameters callback at all, so all of the keys will be empty. Do we want to cover this also?

This is partly why I want to go with calling save_hyperparameters in the Lightning modules, it means for the lightning API we don't have to tell users to add the HyperParametersCallback, without which they would have to completely recreate the config if they want to load the checkpoint, see #520.

It does mean CAREamistV2 is not compatible with old checkpoints... but we have made changes in the past which make checkpoints incompatible, namely changing the model architecture. We should definitely discuss this further though

[veegalinova]

We should definitely discuss this further though

Opened an issue for this - #753, feel free to add thoughts there!
Otherwise, should this PR be merged?

[melisande-c]

Otherwise, should this PR be merged?

Go ahead :)