Implementation Concepts

The off-line processing concept included the main aspects:

  1. Organisation of the routines that ingest and transform to .fp format into a single library or module file that could be used by both FLEXPART and the off-line pre-processing tool. Keep the developed routines with the FLEXPART source code distribution to ensure matching when compiling both the libraries and FLEXPART and to ensure maximum re-utilization of FLEXPART code.
  2. Add a switch in COMMAND file will allow it to read the .fp files directly or to use the usual on-the-fly processing of the GRIB incoming files.
  3. To be the start-up of a potential pre-processing system that could have plugged in additional met data (e.g. WRF).

The conceptual approach, which makes use as much as possible of original source code from FLEXPART, is as follows:

The foundation of the implementation is fpmetbinary_mod.F90, which provides access to simple fpmetbinary_dump() and fpmetbinary_load() routines for writing met variables to a file in the fp format, and reading from an fp file to load the relevant arrays with the data that would normally be stored after reading GRIB met files in the traditional FLEXPART.

Implementation of the concept proceeded as follows:

  • Initial testing of concept by generating the .fp files in getfields(). As soon as GRIB met variables were processed, the data structures were dumped to fp files so that they could be used for testing
  • A new routine getfpfields() was created to read .fp files into the relevant data structures. It has a structure similar to getfields() but, rather than reading GRIB files and processing, it merely loads the fp data into the arrays.
  • Because FLEXPART initially looks at a single GRIB file to gather initial variables and to set up the vertical coordinate system for the simulation (in gridcheck()), it was necessary to build an analogous fpgridcheck() which would read the same data from an fp file. This required us to add a number of new variables to the dump and load routines.
  • With a lot of testing and conditional compilation to make FLEXPART behave as either an fp generator or an fp consumer, it was possible to test the concept and discover several problems discussed in the documentation of the fp format. Once the concept was fully developed and tested, a two-pronged approach was executed
    • FLEXPART was modified so that it would look for a PREPROCESSED_DAT switch in the COMMAND file. If the switch was set to 1, then a few variables were set and FLEXPART would call fpgridcheck() and getfpfields() (instead of gridcheck() and getfields()), and would read fp files as specified by the AVAILABLE file.
    • A separate executable, GRIB2FLEXPART, was created to generate fp files from GRIB met files, using existing FLEXPART routines, plus a small set of additional routines. FLEXPART and GRIB2FLEXPART are intimately coupled with each other through shared routines.

The call diagrams (available from file:///home/morton/flexdoxygen/html/index.html) for FLEXPART.F90 and GRIB2FLEXPART.F90 are presented below. Note that the red boxes indicate routines that have their own expanded call trees, but can't be represented in this single diagram without creating a total mess. At the web site, you may click on a routine for additional information.

Last modified 9 years ago Last modified on Nov 6, 2015, 11:41:20 AM

Attachments (3)

Download all attachments as: .zip

hosted by ZAMG