Scratch for aniket

Using panoply, ensure that you load the openjdk module first. I added the following line to my ~/.bashrc file to simplify running panoply: alias panoply="module load openjdk; bash ${HOME}/PanoplyJ/panoply.sh"

Note that I downloaded the PanoplyJ to the ${HOME} folder.

My recommendation is to look in the /scratch/cjablono_root/cjablono0/daniket/, which is your scratch directory and find the .nc (NetCDF) file generated by our previous model run. Do this in bash first so you know where it is. Now run panoply and open that .nc file.

At this point you can start generating plots. My first recommendation would be to look at the PS field (which is surface pressure). Create latitude-longitude plots for different temporal snapshots. This will show the evolution of the wave. The fields U and V contain, respectively, zonal (east-west) and meridional (north-south) wind. Note that these variables have an extra dimension compared to PS, which is lev. This is the vertical level. Surface pressure is only defined at the surface. How does the U field differ from the PS and V fields at the first time snapshot? Does the time evolution of PS and V exhibit similarities?

Probably the most interesting field for this simulation is the temperature field, T, given in units of Kelvin. What do you notice about the initial distribution of temperature? How does it change at different levels of the model within the first time snapshot? How does the time-evolution of T mirror and how does it differ from the evolution of U and V. Given that V represents wind, think about e.g. walking past the door to an air-conditioned building on a hot day when the door opens. Wind coming from inside the building transports cool air from inside to where you are on the outside. How does that relate to what we're seeing in the T field?

Modifying the source code

Since you already have a case directory, I'll assume that you have the location stored in a variable called $CASE_DIR. The contents of this directory should look like: and if you lost it and want to find it again (or, more specifically, find all case directories contained in your home directory) then you can run find ~ -name "SourceMods".

We will work from within the case directory, so run cd ${CASE_DIR}. The way that source code modifications work in CAM is that if you take a fortran source file (these end in the suffix .f90 or .f) and copy it to ${CASE_DIR}/SourceMods/src.cam/ and run ./case.build to rebuild the case, then any modifications made to the source file will be included in the executable for your case.

We'll work with the concrete example of the source file ic_baro_dry_jw06.F90 which defines the initial conditions for the test case that we're running.

To find the location of the original file, you can run find ~ -name "ic_baro_dry_jw06.F90"

From within your case directory you should run cp ${PATH_TO_IC_BARO_DRY}/ic_baro_dry_jw06.F90 SourceMods/src.cam. Using your text editor of choice (nano and vim are simple choices, but vim has a few early stumbling blocks) to edit the copied file. For me that reads as vim SourceMods/src.cam/ic_baro_dry_jw06.F90.

The crucial parameters that define the test case are found in this file, in the section of the code that looks like The description of the structure of this test case can be found in the following paper.

A good introductory exercise for learning how to change CAM source code is changing these parameters and seeing how this impacts the resulting model output.

A good starting parameter to change is perturbation_amplitude which is the strength of the nudge that starts the wave in motion. To see how this works, we'll start by running two simulations. An important caveat is that if you are running a particular case (which is a particular configuration of the CAM model) that lives in $CASE_DIR multiple times, the output NetCDF file will be overwritten.

Keeping this in mind, I lay before you the following challenge:

  1. Copy the fortran file to the SourceMods/src.cam directory and build the model using ./case.build.
  2. Run the model with the default value of perturbation_amplitude set in the SourceMods/src.cam/ic_baro_dry_jw06.F90, i.e. run ./case.submit. Note: you can check the status of running jobs with squeue -u ${USER}. Once your job completes, continue to the next step.
  3. Find the output NetCDF file. The right-most directory in ${CASE_DIR} (in my setup this is CAM_JUNE22.ne30_ne30_mg17.FADIAB.36.test_cases.jw06) is the name of your case. Since your scratch directory is located at /scratch/cjablono_root/cjablono0/daniket/ try to find a directory that has the same case name as what we found in ${CASE_DIR}.
  4. Navigate to this directory, which should contain two subdirectories, bld, and run. Navigate into the run subdirectory.
  5. If all has gone to plan, there should be a file with the .nc suffix, which you can find by doing ls *.nc.
  6. Rename this NetCDF file to something like default_perturbation_amplitude.nc
  7. Go back to your case directory. Modify SourceMods/src.cam/ic_baro_dry_jw06.F90 to double the strength of the perturbation.
  8. Run ./case.build and if this completes successfully run ./case.submit. Wait for the job to complete.
  9. Navigate to the output directory and rename the NetCDF file to something like doubled_perturbation_amplitude.nc.
  10. A little exercise to test your retention: Determine the steps you need to do to run the model with perturbation_amplitude set to 0. Rename the NetCDF file to something like nil_perturbation_amplitude.nc.

After you're done, you should have an output directory that contains three NetCDF files: one where the model was run with a default perturbation amplitude, one where the perturbation amplitude is doubled, and one where the perturbation is not present. Use panoply to explore these output files and try to figure out what changed. Is there a pattern? Try to see if you can see why; if you're interested in thinking deeply about this, you should look at the paper I linked above which covers the details of this test case in gory detail.

Keep me posted!!

If you get through this wicked fast and are interested in doing something else, my next suggestion is to break the test case in a major way. I won't tell you how to do it, surprise me. Make sure it's not so broken that the model doesn't run. Explain what you did.

Parent post: