develop fast (efficient) "single-tile" GEOSldas driver

[gmao-rreichle]

This "issue" outlines tentative plans to construct a fast and efficient "single-tile" driver functionality for GEOSldas, which is a useful tool for land model development and debugging.

At the moment, we do not have the resources (free developer time) to address this issue, but we should keep it in mind and plan accordingly.

Currently, GEOSldas can be set up to run just a single tile (via "include_list"), but because global forcing data need to be read from disk every data-hour, multi-year GEOSldas simulations for single tiles are relatively slow.

Over the past few years, several versions of efficient "single-tile" drivers based on LDASsa have been constructed and used by @smahanam , Jing Tao, Fanwei, @gmao-jkolassa , and others.

The common design for these LDASsa-based single-tile drivers is that one simulation with the standard LDASsa code is first conducted. During this first integration, the entire time series of forcing data is saved into a single file (or perhaps one file per data-year). For subsequent simulations of the same tile, the "single-tile" driver then reads the single-tile forcing file at the beginning of the simulation (or at the beginning of each year) into memory and can thus run the model very efficiently and much faster for the single tile in question.

When resources permit, a single-tile version of GEOSldas should be constructed in two steps:

1. Add a script or program to write the forcing data for a single tile into a single file. It may be best for this to take the form of a pre-processor that loops through FP and/or MERRA-2 files and extracts the time series for just one grid cell into a single file (or one file per year). That is, this pre-processor would be entirely independent of GEOSldas.
2. Add functionality to the GEOSldas MetForce GridComp that reads the forcing file(s) generated with the pre-processor (item 1) for the entire time period of interest (or in yearly chunks) and run the model with all the forcing data (for a year) in memory.

Additional considerations:

• The above is based on the assumption that the major performance obstacle for efficient single-point simulations is the met forcing data. There's a chance that pre-processing of the LAI and albedo inputs into single-tile files is also necessary.
• Another possible constraint on the performance may be output. If output is required at high temporal resolution, writing it into a single file that includes many time steps may prove to be more efficient. This may break the paradigm of MAPL History.
• Ongoing work on i-server and o-server utilities by @weiyuan-jiang and the SI team may improve the performance of the standard GEOSldas forcing to the point where performance becomes acceptable for small-domain simulations.
• One key design objective is to make the "single-tile" GEOSldas configuration as simple as possible to facilitate s/w maintenance and development. A key problem with the existing LDASsa-based single-tile drivers is that they were not integrated into the main development of LDASsa and have become outdated (i.e., diverged from the main development stream). It is not worth trying to save a bit of runtime at the expense of simplicity.
• It is not strictly necessary to make the single-tile driver work with perturbations and/or data assimilation, but if the 2-part design outlined above proves workable and sufficiently efficient, the perturbations and data assimilation components of the single-tile driver should work as well as they would in a single-tile simulation with the standard GEOSldas s/w.

cc: @rdkoster @weiyuan-jiang @biljanaorescanin