Making VMR files

This section assumes that you have completed Making model files. Like that section, this will assume you want to use GEOS FP files, since those files are available without a data subscription. However, please note that GEOS FP is not the standard met source for TCCON and COCCON priors, and therefore .mod, .vmr, and .map file generated from GEOS FP are not suitable for standard data production for those networks.

Creating .vmr files for dates

As with the previous steps, we will use the run_ginput.py script to call ginput.

To generate the actual .vmr files, we use the vmr subcommand. We’ll assume that we are going to generate the .vmr files corresponding to the .mod files we made in Making model files, so:

  • the files were output under MOD_FILE_DIR,

  • we are generating the files for 1 Jan 2018,

  • the site latitude and longitude are 36.604 N and 97.486 W,

  • we used GEOS FP met data as input, and

  • we want to write the .vmr files to VMR_FILE_DIR.

Given these assumptions, our command is:

$ ./run_ginput.py vmr \
    --product fp \
    --lon -97.486 \
    --lat 36.604 \
    --base-vmr-file ginput/testing/test_input_data/summer_35N.vmr \
    --integral-file ginput/testing/test_input_data/ap_51_level_0_to_70km.gnd \
    --save-path VMR_FILE_DIR \
    --auto-update-fo2-file \
    20180101 \
    MOD_FILE_DIR/fp/xx/vertical

Note

Remember, if you installed with conda or pip, you probably want to use ginput_cli instead of ./run_ginput.py.

Note

ginput v1.3 added a requirement for O2 mole fraction data when generating the .vmr files. For v1.3, you would have to execute the command ./run_ginput update_fo2 once before creating any .vmr files. From v1.3.1 on, you can use the --auto-update-fo2-file flag for the vmr subcommand as shown below. If you are using a version of ginput before 1.3, you will not have the update_fo2 subcommand nor the --auto-update-fo2-file flag, and ginput will not add the O2 mole fractions to the .vmr file headers.

This part of ginput requires several look up tables to be pre-calculated. The first time you run it, it will calculate them and save them as netCDF files. On successive runs, it will load the netCDF files unless any of the inputs or code needed to make those files have changed since the last run. Thus, your first run will be slow, but later runs will be significantly faster.

Some things to take note of:

  1. We do not need to specify altitude here, only latitude and longitude.

  2. We do need to indicate that we used GEOS FP, now with the --product option instead of --mode. However, we do not need to indicate that we used eta level files, so unlike the previous step, the value here is only “fp”, not “fp-eta”.

  3. We point to two files under ginput/testing/test_input_data. If you have GGG installed, it is recommended to point to the versions of these files that come with GGG. summer_35N.vmr is under $GGGPATH/vmrs/gnd and ap_51_level_0_to_70km.gnd is under $GGGPATH/levels.

Like with the model files, we will get a tree output directory like so:

VMR_FILE_DIR
└── fp
    └── xx
        └── vmrs-vertical
            ├── JL1_2018010100Z_37N_097W.vmr
            ├── JL1_2018010103Z_37N_097W.vmr
            ├── JL1_2018010106Z_37N_097W.vmr
            ├── JL1_2018010109Z_37N_097W.vmr
            ├── JL1_2018010112Z_37N_097W.vmr
            ├── JL1_2018010115Z_37N_097W.vmr
            ├── JL1_2018010118Z_37N_097W.vmr
            └── JL1_2018010121Z_37N_097W.vmr

See Making model files for an explanation of the meaning of each level.

Producing .vmr files for a runlog

As with the .mod files, ginput can generate the specific .vmr files needed for a GGG runlog. (If you don’t know what a runlog is, you can skip this section.) The following example shows how to create the .vmr files for the Park Falls benchmark runlog included with GGG. Like with the .mod files, this example uses GEOS FP-IT data, because GEOS FP does not cover the year needed by this runlog.

$ ./run_ginput.py rlvmr \
    --base-vmr-file ginput/testing/test_input_data/summer_35N.vmr \
    --integral-file ginput/testing/test_input_data/ap_51_level_0_to_70km.gnd \
    --product fpit \
    --mod-root-dir MOD_FILE_DIR \
    --save-path VMR_FILE_DIR \
    --auto-update-fo2-file \
    $gggpath/runlogs/gnd/pa_ggg_benchmark.grl

Most of the options are the same as the example above where we specific the dates to generate. However, notice that instead of giving the full path to the .mod files as the second positional argument, we use the --mod-root-dir option and point it to the top directory that the .mod files were output to. This directory must have the structure met/site/vertical. For our example, it would be:

MOD_FILE_DIR
└── fpit
    └── pa
        └── vertical
            ├── FPIT_2004072121Z_46N_090W.mod
            ├── FPIT_2004072200Z_46N_090W.mod
            └── FPIT_2004122215Z_46N_090W.mod

The reason we recommend using --mod-root-dir in this case is that, if your runlog contains multiple sites, this allows ginput to automatically select the correct subdirectory, assuming that your .mod files are organized in the above structure. On the other hand, if all of your .mod files are in one directory (even from different sites), then passing the path to that directory as the second positional argument and omitting the --mod-root-dir option instead will handle that organization.