PMPParser#

PMPParser is basically a wrapper around ArgumentParser. It has the ability for users to use the default arguments which are listed below or define their own, which can overwrite the default arguments if needed. PMPParser also supports reading in a parameter file from the command line and then allowing for the user to modify select parameter values as needed.

Default Arguments#

Value

Argument

parameter

-p or –parameter

case_id

–case_id

vars

-v or –vars

regions

–regions

regions_values

–regions_values

reference_data_set

-r or –reference_data_set

reference_data_path

–reference_data_path

test_data_set

-t or –test_data_set

test_data_path

–test_data_path

target_grid

–target_grid

regrid_tool

–regrid_tool

regrid_method

–regrid_method

regrid_tool_ocn

-regrid_tool_ocn

regrid_method_ocn

-regrid_method_ocn

period

–period

realization

–realization

simulation_description_mapping

–simulation_description_mapping

model_tweaks

–model_tweaks

ext

–ext

dry_run

–dry_run

filename_template

–filename_template

sftlf_filename_template

–sftlf_filename_template

custom_observations

–custom_observations

metrics_output_path

–metrics_output_path

filename_output_template

–filename_output_template

save_test_clims

–save_test_clims

test_clims_interpolated_output

–test_clims_interpolated_output

compute_custom_metrics

–compute_custom_metrics

Examples#

How to use PMPParser in your driver#

#!/usr/bin/env python
from pcmdi_metrics.pcmdi.pmp_parser import *
# soon the import statement will be:
# from pcmdi_metrics.driver.pmp_parser import *
parser = PMPParser() # Includes all default options

parser.add_argument(
    '-n', '--newarg',
    type=ast.literal_eval, #loading in a dictionary
    dest='newarg',
    help='description',
    required=False)

parameter = parser.get_parameter()
# All parameters can be referenced like so:
# parameter.vars
# parameter.regions
# ...

Reading in a list from the command line#

driver -v var1 var2 var3

results in parameter.var being ['var1', 'var2', 'var3']

Reading in a dictionary from the command line#

driver --regions '{"tas": [None, "terre", "ocean"], "tos": [None, ]}'

results in parameter.regions being {'tos': [None], 'tas': [None, 'terre', 'ocean']}

More PMPParser Info#

This guide is intended to bring developers (and maybe users) up to speed with the changes done when refactoring pmp to use cdp. If you don’t know what cdp is, look here.

What changed#

Vocabulary for the parameter has changed to account for the new paradigm of reference data set vs test data set, instead of just observation vs model. See here

All other cdp related stuff is in the src/python/pcmdi/scripts/driver/ folder. This include the pmp_parser, which is no longer in src/python/pcmdi/.

The majority of the work was done to the pcmdi_metrics_driver.py, which is now named pcmdi_metrics_driver_legacy.py. The new driver is now named pcmdi_metrics_driver.py. Both are executable via the command line. The next section details the changes done to the driver.

Changes to the driver#

Though not a requirement of cdp, the driver is now programmed in an object-oriented fashion. There are many good reasons to this, which you can see by googling it. Below is an explanation of the classes, which are located in src/python/pcmdi/scripts/driver/.

  • PMPParameter: Inherits from CDPParameter. Contains the stuff that’s usually in a Python parameter script. Eventually, we want to add error checking to the heck_values() function.

  • PMPParser: Inherits from CDPParser, which it based on ArgumentParser. You can add/remove/change the arguments in the load_default_args() function if needed.

  • DataSet: One of the largest forthcoming changes to pmp is that observations and models can be used interchangeably. To do so, both must be of the same class, which is DataSet. DataSet is an abstract class that acts as an interface, with some functionality through static methods. Each DataSet object also has an attribute of type pmp_io.

  • Model: A concrete version of DataSet. Looking at this from the legacy code, this is all of the stuff in the model_versions loop. It just does stuff related to _model_file, which was called MODEL in the legacy version.

  • Observation: Another concrete version of DataSet. Looking at this from the legacy code, this is all of the stuff in the refs loop. It just does stuff related to _obs_file, which was called OBS in the legacy version.

  • PMPDriver: Inherits from CDPDriver. Has a PMPParser to get command line arguments. Composed of three functions, check_parameter(), run_diags(), export(). check_parameter() checks that the self.parameter has all of the stuff needed for this driver. run_diags() runs the diags. export() should export the results, but doesn’t do that yet because that’s already done in run_diags (but eventually will do it).

  • RunDiags: The actual work for PMPDriver.run_diags() is done by this class. This is where the main functionality is. This loops through all of the vars, regions, reference_data_set and test_data_set in that order. This also determines if the comparison is obs vs obs, obs vs model, or model vs model.

  • OutputMetrics When RunDiags gets the data from Model or Observation (via DataSet.get()), these get sent to OutputMetrics which creates the metrics_dictionary, computes the metrics needed, and outputs the results. Also has an out_file and clim_file, which were respectively OUT and CLIM previously.