Changes between Version 25 and Version 26 of WRF4GWRFReforecast

May 2, 2013 1:54:22 PM (9 years ago)



  • WRF4GWRFReforecast

    v25 v26  
    5151Now we can configure our test experiment, following the instructions in [wiki:WRF4Gexperiment_wrf4g] and [wiki:WRF4Gresources_wrf4g]. Note that, as it is a reforecast, we need to use the [wiki:WRF4Gexperiment_wrf4g#Multipledatesruns multiple dates configuration variables].
     53Once we are finished, we can use the [wiki:WRF4GCommandLineInterface command line interface (CPI)] to prepare and submit our test experiment. Before submitting check in the output of wrf4g_prepare that the chunks and realizations being created are those that we wanted.
     57wrf4g_submit -e sw_test
     60Now we can monitor the experiment using [wiki:WRF4GCommandLineInterface#wrf4g_status wrf4g_status], along with the "watch" command.
     63watch wrf4g_status -l -e sw_test
     66Probably it will fail in the first attempts, so don't worry. If it fails, see [wiki:WRF4GTutorial2#HowtomanageWRF4Gerrors how to manage WRF4G errors] to look for the error.
     68Once the test experiment has run successfully, we should check that the output looks fine and that it contains all the variables that we want. Tools like [ ncview] and [ ncdump] are very useful for this task.
     70=== The experiment ===
     72At this point we are done with the most difficult issues, and we are ready to set up the reforecast experiment itself. Simply create another folder inside "submit" named "sw_ncep", and copy there the configuration files of the test experiment.
     75cd ..
     76mkdir sw_ncep
     77cp -r ../sw_test/* .
     80Then change the experiment_name and extend the end_date to the end date of the full experiment. In this example we will only run one month (January 2010), but it could be many decades. So our dates would be:
     87Finally, prepare and submit the experiment with WRF4G CLI, as before.
     91wrf4g_submit -e sw_test
     94=== Experiment monitoring ===
     96wrf4g_status permits us to monitor the state of all the realizations of the experiment. If the experiment is large, wrf4g_status can be used in combination with shell tools as grep or awk to filter the list with some criteria. For example:
     99wrf4g_status -l -e sw_test | grep Finished
     102Returns all the Finished realizations. Or, more complicated
     105wrf4g_status -l -e sw_test | grep -v Finished | grep -v Submitted | grep -v Failed
     108Returns all the realizations that are currently in some stage of the WRF4G workflow (Down. Bin., ungrib, metgrid..., etc.)
     110If wrf4g_submit is called again, the realizations in Failed status are submitted again. This is very useful to resubmit simulations after some problems with the infrastructure.
     112Other more complicated situation can occur. For example, if there is a blackout, the jobs can fail before they can send the "Failed" signal to the database. In that case, they can appear to be indefinitely in "WRF" status. These kind of problems need a less confortable monitoring, such as entering to the working nodes and use the commands "top" or "ps -ef" to see it WRF is really running.
     114When a realization has failed but does not appear with the "Failed" status, it can be resubmitted using the --force flag of wrf4g_submit.  Note also that wrf4g_submit can be used refering only to one realization or chunk, using the flags, -r or -c.