C-Star is a python package for setting up and running ocean model simulations, with a particular focus on marine carbon dioxide removal (mCDR) applications.
C-Star has to modify the ROMS primary namelist (typically called roms.in) in order to set basic parameters like run length and timestep.
The current strategy for this following PR #55 is to expect a "template" namelist containing placeholder strings to be replaced with actual parameter values by C-Star. When creating an AdditionalCode instance, C-Star adds any namelists to AdditionalCode.namelists but also copies any namelists with the suffix _TEMPLATE to a file without this suffix, adding this file to a separate attribute AdditionalCode.modified_namelists. Methods which then have to set namelist parameters use the modifiable copy, rather than the template.
Instead, we should separate AdditionalCode, in particular creating a Namelist class with:
ROMSNamelist and MARBLNamelist subclasses
A parser that can read an existing namelist file and extract a dictionary of settings (effectively a python translation of whatever happens in the model's Fortran code)
A create() method (or option in __init__ ) if no existing file is provided when we instantiate the object, to make from scratch a namelist file using a dictionary of default settings (something like this already exists within MARBL)
A modify() method that would allow calls like ROMSNamelist.modify(dt=360). In particular this would allow us to catch modifications that substantially change simulation outcomes, which would play nicely into #8
If we design a sufficiently robust framework to handle the parsing and modifying, this potentially could be extended to cover source code modifications, including things like output frequency.
This would mean that instead of a single AdditionalCode instance describing a list of source code modifications and namelists associated with a Component, each namelist would have its own object, similarly to how InputDataset currently works. Component.input_dataset is a list of InputDataset objects, but Component.additional_code is a single AdditionalCode option.
C-Star has to modify the ROMS primary namelist (typically called
roms.in) in order to set basic parameters like run length and timestep.The current strategy for this following PR #55 is to expect a "template" namelist containing placeholder strings to be replaced with actual parameter values by C-Star. When creating an
AdditionalCodeinstance, C-Star adds any namelists toAdditionalCode.namelistsbut also copies any namelists with the suffix_TEMPLATEto a file without this suffix, adding this file to a separate attributeAdditionalCode.modified_namelists. Methods which then have to set namelist parameters use the modifiable copy, rather than the template.Instead, we should separate
AdditionalCode, in particular creating aNamelistclass with:ROMSNamelistandMARBLNamelistsubclassescreate()method (or option in__init__) if no existing file is provided when we instantiate the object, to make from scratch a namelist file using a dictionary of default settings (something like this already exists within MARBL)modify()method that would allow calls likeROMSNamelist.modify(dt=360). In particular this would allow us to catch modifications that substantially change simulation outcomes, which would play nicely into #8If we design a sufficiently robust framework to handle the parsing and modifying, this potentially could be extended to cover source code modifications, including things like output frequency.
This would mean that instead of a single
AdditionalCodeinstance describing a list of source code modifications and namelists associated with aComponent, each namelist would have its own object, similarly to howInputDatasetcurrently works.Component.input_datasetis a list ofInputDatasetobjects, butComponent.additional_codeis a singleAdditionalCodeoption.