search

GEOS-ESM / MAPL

MAPL is a foundation layer of the GEOS architecture, whose original purpose is to supplement the Earth System Modeling Framework (ESMF)
https://geos-esm.github.io/MAPL/
Apache License 2.0
26 stars 18 forks source link

Feature request for History wildcard support in GCHP #2647

Open lizziel opened 3 months ago

lizziel commented 3 months ago

This feature request is an expansion of https://github.com/GEOS-ESM/MAPL/issues/210 with an updated summary of the wildcard functionality we would like to have in GCHP. Wildcards are functional in GEOS-Chem Classic via configuration of HISTORY.rc, such as in this entry:

  DryDep.template:            '%y4%m2%d2_%h2%n2z.nc4',
  DryDep.format:              'CFIO',
  DryDep.frequency:           010000
  DryDep.duration:            010000
  DryDep.mode:                'time-averaged'
  DryDep.fields:              'DryDepVel_?DRY?'
::

In this example, ?DRY? represents a list of all dry deposited species. The list is assembled at run-time by reading all advected species from a text file and then filtering it based on dry deposition logical per species stored in another text file. N exports are then created, where N is the number of advected species that are dry deposited. Each export has name DryDepVel_{species_name}, e.g. DryDepVel_O3.

We would like to do this in GCHP for two reasons: (1) to reduce the size of theGCHP History configuration file, and (2) to eliminate the need to maintain duplicate lists of species which can get out-of-date, e.g. if a new species is added to the model.

Currently in GCHP the text file that contains the advected species list is read during SetServices. The text file containing species properties (i.e. which species are dry deposited) is read during Initialize, but could be read during SetServices if needed.

Do you think this functionality is feasible in GCHP using MAPL v3?

tclune commented 3 months ago

A related but somewhat confounding concern is a request by another user to have components maintain named sets of variables to be used in History. This avoids a current problem in which updates to components necessitate an update into the "app" repository which maintains the baseline history config file.

As @lizziel explained, the problem with this approach is often such lists of variables are dependent on other run-time switches. At best History would have to allow missing imports to be ignored, rather than raising an exception.