Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Refactor AdditionalCode to accommodate namelist modification #56

Open
dafyddstephenson opened this issue Aug 29, 2024 · 0 comments
Open
Labels
enhancement New feature or request
Milestone

Comments

@dafyddstephenson
Copy link
Contributor

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 Differentiating "approved" blueprints #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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant