Treatment of forecast & hindcast CMIP6 expts.

taylor13 commented 7 years ago

In forecast or hindcast experiments -- i.e., all of the experiments where sub_experiment_id is not "none" -- a singleton coordinate should be defined recording the "forecast_reference_time" (the time the simulation was initiated from observations).

Specifically, the plan is to use "verification" (i.e., actual) time for the time coordinate, and record the forecast_reference_time as a separate variable pointed to by the coordinates attribute. The forecast_reference_time would be a scalar in our files.

sample of proposed CMIP6 file containing a single forecast (which is very similar to Example 5.12 in the CF conventions document): dimensions: time = UNLIMITED ... ... variables:

double reftime reftime:units = "days since 1960-01-01" [We could stipulate that a common set of "base-times" be adopted by all models.] reftime:standard_name = "forecast_reference_time" reftime:calendar = "gregorian" reftime:long_name = "Time Forecast was Initiated" ;

double time(time) time:units = "days since 1960-01-01" [This base time doesn't have to be the same as the basetime used in reftime.] time:standard_name = "time" time calendar = "gregorian" time:long_name = "Verification time of the forecast" ;

float psl(time, lat, lon) ; psl:standard_name = "air_pressure_at_sea_level" ; psl:long_name = "Sea Level Pressure" ; psl:units = "Pa" ; psl:cell_methods = "time: mean" ; psl:cell_measures = "area: areacella" ; psl:coordinates = "reftime "

One way to make this happen would be to generate a set of tables that parallel the existing tables but would be used exclusively for forecasts and hindcasts. In those tables an additional dimension would be added to all variables. For example in place of the following Amon variable

    "tas": {
        "modeling_realm": "atmos", 
        "standard_name": "air_temperature", 
        "units": "K", 
        "cell_methods": "time: mean", 
        "cell_measures": "area: areacella", 
        "long_name": "Near-Surface Air Temperature", 
        "comment": "near-surface (usually, 2 meter) air temperature", 
        "dimensions": "longitude latitude time height2m", 
        "out_name": "tas", 
        "type": "real", 
        "positive": "", 
        "valid_min": "", 
        "valid_max": "", 
        "ok_min_mean_abs": "", 
        "ok_max_mean_abs": ""
    },

you would find (only difference is in the "dimensions")

    "tas": {
        "modeling_realm": "atmos", 
        "standard_name": "air_temperature", 
        "units": "K", 
        "cell_methods": "time: mean", 
        "cell_measures": "area: areacella", 
        "long_name": "Near-Surface Air Temperature", 
        "comment": "near-surface (usually, 2 meter) air temperature", 
        "dimensions": "longitude latitude time height2m reftime", 
        "out_name": "tas", 
        "type": "real", 
        "positive": "", 
        "valid_min": "", 
        "valid_max": "", 
        "ok_min_mean_abs": "", 
        "ok_max_mean_abs": ""
    },

and we would add to the dimensions table:

    "reftime": {
        "standard_name": "forecast_reference_time", 
        "units": "days since ?", 
        "axis": "", 
        "long_name": "forecast reference time", 
        "climatology": "", 
        "formula": "", 
        "must_have_bounds": "no", 
        "out_name": "reftime", 
        "positive": "", 
        "requested": "", 
        "requested_bounds": "", 
        "stored_direction": "increasing", 
        "tolerance": "", 
        "type": "double", 
        "valid_max": "", 
        "valid_min": "", 
        "value": "", 
        "z_bounds_factors": "", 
        "z_factors": "", 
        "bounds_values": ""
    },

If this were done, the person running CMOR would have to remember to switch from the normal cmor tables to the parallel tables (with the added dimension). The table names would have to be identical, however, so that the filenames (and DRS) would be consistent across all CMIP6 expts.

There are other approaches that might make it easier for users, which we should discuss.

One thing we'll have to check is whether CMOR3 can handle multiple singleton dimensions (as in the above example where both height2m and reftime are singleton dimensions.

taylor13 commented 7 years ago

Another option would be to keep the table names the same but the rename the files, replacing "CMIP6" with "DCPP". CMOR would obtain the correct table from within an if/else construct with the outcome determined on whether or not sub_experiment_id = "none" or not.

taylor13 commented 7 years ago

Another option would be to test within CMOR whether we are dealing with an inititalized forecast run or a climate run. If a forecast, then add the singleton dimension and pointers needed. If not, skip that step.

I would start by testing whether CMOR has any problems when we prepare a special table that includes the extra scalar time dimension and we run a test case. If that works, I think I'd be tempted to simply produce a parallel set of tables to the "CMIP6 ..." cmor tables, that include the extra dimension and are named "DCPP ...". The user would need to use these tables when preparing output from a forecast experiment.

dnadeau4 commented 7 years ago

Can now add reftime. See test. https://github.com/PCMDI/cmor/blob/master/Test/test_python_forecast_time.py

taylor13 commented 7 years ago

At some point (at a lower priority), we might restrict the user from defining reftime except in certain experiments (when it is appropriate).

PCMDI / cmor

Treatment of forecast & hindcast CMIP6 expts. #144