Refactor AdditionalCode
to accommodate namelist modification
#56
Labels
enhancement
New feature or request
Milestone
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 toAdditionalCode.namelists
but also copies any namelists with the suffix_TEMPLATE
to 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 aNamelist
class with:ROMSNamelist
andMARBLNamelist
subclassescreate()
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 Differentiating "approved" blueprints #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
AdditionalCode
instance describing a list of source code modifications and namelists associated with aComponent
, each namelist would have its own object, similarly to howInputDataset
currently works.Component.input_dataset
is a list ofInputDataset
objects, butComponent.additional_code
is a singleAdditionalCode
option.The text was updated successfully, but these errors were encountered: