Welcome to the MPAS tutorial practice guide

In the previous session, we started the process of interpolating static geographical fields to the 240-km, quasi-uniform mesh in the 240km_uniform directory. If this interpolation was successful, this directory should contain two new files: log.init_atmosphere.0000.out and x1.10242.static.nc.

$ cd ${HOME}/240km_uniform
$ ls -l log.init_atmosphere.0000.out x1.10242.static.nc

The end of the log.init_atmosphere.0000.out file should show that there were no errors:

 -----------------------------------------
 Total log messages printed:
    Output messages =                 3952
    Warning messages =                   7
    Error messages =                     0
    Critical error messages =            0
 -----------------------------------------

We can also make a plot of the terrain elevation field in the x1.10242.static.nc file with an NCL script named plot_terrain.ncl. We'll discuss the use of NCL scripts for visualization in a later session, so for now we can simply execute the following commands to plot the terrain field:

$ cp /classroom/wrfhelp/mpas/ncl_scripts/plot_terrain.ncl .
$ setenv FNAME x1.10242.static.nc
$ ncl plot_terrain.ncl

Running the script may take up to a minute, but the result should be the display of a figure that looks like the following:

Now that we have convinced ourselves that the processing of static, geographical fields was successful, we can proceed to interpolate atmosphere and land-surface initial conditions for our 240-km simulation. Generally, it is necessary to use the ungrib component of the WRF Pre-Processing System to prepare atmospheric datasets in the intermediate format used by MPAS. For the purposes of this tutorial, we will simply assume that these data have already been processed with the ungrib program in /classroom/wrfhelp/mpas/met_data/.

To interpolate the NCEP GFS data valid at 0000 UTC on 10 September 2014 to our 240-km mesh, we will symbolically link the GFS:2014-09-10_00 to our working directory:

$ ln -s /classroom/wrfhelp/mpas/met_data/GFS:2014-09-10_00 .

Then, we will need to edit the namelist.init_atmosphere as described in the lectures to instruct the init_atmosphere_model program to interpolate the GFS data to our mesh. The critical items to set in the namelist.init_atmosphere file are:

&nhyd_model
    config_init_case = 7
    config_start_time = '2014-09-10_00:00:00'
/
&dimensions
    config_nvertlevels = 41
    config_nsoillevels = 4
    config_nfglevels = 38
    config_nfgsoillevels = 4
/
&data_sources
    config_met_prefix = 'GFS'
    config_landuse_data = 'USGS'
    config_topo_data = 'GTOPO30'
    config_use_spechumd = false
/
&vertical_grid
    config_ztop = 30000.0
    config_nsmterrain = 1
    config_smooth_surfaces = true
    config_dzmin = 0.3
    config_nsm = 30
    config_tc_vertical_grid = true
/
&preproc_stages
    config_static_interp = false
    config_native_gwd_static = false
    config_vertical_grid = true
    config_met_interp = true
    config_input_sst = false
    config_frac_seaice = true
/

You may find it easier to copy the default namelist.init_atmosphere file from ${HOME}/MPAS-Model/namelist.init_atmosphere before making the edits highlighted above.

When editing the namelist.init_atmosphere file, the key changes are to the starting time for our real-data simulation, the prefix of the intermediate file that contains the GFS atmospheric and land-surface fields, and the pre-processing stages that will be run. For this simulation, we'll also use just 41 vertical layers in the atmosphere, rather than the default of 55, so that the simulation will run faster.

After editing the namelist.init_atmosphere file, we will also need to set the name of the input file in the streams.init_atmosphere file to the name of the "static" file that we just produced:

<immutable_stream name="input"
                  type="input"
                  filename_template="x1.10242.static.nc"
                  input_interval="initial_only"/>

and we will also need to set the name of the output file, which will be the MPAS real-data initial conditions file:

<immutable_stream name="output"
                  type="output"
                  filename_template="x1.10242.init.nc"
                  packages="initial_conds"
                  output_interval="initial_only" />

Once we've made the above changes to the namelist.init_atmosphere and streams.init_atmosphere files, we can run the init_atmosphere_model program:

$ ./init_atmosphere_model

The program should take just a minute or two to run, and the result should be an x1.10242.init.nc file and a new log.init_atmosphere.0000.out file. Assuming no errors were reported at the end of the log.init_atmosphere.0000.out file, we can plot, e.g., the skin temperature field in the x1.10242.init.nc file using the plot_tsk.ncl NCL script:

$ cp /classroom/wrfhelp/mpas/ncl_scripts/plot_tsk.ncl .
$ setenv FNAME x1.10242.init.nc
$ ncl plot_tsk.ncl

Again, we'll examine the use of NCL scripts for visualization later, so for now we only need to verify that a plot like the following is produced:

If a plot like the above is produced, then we have completed the generation of an initial conditions file for our 240-km real-data simulation!

Because MPAS-Atmosphere — at least, when run as a stand-alone model — does not contain prognostic equations for the SST and sea-ice fraction, these fields would remain constant if not updated from an external source; this is, of course, not realistic, and it will generally impact the quality of longer model simulations. Consequently, for MPAS-Atmosphere simulations longer than roughly a week, it is typically necessary to periodically update the sea-surface temperature (SST) field in the model. For real-time simulations, this is generally not an option, but it is feasible for retrospective simulations, where we have observed SST analyses available to us.

In order to create an SST update file, we will make use of a sequence of intermediate files containing SST and sea-ice analyses that are available in /classroom/wrfhelp/mpas/met_data. Before proceeding, we'll link all of these SST intermediate files into our working directory:

$ ln -sf /classroom/wrfhelp/mpas/met_data/SST* .

Following Section 7.2.2 of the MPAS-Atmosphere Users' Guide, we must edit the namelist.init_atmosphere file to specify the range of dates for which we have SST data, as well as the frequency at which the SST intermediate files are available. The key namelist options that must be set are shown below; other options can be ignored.

&nhyd_model
    config_init_case = 8
    config_start_time = '2014-09-10_00:00:00'
    config_stop_time = '2014-09-20_00:00:00'
/

&data_sources
    config_sfc_prefix = 'SST'
    config_fg_interval = 86400
/

&preproc_stages
    config_static_interp = false
    config_static_interp = false
    config_vertical_grid = false
    config_met_interp = false
    config_input_sst = true
    config_frac_seaice = true
/

Note in particular that we have set the config_init_case variable to 8! This is the initialization case used to create surface update files, instead of real-data initial condition files.

As before, we also need to edit the streams.init_atmosphere file, this time setting the name of the SST update file to be created by the "surface" stream, as well as the frequency at which this update file should contain records:

<immutable_stream name="surface"
                  type="output"
                  filename_template="x1.10242.sfc_update.nc"
                  filename_interval="none"
                  packages="sfc_update"
                  output_interval="86400"/>

Note that we have set both the filename_template and output_interval attributes of the "surface" stream. The output_interval should match the interval specified in the namelist for the config_fg_interval variable. The other streams ("input" and "output") can remain unchanged — the input file should still be set to the name of the static file.

After setting up the namelist.init_atmosphere and streams.atmosphere files, we're ready to run the init_atmosphere_model program:

$ ./init_atmosphere_model

After the job completes, as before, the log.init_atmosphere.0000.out file should report that there were no errors. Additionally, the file x1.10242.sfc_udpate.nc file should have been created.

We can confirm that the x1.10242.sfc_udpate.nc contains the requested valid times for the SST and sea-ice fields by printing the "xtime" variable from the file; in MPAS, the "xtime" variable in a netCDF file is always used to store the times at which records in the file are valid.

$ ncdump -v xtime x1.10242.sfc_update.nc

This ncdump command should print the following times:

 xtime =
  "2014-09-10_00:00:00                                             ",
  "2014-09-11_00:00:00                                             ",
  "2014-09-12_00:00:00                                             ",
  "2014-09-13_00:00:00                                             ",
  "2014-09-14_00:00:00                                             ",
  "2014-09-15_00:00:00                                             ",
  "2014-09-16_00:00:00                                             ",
  "2014-09-17_00:00:00                                             ",
  "2014-09-18_00:00:00                                             ",
  "2014-09-19_00:00:00                                             ",
  "2014-09-20_00:00:00                                             " ;

If the times shown above were printed, then we have successfully created an SST and sea-ice update file for MPAS-Atmosphere. As a final check, we can use the NCL script from /classroom/wrfhelp/mpas/ncl_scripts/plot_delta_sst.ncl to plot the difference in the SST field between the last time in the surface update file and the first time in the file.

Because the surface update file contains no information about the latitude and longitude of grid cells, we need to specify two environment variables when running this script: one to give the name of the surface update file, and the second to give the name of the grid file, which contains cell latitude and longitude fields:

$ cp /classroom/wrfhelp/mpas/ncl_scripts/plot_delta_sst.ncl .
$ setenv FNAME x1.10242.sfc_update.nc
$ setenv GNAME x1.10242.static.nc
$ ncl plot_delta_sst.ncl

In this plot, we have masked out the SST differences over land, since the values of the field over land are not representative of actual SST differences, but may represent differences in, e.g., skin temperature or 2-m air temperature, depending on the source of the SST analyses.

Assuming that an initial condition file and a surface update file have been created, we're ready to run the MPAS-Atmosphere model itself!

Working from our 240km_uniform directory, we'll begin by creating a symbolic link to the atmosphere_model executable that we compiled in ${HOME}/MPAS-Model. We'll also make copies of the namelist.atmosphere and streams.atmosphere files as well. Recall from when we compiled the model that there are stream_list.atmosphere.* files that accompany the streams.atmosphere file; we'll copy these as well.

$ ln -s ${HOME}/MPAS-Model/atmosphere_model .
$ cp ${HOME}/MPAS-Model/namelist.atmosphere .
$ cp ${HOME}/MPAS-Model/streams.atmosphere .
$ cp ${HOME}/MPAS-Model/stream_list.atmosphere.* .

You'll also recall that there were many look-up tables and other data files that are needed by various physics parameterizations in the model. Before we can run MPAS-Atmosphere, we'll need to create symbolic links to these files as well in our working directory:

$ ln -s ${HOME}/MPAS-Model/src/core_atmosphere/physics/physics_wrf/files/* .

Before running the model, we will need to edit the namelist.atmosphere file, which is the namelist for the MPAS-Atmosphere model itself. The default namelist.atmosphere is set up for a 120-km mesh; in order to run the model on a different mesh, there are several key parameters that depend on the model resolution:

• config_dt — the model timestep (delta-t) in seconds.
• config_len_disp — the length-scale for explicit horizontal diffusion, in meters.

To tell the model the date and time at which integration will begin (important, e.g., for computing solar radiation parameters), and to specify the length of the integration to be run, there are two other parameters that must be set for each simulation:

• config_start_time — the start time of the integration.
• config_run_duration — the length of the integration.

Lastly, when running the MPAS-Atmosphere model in parallel, we must tell the model the prefix of the filenames that contain mesh partitioning information for different MPI task counts:

• config_block_decomp_file_prefix — the file prefix (to be suffixed with processor count) of the file containging mesh partitioning information.

Accordingly, we must edit at least these parameters in the namelist.atmosphere file; other parameters are described in Appendix B of the MPAS-Atmosphere Users' Guide, and do not necessarily need to be changed:

&nhyd_model
    config_dt = 1200.0
    config_start_time = '2014-09-10_00:00:00'
    config_run_duration = '5_00:00:00'
    config_len_disp = 240000.0
/

&decomposition
    config_block_decomp_file_prefix = 'x1.10242.graph.info.part.'
/

For a relatively coarse mesh like the 240-km mesh, we can also call the radiation schemes less frequently to allow the model to run a little more quickly. Let's set the radiation calling interval to 1 hour:

&physics
    config_radtlw_interval = '01:00:00'
    config_radtsw_interval = '01:00:00'
/

After changing the parameters shown above in the namelist.atmosphere file, we must also set the name of the initial condition file, the name of the surface update file, and the interval at which we would like to read the surface update file in the streams.atmosphere file:

<immutable_stream name="input"
                  type="input"
                  filename_template="x1.10242.init.nc"
                  input_interval="initial_only"/>

<stream name="surface"
        type="input"
        filename_template="x1.10242.sfc_update.nc"
        filename_interval="none"
        input_interval="86400">

    <file name="stream_list.atmosphere.surface"/>

</stream>

Having set up the namelist.atmosphere and streams.atmosphere files, we're almost ready to run the model in parallel. You'll recall from the lectures that we need to supply a graph partition file to tell MPAS how the horizontal domain is partitioned among MPI tasks. Accordingly, we'll create a symbolic link to the partition file for 4 MPI tasks for the 240-km mesh in our working directory:

$ ln -s /classroom/wrfhelp/mpas/meshes/x1.10242.graph.info.part.4 .

As a general rule, a mesh with N grid columns should be run on at most N/160 processors in MPAS-Atmosphere to make efficient use of the processors. So, for the mesh in this exercise, which has 10242 grid columns, we could in principle use up to about 64 MPI tasks while still making relatively efficient use of the computing resources. For this exercise, however, we only have 4 cores available to us.

Now, we should be able to run MPAS using 4 MPI tasks:

$ mpiexec -n 4 ./atmosphere_model

Once the model begins to run, it will write information about its progress to the log.atmosphere.0000.out file. From another terminal window, we can use tail -f to follow the updates to the log file as the model runs:

$ tail -f log.atmosphere.0000.out

If the model has started up successfully and begun to run, we should see messages like this

 Begin timestep 2014-09-10_06:00:00
 --- time to run the LW radiation scheme L_RADLW =T
 --- time to run the SW radiation scheme L_RADSW =T
 --- time to run the convection scheme L_CONV    =T
 --- time to apply limit to accumulated rainc and rainnc L_ACRAIN   =F
 --- time to apply limit to accumulated radiation diags. L_ACRADT   =F
 --- time to calculate additional physics_diagnostics               =F
  split dynamics-transport integration 3
 
 global min, max w -0.177687 0.512867
 global min, max u -112.127 112.008
  Timing for integration step: 5.78077 s

written for each timestep that the model takes. If not, a log.atmosphere.0000.err file may have been created, and if so, it may have messages to indicate what might have gone wrong.

The model simulation will take about an hour to complete. As it runs, you may notice that several netCDF output files are being created:

• diag.2014.09.*.nc — These files contain mostly 2-d diagnostic fields that were listed in the stream_list.atmosphere.diagnostics file.
• history.2014.09.*.nc — These files contain mostly 3-d prognostic and diagnostic files from the model.
• restart.2014.09.*.nc — These are model restart files that are essentially checkpoints of the model state; a simulation can be re-started from any of these checkpoint/restart files.

If the model has successfully begun running, we can move to the next sub-section to obtain and compile the convert_mpas utility for interpolating model output files to a lat-lon grid for quick visualization.

We saw in earlier sections that NCL scripts may be used to visualize fields in MPAS netCDF files. Although these scripts can produce publication-quality figures, many times all that is needed is a way to quickly inspect the fields in a file. The convert_mpas program is designed to interpolate fields from the unstructured MPAS mesh to a regular lat-lon grid for easy checking, e.g., with ncview.

As with the MPAS-Model code, the convert_mpas code may be obtained most easily by cloning a GitHub repository. Working from our home directory, we'll download the code in this way:

$ cd ${HOME}
$ git clone https://github.com/mgduda/convert_mpas.git
$ cd convert_mpas

The convert_mpas utility is compiled via a simple Makefile. In general, one can edit the Makefile in the main convert_mpas directory. On these classroom machines, the netCDF library version is quite old, so we'll need to make one change in the Makefile, deleting the string "-DHAVE_NF90_INQ_VARIDS".

We also need to make one small code change for these classroom machines: in the src/file_output.F file, we need to replace the string "NF90_NETCDF4" with "NF90_64BIT_OFFSET".

After making these two changes, we can build the convert_mpas utility with the make command:

$ make

If compilation was successful, there should now be an executable file named convert_mpas. So that we can run this program from any of our working directories, we'll add our current directory to our shell ${PATH} environment variable:

$ setenv PATH ${HOME}/convert_mpas:${PATH}

You may like to take a few minutes to read through the README.md file to familiarize yourself with the usage of the convert_mpas program. We'll have a chance to exercise the convert_mpas utility in the next practical session.

A common theme with MPAS is the need to obtain source code from git repositories hosted on GitHub. The grid_rotate utility is no exception in this regard. One difference, however, is that the grid_rotate code is contained in a repository that houses many different tools for MPAS cores, including the MPAS-Albany Land Ice core, the MPAS-Ocean core, and the MPAS-Seaice core.

The grid_rotate utility is found in the MPAS-Tools repository, which we can clone into our home directory with the following commands:

$ cd ${HOME}
$ git clone https://github.com/MPAS-Dev/MPAS-Tools.git

Within the MPAS-Tools repository, the grid_rotate code resides in the mesh_tools/grid_rotate sub-directory. On these classroom machines, we can change to this directory and build the grid_rotate utility with the make command:

$ cd MPAS-Tools/mesh_tools/grid_rotate
$ make

The netCDF library on these machines is quite old, so there may be some build warnings about missing nc-config commands; in this particular case, these can be ignored, but in general, one should be concerned with build warnings.

So that we can more easily run the grid_rotate program from any working directory, we'll add our current working directory to our shell ${PATH}.

$ setenv PATH ${HOME}/MPAS-Tools/mesh_tools/grid_rotate:${PATH}

Now that we have a means to rotate the location of refinement in a variable-resolution MPAS mesh, we can begin the process of preparing such a mesh. For this tutorial, we'll be using a mesh that refines from 240-km grid spacing down to about 48-km grid spacing over an elliptic region.

When creating initial conditions and running the 240-km quasi-uniform simulation, we worked in a sub-directory named 240km_uniform. For our variable-resolution simulation, we'll work in a sub-directory named 240-48km_variable to keep our work separated. Let's create the 240-48km_variable directory and link in the variable-resolution mesh from /classroom/wrfhelp/mpas/meshes into that directory:

$ cd ${HOME}
$ mkdir 240-48km_variable
$ cd 240-48km_variable
$ ln -s /classroom/wrfhelp/mpas/meshes/x5.30210.grid.nc .

The x5.30210.grid.nc mesh contains 30210 grid cells and refines by a factor of five (from 240-km grid spacing to 48-km grid spacing). The refinened region is centered over (0.0 lat, 0.0 lon), and we can get a quick idea of the size of the refinement by plotting contours of the approximate mesh resolution with the mesh_resolution.ncl NCL script:

$ cp /classroom/wrfhelp/mpas/ncl_scripts/mesh_resolution.ncl .
$ setenv FNAME x5.30210.grid.nc
$ ncl mesh_resolution.ncl

When running the mesh_resolution.ncl script, a plot like that below should be produced.

Using the grid_rotate tool, we can change the location and orientation of this refinement to an area of our choosing. Before running the grid_rotate program, we need a copy of the input namelist that is read by this program:

$ cp ${HOME}/MPAS-Tools/mesh_tools/grid_rotate/namelist.input .

As described in the lectures, we'll set the parameters in the namelist.input file to relocate the refined region in the mesh. For example, to move the refinement over South America, we might use:

&input
   config_original_latitude_degrees = 0
   config_original_longitude_degrees = 0

   config_new_latitude_degrees = -19.5
   config_new_longitude_degrees = -62
   config_birdseye_rotation_counter_clockwise_degrees = 90
/

Feel free to place the refinement wherever you would like!

After making changes to the namelist.input file, we can rotate the x5.30210.grid.nc file to create a new "grid" file with any name we choose. For example:

$ grid_rotate x5.30210.grid.nc SouthAmerica.grid.nc

As with the original x5.30210.grid.nc file, we can plot the approximate resolution of our rotated grid file with commands like the following:

$ setenv FNAME SouthAmerica.grid.nc
$ ncl mesh_resolution.ncl

Of course, the name SouthAmerica.grid.nc should be replaced with the name that you have chosen for your rotated grid when setting the FNAME environment variable. In our example, the resulting plot looks like the one below.

It may take some iteration to get the refinement just where you would like it. You can go back and edit namelist.input file, then re-run the grid_rotate program, and finally, re-run the ncl mesh_resolution.ncl command until you are satisfied!

Interpolating static, geographical fields to a variable-resolution MPAS mesh works in essentially the same way as it does for a quasi-uniform mesh. So, the steps taken in this section should seem familiar — they mirror what we did in Section 1.3!

To begin the process, we'll symbolically link the init_atmosphere_model executable into our 240-48km_variable directory, and we'll copy the default namelist.init_atmosphere and streams.init_atmosphere files as well:

$ ln -s ${HOME}/MPAS-Model/init_atmosphere_model .
$ cp ${HOME}/MPAS-Model/namelist.init_atmosphere .
$ cp ${HOME}/MPAS-Model/streams.init_atmosphere .

As before, we'll set the following variables in the namelist.init_atmosphere file:

&nhyd_model
    config_init_case = 7
/
&data_sources
    config_geog_data_path = '/classroom/wrfhelp/GEOG_DATA/WPS_GEOG/'
    config_landuse_data = 'USGS'
    config_topo_data = 'GTOPO30'
/
&preproc_stages
    config_static_interp = true
    config_native_gwd_static = true
    config_vertical_grid = false
    config_met_interp = false
    config_input_sst = false
    config_frac_seaice = false
/

In editing the streams.init_atmosphere file, we'll choose the filename for the "input" stream to match whatever name we chose for our rotated grid file:

<immutable_stream name="input"
                  type="input"
                  filename_template="SouthAmerica.grid.nc"
                  input_interval="initial_only"/>

and we'll set the filename for the "output" stream to follow the same naming convention, but using "static" instead of "grid":

<immutable_stream name="output"
                  type="output"
                  filename_template="SouthAmerica.static.nc"
                  packages="initial_conds"
                  output_interval="initial_only" />

With these changes, we can run the init_atmosphere_model program:

$ ./init_atmosphere_model

As before, processing of the static, geographical fields may take up to an hour.

While the static, geographical fields are being processed for our 240km – 48km variable-resolution mesh, we can experiment with the use of the convert_mpas utility to interpolate output from our 240-km, quasi-uniform simulation.

If you didn't have a chance to download and compile the convert_mpas program back in Section 2.4, you will need to go back to that section before proceeding with the rest of this section.

In another terminal window, we'll change to the 240km_uniform directory, and we may also need to add the directory containing the convert_mpas utility to our shell ${PATH} variable again:

$ cd ${HOME}/240km_uniform
$ setenv PATH ${HOME}/convert_mpas:${PATH}

In the 240km_uniform directory, we should see output files from MPAS that are named history*nc and diag*nc:

$ ls -l history*nc diag*nc
-rw-r--r-- 1 class101 cbet  4526928 Jul 28 21:03 diag.2014-09-10_00.00.00.nc
-rw-r--r-- 1 class101 cbet  4526928 Jul 28 21:04 diag.2014-09-10_03.00.00.nc
...
-rw-r--r-- 1 class101 cbet  4526928 Jul 28 21:26 diag.2014-09-14_21.00.00.nc
-rw-r--r-- 1 class101 cbet  4526928 Jul 28 21:26 diag.2014-09-15_00.00.00.nc
-rw-r--r-- 1 class101 cbet 94457824 Jul 28 21:03 history.2014-09-10_00.00.00.nc
-rw-r--r-- 1 class101 cbet 94457824 Jul 28 21:04 history.2014-09-10_06.00.00.nc
...
-rw-r--r-- 1 class101 cbet 94457824 Jul 28 21:25 history.2014-09-14_18.00.00.nc
-rw-r--r-- 1 class101 cbet 94457824 Jul 28 21:26 history.2014-09-15_00.00.00.nc

As a first try, we can interpolate the fields from the final model "history" file, history.2014-09-15_00.00.00.nc, to a 0.5-degree lat-lon grid with the command:

$ convert_mpas history.2014-09-15_00.00.00.nc

The interpolation should take less than a minute, and the result should be a file named latlon.nc. Let's take a look at this file with the ncview utility:

$ ncview latlon.nc

Depending on which field you've chosen to view first, you may need to change the coordinate axes that are displayed in ncview, e.g.,

After setting the coordinate axes in the "Axes" menu, we can, e.g., view the qv field, which may look something like the plot below at the lowest model level.

When we're done viewing the latlon.nc file, we'll delete it. The convert_mpas utility attempts to append to existing latlon.nc files when converting a new MPAS netCDF file, and this often doesn't work as expected, so to avoid confusion, it's best to remove the latlon.nc file we just created with

$ rm latlon.nc

before converting another MPAS output file.

As we just saw, it can take upwards of a minute to interpolate a single MPAS "history" file (at least, on these classroom machines). If we are only interested in a small subset of the fields in an MPAS file, we can restrict the interpolation to just those fields by providing a file named include_fields in our working directory.

Using an editor of your choice, create a new text file named include_fields with the following contents:

u10
v10
precipw

After saving the file, we can re-run the convert_mpas program as before to produce a latlon.nc file with just the 10-meter surface winds and precipitable water:

$ convert_mpas history.2014-09-15_00.00.00.nc
$ ncview latlon.nc

The convert_mpas program should have taken just a few seconds to run; if not, make sure the latlon.nc file was deleted before re-running convert_mpas. The only fields in the new latlon.nc file should be "precipw", "u10", and "v10".

Rather than converting just a single file at a time, we can convert multiple MPAS output files and write the results to the same latlon.nc file. The key to doing this is to use the first command-line argument to convert_mpas to specify a file that contains horizontal (SCVT) mesh information, and to let subsequent command-line arguments specify MPAS netCDF files that contain fields to be remapped.

To interpolate the "precipw", "u10", and "v10" fields for our entire 5-day simulation, we can use the following commands:

$ rm latlon.nc
$ convert_mpas x1.10242.init.nc history.*.nc
$ ncview latlon.nc

Note, again, that the first command-line argument to convert_mpas is only used to obtain SCVT mesh information by the convert_mpas program when multiple command-line arguments are given, and all remaining command-line arguments specifie netCDF files with fields to be interpolated!

When viewing a netCDF file with multiple time records, you can step through the time periods in ncview with the "forward" and "backward" buttons to the right and left of the "pause" button:

As a final exercise in viewing MPAS output via the convert_mpas and ncview programs, we'll zoom in on a part of the globe, looking at the 250 hPa vertical vorticity field over East Asia on a 1/10-degree lat-lon grid.

To do this, we will first need to edit the include_fields file so that it contains just the following line:

vorticity_250hPa

Then, we'll create a new file named target_domain with the editor of our choice. This file should contain the following lines:

startlat=30
endlat=60
startlon=90
endlon=150
nlat=300
nlon=600

After editing the include_fields file and creating the target_domain file, we can remove the old latlon.nc file and use the convert_mpas program to interpolate the 250 hPa vorticity field from our diag.*.nc files:

$ rm latlon.nc
$ convert_mpas x1.10242.init.nc diag*nc
$ ncview latlon.nc

If the processing of the static, geographical fields for the 240km – 48km variable-resolution mesh has not finished, yet, you can feel free to experiment more with the convert_mpas program!

Once the processing of the static, geographical fields has completed in the 240-48km_variable directory, we should have a new "static" file as well as a log.init_atmosphere.0000.out file. In our example, the static file is named SouthAmerica.static.nc, but your file should have whatever name was specified in the definition of the "output" stream in the streams.init_atmosphere file.

Before proceeding, it's a good idea to verify that there were no errors reported in the log.init_atmosphere.0000.out file. We can also make a plot of the terrain height field as we did for the 240-km quasi-uniform simulation:

$ cp /classroom/wrfhelp/mpas/ncl_scripts/plot_terrain.ncl .
$ setenv FNAME SouthAmerica.static.nc
$ ncl plot_terrain.ncl

Once we have convinced ourselves that the static, geographical processing was successful, we can proceed as we did for the 240-km quasi-uniform simulation. We'll create a symbolic link to the NCEP GFS intermediate file valid at 0000 UTC on 10 September 2014:

$ ln -s /classroom/wrfhelp/mpas/met_data/GFS:2014-09-10_00 .

As before, we'll set up the namelist.init_atmosphere file to instruct the init_atmosphere_model program to interpolate meteorological and land-surface initial conditions:

&nhyd_model
    config_init_case = 7
    config_start_time = '2014-09-10_00:00:00'
/
&dimensions
    config_nvertlevels = 41
    config_nsoillevels = 4
    config_nfglevels = 38
    config_nfgsoillevels = 4
/
&data_sources
    config_met_prefix = 'GFS'
    config_landuse_data = 'USGS'
    config_topo_data = 'GTOPO30'
    config_use_spechumd = false
/
&vertical_grid
    config_ztop = 30000.0
    config_nsmterrain = 1
    config_smooth_surfaces = true
    config_dzmin = 0.3
    config_nsm = 30
    config_tc_vertical_grid = true
/
&preproc_stages
    config_static_interp = false
    config_native_gwd_static = false
    config_vertical_grid = true
    config_met_interp = true
    config_input_sst = false
    config_frac_seaice = true
/

Besides the namelist.init_atmosphere file, we must also edit the XML I/O configuration file, streams.init_atmosphere, to specify the name of the static file that will serve as input to the init_atmosphere_model program, as well as the name of the MPAS-Atmosphere initial condition file to be created. Specifically, we must set the filename_template for the "input" stream to the name of our static file:

<immutable_stream name="input"
                  type="input"
                  filename_template="SouthAmerica.static.nc"
                  input_interval="initial_only"/>

and we must set the name of the initial condition file to be created in the "output" stream:

<immutable_stream name="output"
                  type="output"
                  filename_template="SouthAmerica.init.nc"
                  packages="initial_conds"
                  output_interval="initial_only" />

After editing the namelist.init_atmosphere and streams.atmosphere files, and linking the intermediate file to our run directory, we can run the init_atmosphere_model program.

$ ./init_atmosphere_model