The current version of FRE (Version 2 of the syntax) is organized by the stages in the sequence of preparing an experiment, as follows:

<cvs>
...
<cvs>
<compile>
...
<compile>
<input>
...
</input>
<run>
...
</run>
<postProcess>
...
</postProcess>

The <postProcess> tag alone had been organized into components.

Organizing by stages in the workflow rather than by component clearly violates modularity at some very basic level: everyone is exposed to the inner workings of every component.

As part of the FRE overhaul, we have reorganized the FRE schema entirely by component. Also, with a nod to the future and our ESC project, we now allow components to be recursive. The <component> tag now becomes the basic unit of organization, and each specifies its own workflow stages.

Checkout and compilation

Concurrently with the Nalanda release, we are deploying a new syntax wherein the checkout and compilation is done per component.

<component name="fms" paths="shared">
   <source versionControl="cvs" root="/home/fms/cvs">
      <codeBase version="latest">shared</codeBase>
   </source>
   <compile>
      <cppDefs>-Duse_libMPI -Duse_netCDF -Duse_SGI_GSM</cppDefs>
   </compile>
   <compile target="debug">
      <cppDefs>-Duse_libMPI -Duse_netCDF -Duse_SGI_GSM</cppDefs>
      <mkmfTemplate>/home/fms/bin/mkmf.debugtemplate.ia64</mkmfTemplate>
   </compile>
</component>

Features to note:

• The component's name attribute is freely chosen by the user: the output of compilation will use it to construct a library name like libfms.a.
• For this component the version control system is cvs and we are using the standard FMS CVSROOT, which is /home/fms/cvs. But another component could come from another repository, which might be using the Subversion version control system. The value of versionControl belongs to a controlled vocabulary, for which the only accepted value today is cvs.
• there are two <compile> nodes, one pointing to the default target exec, and another to the target debug. They use different Makefile templates. By default, fremake will use the default target, but fremake -t debug will use the alternate template, and provide an alternate compilation from the same source.
• the value of <codeBase> must be an existing CVS module, or set of CVS modules, in the named repository. Its version attribute is the associated CVS tag.

Other components will be listed as follows: each can have its own checkout and compilation instructions, its own <cppDefs>, and so on.

<component name="atmos_phys" paths="atmos_param atmos_shared" requires="fms">
...
</component>

Note the requires attribute: this tells us that the fms component must be compiled ahead of atmos_phys. Further components set up an entire compilation tree:

<component name="atmos_dyn" paths="atmos_coupled atmos_fv_dynamics" requires="fms atmos_phys">
...
</component>
<component name="ice" paths="ice_amip ice_param" requires="fms">
...
</component>
<component name="land" paths="land_lad land_param" requires="fms">
...
</component>
<component name="ocean" paths="ocean_amip" requires="fms">
...
</component>
<component name="coupler" paths="coupler" requires="fms atmos_phys atmos_dyn ice land ocean">
...
</component>

Precompiled libraries

Since compilation is now by library, we introduce a powerful new feature. Just as in the old FRE, you could specify an <executable> and avoid compilation altogether, you are now able to specify a <library> for a component and avoid both checkout and compilation. The specification:

<component name="fms" paths="shared">
   <library path="/home/arl/fre/test/trial9/m45_am2p14/exec/libfms.a"
               headerDir="/home/arl/fre/test/trial9/m45_am2p14/exec" />
   <source versionControl="cvs" root="/home/fms/cvs">
      <codeBase version="latest">shared</codeBase>
   </source>
   <compile>
      <cppDefs>-Duse_libMPI -Duse_netCDF -Duse_SGI_GSM</cppDefs>
   </compile>
   <compile target="debug">
      <cppDefs>-Duse_libMPI -Duse_netCDF -Duse_SGI_GSM</cppDefs>
      <mkmfTemplate>/home/fms/bin/mkmf.debugtemplate.ia64</mkmfTemplate>
   </compile>
</component>

tells fremake not to perform either checkout or compilation for the fms component; instead, we will link to the specified library at the loader stage. The headerDir attribute specifies where Fortran module header (".mod") files and CPP (".h") files are stored, for other components that have a dependency on them.

Starting with the Nalanda release, a set of standard libraries for most component configurations in common use at GFDL will be provided. These will have the best known optimizations. Users principally working on one component will be able to link to other components as black box libraries.

The list of components in this example are one or two levels deep from the coupler. The method however can be done at much deeper levels of component systems. For example, the CVS module atmos_param_am3 is itself a composite of various column physics modules. This provides a degree of fine-grained control over what is compiled. One could also go in the other direction and provide a set of "standard executables" as well.

Input datasets

Currently, FMS uses a flat file structure across components (e.g diag_table and data_table). The next change to FRE will be an ability to specify input files per component: FRE will be responsible for constructing diag_table, data_table, etc. The namelists also will be per-component: FRE will make input.nml.

Composite datasets such the gridspec file will belong to the top-level coupler component.

Running

In principle, each <component> could even have its own <run>, this would work for the multiple-executable mode of coupling favored by PRISM. In practice, we would write a run method only for our top-level component coupler.

In future, there will be a targetType attribute that tells whether a component should produce a library or an executable.

Post-processing

The post-processing is already organized by component. The only change we foresee here is that the hierarchy:

<postProcess>
  <component name="atmos">
  ...
  </component>
</postProcess>

will be reversed, and the <postProcess> node will also come below <component>.