Closed dafyddstephenson closed 2 weeks ago
the
ROMSComponent.additional_code
attribute should be broken up into two instances ofAdditionalCode
:namelists
andadditional_source_code
A split like this seems totally reasonable, and I think we discussed it somewhere previously (can't find the issue now). Perhaps namelists
and additional_source_code
should be separate classes though? IDK
I considered this possibility as I went (this is implemented in #117 ) but they turned out to both make sense as defined by (and require the methods of) AdditionalCode
. I think this is much the same as #112 , where ROMSComponent.input_datasets
was split into ROMSComponent.model_grid
, etc., etc., but each of these new attributes was still an instance of the InputDataset
class.
(I think in the future they will be separate classes, per #56)
The spiral:
AdditionalCode.get()
clones the template namelistroms.in_TEMPLATE
to a local working copy once and for all - all future modifications happen to the working copy.update_namelist
method that always goes back to the template version and replaces its placeholder strings with new valuesnamelist_modifications
property, that exists parallel tonamelists
(a list with one entry per namelist file). Each entry is a dictionary of values to replace (initially{}
).Component
level, e.g.ROMSComponent.namelist_modifications
in order to keep track of everything happening below. If it wereROMSComponent.additional_code.namelist_modifications
then it wouldn’t be able to dynamically update when, say, the user setsROMSComponent.discretization.time_step
.ROMSComponent.additional_code
attribute should be broken up into two instances ofAdditionalCode
:namelists
andadditional_source_code
. We could then have, e.g.ROMSComponent.namelist_modifications
that dynamically tracks all other changes below the level ofROMSComponent
, e.g.ROMSComponent.initial_conditions
,ROMSComponent.discretization.time_step
, etc.@TomNicholas (if I've managed to explain this problem sensibly) do you have any other ideas to tackle it?