Run Hurricane Matthew test case in METplus container #48
Comments
jaredalee
added
component: METplus
|
As a placeholder until the WRF output from the Hurricane Matthew test case from the container is available, the output from a standalone version of WRF for this case is here: /glade/derecho/scratch/jaredlee/nsf_i-wrf/matthew/wrf |
|
@georgemccabe, @jaredalee, and @JohnHalleyGotway met on April 17th for a working session. Steps:
|
|
In branch https://github.com/NCAR/i-wrf/tree/feature/48_matthew_metplus, I created the directory structure for the use cases from @JohnHalleyGotway's comment above. I also committed the in-progress METplus configuration file for the Hurricane Matthew example. The config file has been set to read the WRF data (using a hard-coded path).
|
|
@JohnHalleyGotway and @georgemccabe |
|
George & I just finished a working meeting, where we set up the METplus config file (in the commit referenced just above) to: a) read in the WRF output file successfully We uncovered a bug in MET where it doesn't currently read in multiple obs files. George will create an issue and then fix that. Next time we'll add configurations to handle processing the RAOB obs file and determine if MET is properly interpolating native-grid WRF output to pressure levels, or if WRF needs to be re-run to output variables on specific pressure levels in a different file. |
|
During the i-wrf tech team meeting on 5/3/24, @dudhia recommended the following:
Note that these changes are rather large and should probable be done via a separate issue. For this issue while working on the hurricane Matthew instructions, please just scope out the idea, and if feasible, write up a separate issue to describe this potential future enhancement. |
|
These notes expand on the previous comment and should be added to the new issue when it is created: There is already a METplus wrapper for the GFDLTracker. I created a Docker image on DockerHub that contains the tracker that is used to run it for the METplus automated tests. This Dockerfile could be copied and modified to create a Docker container that includes METplus and the tracker. The image created includes patches so it can be compiled using GCC instead of Intel. We could instead compile it using Intel since we already compile WRF using Intel. Here is the Dockerfile that builds the tracker using GCC: |
|
Here's a list of recommended improvements to MET/METplus:
Only warn about this when VCNT output is requested.
|
|
I was able to get a successful METplus run using apptainer on casper. To load apptainer and pull the METplus image: This creates a local file called Create local output directory: Set environment variable to bind directories to container (note: this can also be accomplished by passing the value on the command line using the
Execute the run_metplus.py command inside the container to run the use case: Check that the output data was created locally:
If you need to run on casper outside of apptainer, you can override the input directory values with the actual paths on casper: Resources: |
|
I was able to create a Docker "artifact" that can be pulled and mounted using apptainer. This is what I had to do on casper to create it: To create volume (directory obs existed in current directory that contained observation data): To push volume sif (artifact) to DockerHub: Then to run I had to pull the artifact using oras, then bind it to container: Resources: |
* per #48, create directory structure to store files needed for each use case example * per #48, add in-progress METplus config file * per #48, update use case config to read metar observations and compute statistompute statistics * Configure 2 instances of PointStat to process surface and upper air separately (until dtcenter/METplus#2567 is completed). Adjust settings to produce more useful output, prevent wind vector warnings, filter out duplicate obs, define pressure levels, etc. * change configuration to overwrite fcst level to avoid messy NetCDF level value and change output flag settings to get results that can be more easily plotted * change input directory paths to paths that are expected inside the container that are mounted -- left paths on casper for reference * process all forecast leads and pressure levels * change obs window to prevent observations from being matched with multiple model files * add file window to get multiple observation input files * Per #48, add instructions to run METplus use case on HPC using apptainer * update RTD documentation requirements to specify sphinx * add JetBrains files * add other requirements for documentation * change to consistent format as other entries * Reformat info about local and container paths that are mounted * add WRF configuration files * run MADIS2NC as part of the use case instead of using output from the tool * updated instructions to obtain obs data from artifact stored on DockerHub instead of local directory * updated instructions to use full paths instead of changing directories, added steps to clone i-wrf repo to get METplus config files * removed commented lines
Describe the Task
Using the WRF output generated by #46 and the observation data obtained in #47, generate some sample verification statistics with the METplus container. Document what commands/steps were used. This will also serve as another test to make sure that #5 is working properly.
Time Estimate
Estimate the amount of work required here.
Issues should represent approximately 1 to 3 days of work.
Sub-Issues
Consider breaking the task down into sub-issues.
Relevant Deadlines
List relevant project deadlines here or state NONE.
Funding Source
7790013
Define the Metadata
Assignee
Labels
Projects and Milestone
Task Checklist
Branch name:
feature_<Issue Number>_<Description>Pull request:
feature <Issue Number> <Description>Select: Reviewer(s) and Development issues
Select: Repository level development cycle Project for the next official release
Select: Milestone as the next official version
The text was updated successfully, but these errors were encountered: