FRE has been in use now at GFDL since January 2003. It became a completely indispensable element in our testing, and a successful element in long production runs where a sustained workflow was important. Some time ago, we went through a process of listing the shortcomings of FRE, especially as a development environment, and presented a talk describing plans for its overhaul.

Shortcomings of FRE we listed in that plan include:

• The scripts FRE generates are too rigid: every runscript looks like a self-resubmitting, post-processing CM2 script.
• The earliest stage in model development — prototyping — requires a more nimble FRE than the RTS and production environment.
• Too much intermediate data is archived.
• Reliance on inefficient, serial external utilities (NCO);
• Too much reliance on run segment lengths: a lot of the post-processing is triggered on month boundaries and so on.
• Every experiment generates a fresh checkout: shared codebase is not exploited where appropriate.
• Does not save enough state: there is not enough checking of when model configuration is altered.
• The XML, which most users edit by hand, is convoluted and verbose;
• The FRE perl scripts themselves could be more modular.

We proposed that we would provide a new FRE, designed to offer:

• a development, testing and production environment for FMS-based models;
• that adequately serves the needs of CMDT, ESMDT, GAMDT, LMDT, OMDT and model liaisons;
• generates scripts that are no more (and no less) complex than they need to be;
• monitors performance and offers choices to reduce resource usage;
• and all the above being met, is abstract enough to be adapted by external users of FMS to their own needs.

New design elements that we have proposed include:

• modularizing the XML spec into self-contained components: this also maps into modularizing checkout and compilation;
• a new model of storage resources: a 3-level abstraction that permits efficient use of the /ptmp and /work archives that are not linked to tape;
• preservation of run state in the XML: this means ability to detect changes in FRE settings in a run that is underway, as well as detecting changes to any referenced external files
• direct linking of FRE to model development database: where information is entered now by hand, and is thus less than perfectly structured or reliable.

More details are to be found in the referenced FRE redesign slides.

These pages (see the Balaji's FRE pages links at left...) will explain the new structure of FRE as it evolves. Stages in the overhaul will cover:

• Reorganizing FRE by component;
• Attaching state to referenced external files;
• FRE's use of /ptmp;
• FRE's awareness of model time;
• etc.