Closed TomNicholas closed 1 month ago
I agree that it would make some sense to bundle these into a class, but disagree that it is a separate set of choices - it is a part of the make-up of a component. Changing the grid discretisation or time step would change the model output like changing the surface forcing dataset would. Different components of the same case can also have, e.g., different time steps. I can see e.g. a ROMSDiscretization object being an argument to ROMSComponent much like a ROMSBaseModel instance currently is.
In any case most of the info contained in the discretisation should not need to be specified by the user in the future. For example, the domain having 100 levels shouldn't need to be specified in the blueprint; that information either exists in the metadata of the grid file or in the roms-tools recipe, and C-Star should, long-term, be obtaining it from there, ideally before/without downloading anything or calling to roms-tools.
The discretization info is conceptually a separate set of choices from choosing a component or input datasets. It should be defined using a separate class (e.g. a small dataclass), then passed in only when necessary