|
|
| Line 35: |
Line 35: |
| === Obtaining MERRA Data === | | === Obtaining MERRA Data === |
|
| |
|
| MERRA output files are located under <code>/archive</code> on NCCS discover and can be time consuming to obtain. For this purpose a set of scripts have been created to make the task easier. To use them, create a subdirectory and copy the contents of <code>/discover/nobackup/aeichman/scm/util/get-merra</code> to it. You should have the following: | | MERRA output files are located under <code>/archive/u/dao_ops/MERRA/dao_ops/production/GEOSdas-2_1_4</code> on NCCS discover. You will need the output files spanning the desired dates of the experiment from following collections: |
|
| |
|
| getter.j | | inst3_3d_asm_Cp |
| MERRAobsys.rc | | tavg3_3d_tdt_Cp |
| README | | tavg3_3d_qdt_Cp |
| watcher.j | | tavg1_2d_slv_Nx |
| | tavg1_2d_flx_Nx |
|
| |
|
| | | While you only need the the one gridpoint or so from each collection, you will have to copy over the entire collection from <code>/archive</code>, which may take a couple days even with use of <code>dmget</code>. Maybe there's a better way with OPeNDAP? |
| To use the scripts, modify the line in <code>getter.j</code> starting <code>setenv PATH ${PATH}:</code> ... to point to the directory
| |
| <code>src/GMAO_Shared/GMAO_etc/</code> in your local Fortuna 2.0 build, which
| |
| contains the necessary utilities. These use perl
| |
| libraries, which might require additions to your environment. (Assume at first that they don't.) To specify the range of MERRA data to obtain, modify the variables
| |
| <code>BEGIN_date</code> and <code>END_date</code> (both in the format YYYYMMDD). You may need
| |
| to modify your group name in the PBS environment variables as well.
| |
| | |
| Then <code>qsub watcher.j</code> (''not'' <code>getter.j</code>). It will submit the <code>getter.j</code>
| |
| script while submitting a version of itself to monitor the "getter"
| |
| job. <code>getter.j</code> uses the <code>acquire</code> utility to smoothly transfer files from <code>/archive</code> to the current directory. If the getter job ends without finishing -- most likely
| |
| because the allotted walltime ran out -- then the watcher job will
| |
| repeat the process, until all the data in the specified range are
| |
| copied to the current directory. For data sets of a month or so this may take a few hours, but the scripts should run without intervention. If something interrupts this process, the same scripts may be started again, and <code>acquire</code> will be intelligent enough figure out where it needs to pick up. Keep in mind that response time of the <code>/archive</code> filesystem can vary considerably (on the scale of hours to days, depending on downtime).
| |
| | |
| For more details, see <code>README</code>.
| |
|
| |
|
| === Generating the Driving Data === | | === Generating the Driving Data === |