Split Component.additional_code into Component.namelists and Component.additional_source_code

[dafyddstephenson]

The spiral:

• To do a restart, we need to update the namelist with the new IC file and number of timesteps
• However, AdditionalCode.get() clones the template namelist roms.in_TEMPLATE to a local working copy once and for all - all future modifications happen to the working copy.
• If we want to change the IC file entry and then change it again, we have lost the placeholder string to replace in the modified version.
• A “simple” solution would be to have an update_namelist method that always goes back to the template version and replaces its placeholder strings with new values
• However, we would need to track all the other changes that have been happening too, not just the value that’s being replaced in the moment, or we would have an “updated” namelist that had N-1 placeholders and one correct value.
• In order to track namelist modifications we need a namelist_modifications property, that exists parallel to namelists (a list with one entry per namelist file). Each entry is a dictionary of values to replace (initially {} ).
• This property would have to exist at the Component level, e.g. ROMSComponent.namelist_modifications in order to keep track of everything happening below. If it were ROMSComponent.additional_code.namelist_modifications then it wouldn’t be able to dynamically update when, say, the user sets ROMSComponent.discretization.time_step .
• This implies that (as I have concluded in the past), the ROMSComponent.additional_code attribute should be broken up into two instances of AdditionalCode : namelists and additional_source_code . We could then have, e.g. ROMSComponent.namelist_modifications that dynamically tracks all other changes below the level of ROMSComponent , 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?

[TomNicholas]

the ROMSComponent.additional_code attribute should be broken up into two instances of AdditionalCode : namelists and additional_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

[dafyddstephenson]

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.

[dafyddstephenson]

(I think in the future they will be separate classes, per #56)