Should each algorithm have its own configuration

[jdeschamps]

Description

We originally split the configuration in algorithm-specific configurations (child classes) to be able to perform validation across sub-configurations:

from pydantic import BaseModel

class Configuration(BaseMode):
    algorithm_config: UNetBasedAlgorithm | LVAEBasedAlgorithm
    data_config: GeneralDataConfig

# N2V
class N2VAlgorithm(UNetBasedAlgorithm):
    ...

class N2VDataConfig(GeneralDataConfig):
    ...

class N2VConfiguration(Configuration):
    algorithm_config: N2VAlgorithm
    data_config: N2VDataConfig
    # validate parameters from N2VAlgorithm and N2VDataConfig against each other


# CARE
class CAREAlgorithm(UNetBasedAlgorithm):
    ...

class CAREConfiguration(Configuration):
    algorithm_config: CAREAlgorithm

@melisande-c correctly pointed out that in #365 we are now removing the need for N2VDataConfig. The only difference between N2VConfiguration and CAREConfiguration are now:

• Algorithm sub-configuration parameter
• Methods to generate citations, references, summary and friendly name for BMZ export (e.g. here)

There will be no more validation across algorithm and data, at least for now.

Which part of the code?

• Algorithm configuration declared in algorithm-specific configuration:

  careamics/src/careamics/config/n2v_configuration.py

  Line 86 in 9a027a5

  algorithm_config: N2VAlgorithm

• Methods to generate metadata for BMZ export:

  careamics/src/careamics/config/n2v_configuration.py

  Line 189 in 9a027a5

  def get_algorithm_references(self) -> str:

Potential solutions

Therefore, a few aspects to discuss:

1. Is having a clean class per algorithm to generate the metadata (references, citations, description) for the BMZ enough to justify the existence of N2VAlgorithm, CAREAlgorithm etc. ?
2. Where will the noise model end up in the PN2V configuration? Probably in algorithm_config as well isn't it?
3. Do we foresee any need for specific data or training configuration for the LVAE-based algorithms (HDN, microSplit)?

Solution 1: Remove algorithm-specific configurations

from pydantic import BaseModel

class Configuration(BaseMode):
    algorithm_config: N2VAlgorithm | N2NAlgorithm | CAREAlgorithm | PN2VAlgorithm | MicroSplitAlgorithm | HDNAlgorithm
    data_config: DataConfig

The main advantage is really to have a single Configuration type. Code-base will not change much:

• Less classes in the configurations.
• We will need a new space for all the BMZ-related metadata creation (which is algorithm specific).
• Doc is easier to write.

API will not really be impacted.

Solution 2: Change nothing

We keep a separated structure per algorithm. Advantages:

• Clean separation of the BMZ metadata
• We still have the possibility to validate across sub-configurations

This comes at the cost of the multiplication of configurations, and a more complex documentation.

Did I miss anything? Opinions?

@CatEek @melisande-c @veegalinova @federico-carrara

[melisande-c]

Ok so I did forget about the citations, refs etc. when I made the comment; but I guess moving them to the algorithm model classes, does make sense? (citations don't relate to the data).

Even if the configurations for LVAE based algorithms end up being split for data + algorithm validation, that doesn't mean the CARE-family configurations also have to be split.

But this is not a massive priority since it works fine as is, but if the number of configuration classes starts to become cumbersome we may want to consider it.

[jdeschamps]

That makes sense, I am convinced!

It will be an easy enough PR.