This page proposes a modular approach to how FRE interacts with the software framework that it supports: currently only FMS of course, but one could imagine that if Curator expands FRE into CRE, this could be generalized.

In particular, we are currently interpreting certain files that belong to FMS that relate to model time and processor layout. This is currently done haphazardlly across the FRE code, often in multiple places.

Second, FMS has single flat input files, whereas FRE is (or is going to be) organized by component. We need to be able to generate these files (e.g diag_table) from component specs.

Finally, FMS uses namelists, which in turn use defaults embedded in the code. So the input.nml file alone is not enough to specify the model state. FMS writes the value of all namelists after applying defaults, to a file logfile.out. Tools such as fredb which must save the value of configuration parameters to a database, must use logfile.out instead of the canonical \$nml hash.

Model time

• A running FRE job must be able to query the current model time before or after a run segment, and return it as a string. This string is used to put timestamps on filenames; it will also be used in XML 4.0 to activate script segments at or before or after a particular model time, or at certain model time intervals. The source for this information is probably always the coupler.res file, but exists elsewhere as well... diag_table, reload_commands, ... very confusing! Unify into a single subroutine get_current_model_time.
• Currently the segment loop generated by frerun assumes you always have constant run segments and so the number of times through the loop can be calculated ahead of time. This needs to be changed because of expanded use of checkpointing. Let's use get_current_model_time to rewrite the loop as a "run until model time exceeds target". (If we had the get_cp_time routine proposed on the platform page, we could be more ambitious, and measure how much CP time was left, to deduce whether it's possible to run one more segment or not).
• A current frepp limitation is that it can only be run at year intervals. It also hardcodes the definition of "season" etc. Can we use this model-time module to come up with a uniform and flexible way of setting triggers and alarms?

Tables

"Tables" (e.g diag_table, data_table, ...) are flat text files that FMS uses. We need to be able to string them together out of components.

• diag_table is poorly designed and will require reordering of elements.

  = data_table is poorly designed as some components need a default value supplied even when that component is not in use! FRE should then supply it, I suppose.

Namelists

We currently interpret certain settings out of XML and use shell variables to modify the input.nml here-document.

• running time of a segment. Until recently we only supported months and days, recently extended to hours. Each of these time units is hardcoded in FRE. Should generalize to support model time intervals of any resolution.
• layout: the processor division between atmosphere and ocean is now hardcoded in XML and passed to input.nml, as is the XxY processor layout within each component. This is done in different ways in different models. Refactor to unify.

Grids

• The Mosaic grid specification is very general, the tool fregrid that interprets it is also general; but the current FRE code has hardcoded many "soft" conventions that might change, e.g that the grid tiles are contained in foo.tile1.nc, etc. It would be better to put this in a "grid interpreter module" that could rely on soft conventions initially; but later learn to read and interpret the mosaic.nc file.
• similarly the vertical and horizontal regridding options rely on conventions shared with plevel.sh in the vertical, and with fregrid in the horizontal. The vertical is stable and is easy to extract. For the horizontal, let's change cub2latlon="144 90" to a more general xyInterp="-some_fregrid_flags"... as we start to run and process more high-resolution models, it will be necessary to use fregrid for more things than just cub2latlon. (Even for that, we now have multiple options for regridding, that can't currently be expressed in FRE).