Changes between Version 25 and Version 26 of WRF4GWRFReforecast

Timestamp:

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

Author:

MarkelGarcia

Comment:

--

WRF4GWRFReforecast

@@ -50 +50 @@
 
 Now 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].
+
+Once 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.
+
+{{{
+wrf4g_prepare
+wrf4g_submit -e sw_test
+}}}
+
+Now we can monitor the experiment using [wiki:WRF4GCommandLineInterface#wrf4g_status wrf4g_status], along with the "watch" command.
+
+{{{
+watch wrf4g_status -l -e sw_test
+}}}
+
+Probably 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.
+
+Once 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 [http://meteora.ucsd.edu/~pierce/ncview_home_page.html ncview] and [https://www.unidata.ucar.edu/software/netcdf/docs/ncdump-man-1.html ncdump] are very useful for this task.
+
+=== The experiment ===
+
+At 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.
+
+{{{
+cd ..
+mkdir sw_ncep
+cp -r ../sw_test/* .
+}}}
+
+Then 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:
+
+{{{
+start_date="2009-12-31_18:00:00"
+end_date="2010-01-31_06:00:00"
+}}}
+
+Finally, prepare and submit the experiment with WRF4G CLI, as before.
+
+{{{
+wrf4g_prepare
+wrf4g_submit -e sw_test
+}}}
+
+=== Experiment monitoring ===
+
+wrf4g_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:
+
+{{{
+wrf4g_status -l -e sw_test | grep Finished
+}}}
+
+Returns all the Finished realizations. Or, more complicated
+
+{{{
+wrf4g_status -l -e sw_test | grep -v Finished | grep -v Submitted | grep -v Failed
+}}}
+
+Returns all the realizations that are currently in some stage of the WRF4G workflow (Down. Bin., ungrib, metgrid..., etc.)
+
+If 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.
+
+Other 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.
+
+When 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.