===================== How to use restart: ===================== 1) Keep same end time (nhours_fcst: in config file) like in original run. 2) Change restart: argument in config file from false to true That's the only change in config file 3) The only difference from original run script is you don't use main_input_filename. Instead, you use restart_file which you get from original output (i.e. nmm_b_restart.006) Limitations: 1) In order to keep bit-identical results, restart must be written (used) on full hour 2) Restart cannot be more frequent than history output and must be multiplier of history output i.e. if history is written on 3 hours, model can be restarted on 3, 6, 9, ... hours (need to be fixed later) TODO: 1) Allow writing restart file at any time in forecast ====================================== How to use time series output in NMMB: ====================================== Time series output in NMMB is optional output that is turned on by providing appropriate namelist file in run directory. The name of that file must be ts_locations.nml, and the contents of the file is as follows: &TS_LOCATIONS NPOINTS=2, POINTS_LON=-106.0, -110.0, POINTS_LAT=54.0, 50.0 / where NPOINTS defines number of locations and POINTS_LON,POINTS_LAT are arrays of longitudes and latitudes of selected points in degrees (-180.0 to 180.0). The output filenames are ts_p01_d01.bin,ts_p02_d01.bin, ts_p01_d02.bin,ts_p02_d02.bin etc. The p01 indicates the point number from 1 to NPOINTS and d01,d02 indicate domain number The ncarg program tsplot that can be used to plot time series is located in /u/wx20du/plot_timeseries. It requires a control file as a command line argument. For example if the control file is named tsplotsetup_nmm you will need to run: $ ./tsplot tsplotsetup_nmm which will create gmeta file. Sample control file (tsplotsetup_nmm) is also located in /u/wx20du/plot_timeseries directory. ======= Nesting ======= Currently the NMM-B has 1-way nesting for static and for moving nests. All domains, whether the uppermost parent or any nest, are functionally equivalent and thus each needs its own configure file. (1) First go into the uppermost parent's configure file. (a) The variable 'num_domains_total' must be set in this domain's configure file. This is the total number of domains in the run which includes the upper parent plus all nests. This variable does not need to be set in any other configure files (if it is set in others it is not read). (b) Set the value for 'my_domain_id' which must always be 1 for the uppermost parent. (c) Set the value for 'my_parent_id' to -999. (d) Set 'n_children' to the number of child nests associated with the uppermost parent. This does not include any nests inside the first generation of child nests because all interactions with nesting involve only a parent and its first generation of children. (e) Set 'my_domain_moves' to false. (2) Static nest configure files. (a) In each nest's configure file set 'my_domain_id' to a unique integer greater than 1. The user is free to choose these integer identifiers in any way desired except that all domain IDs must ultimately form a monotonic sequence. In other words if the run contains 2 first generation nests and one of those nests contains a nest then the three nests may use any integer value between 2 and 4 as their domain ID so that the final IDs are 1,2,3, and 4 but never something like 1,2,4,5. (b) Set the value for 'my_parent_id' to the integer ID that was given to this nest's parent domain. (c) Set 'n_children' to the number of child nests inside of this nest but not counting any deeper nests inside of those children. (d) Set 'i_parent_start' and 'j_parent_start' to the I and J indices on the nest's parent grid H point that coincide with the nest's SW corner H point. This implies that any nest's SW corner must lie directly on a parent grid H point. (e) Set 'parent_child_space_ratio' to the ratio of the parent's grid increment to the child's. Make this an integer. Although the code was originally written to allow this ratio to be any real number, tests with real values have not been done yet. (f) Set 'input_ready' to true if input data has already been produced for this nest. Set it to false if input data has not been produced and the user wants the parent to generate the nest's input data. NPS-generated input data is naturally preferable. (g) Set 'my_domain_moves' to false. (3) Moving nest configure files. See the example in job/configfile_moving_nmm . (a) Follow all instructions in 2(a)-(f). (b) Set 'my_domain_moves' to true. (c) Set 'ratio_sfc_files' to the ratio of the uppermost parent's grid increment to this moving nest's. Again this should be an integer. The use of moving nests requires the user to generate eight different surface-related static datafiles for each different resolution of nest in the run. If there are two moving nests with parent_child_space_ratio=3 then a set of the following eight files must be pre-generated: ALBASE_ij_3, FIS_ij_3, ISLTYP_ij_3, IVGTYP_ij_3, MXSNAL_ij_3, SM_ij_3, TG_ij_3, and VEGFRC_ij_3. These are the base albedo, sfc geopotential, soil type, vegetation type, maximum snow albedo, sea mask, deep underground temperature, and vegetation fraction, respectively, at the 3x nests' resolution but which span the entire upper parent domain. This data must be present as the nests move across the parent's domain. Then assume one of the 3x moving nests contains a 3x moving nest inside it. In the configure file for the inner nest the value of ratio_sfc_files would be 9 and the eight sfc datafiles would contain 9x data that spans the entire upper parent's domain. Note that the final integer in these files' names must be the value of ratio_sfc_files. (d) Set the values of 'nrows_p_upd_w', 'nrows_p_upd_e', 'nrows_p_upd_s', and 'nrows_p_upd_n' to 2. This is the number of rows around the edge of the nest domain that must be updated by the parent after the nest moves. The nest does not use its own data in these rows for updating itself because V is not present on the north/east sides and some variables needed in the integration part of the domain are not computed in these rows. (e) For now any child of a moving nest must be a moving nest and not a static nest. A static child would be tied to the parent and so when the parent moves then its child would move with it. A moving child is not tied to its parent and so when the parent moves then its child does not move with it and the child continues to determine its own motion independently. (4) The run script will copy each configure file to configure_file_01, configure_file_02, etc. where the final integers on the filenames form a monotonic sequence. The uupermost parent's configure file must be used for configure_file_01 but the user is not required to make the remaining files' names contain the same integer as their corresponding configure files' domain IDs. ======================== How to add new variable: ======================== 1) Go to ~/src/atmos/nmm directory 2) In file module_DYNAMICS_INTERNAL_STATE.F90 or module_PHYSICS_INTERNAL_STATE.F90 (whether you need it in dynamics or physics), search for similar variable; in this case let's use 2D variable ALBEDO as an example. a) First command is declaration of the pointer, add your variable to that command b) Search further and next call is allocating size of your new variable: CALL SET_VAR_PTR(int_state%VARS,NV,AF,'ALBEDO',int_state%ALBEDO,(/IMS,JMS/),(/IME,JME/)) In most cases you'll need just to copy this line and change ALBEDO to the name of your variable. 3) Now, your variable is placed in internal state, allocated and given initial value to NaN!!! If you want to initialize with different number, in same directory open file module_PHYSICS_GRID_COMP.F90, go to subroutine PHYSICS_INITIALIZE, search for string "Initialize allocated arrays" and add your variable to appropriate place and initialize with desired value. *) Same procedure should be done with 3D and 4D arrays. =================================================== Adding variable to the history and/or restart file: =================================================== 1) If this is a new (non-existing) variable in internal state, go through steps 1-3 in previous paragraph. 2) When you have existing variable in internal state, go to ~/job/regression_tests directory, and choose one of two files: dyn_state.txt or phy_state.txt, whether your variable is in dynamics or physics internal state. 3) Again let's use ALBEDO as an example, open file phy_state.txt and search for ALBEDO. - copy and paste line: 'ALBEDO' H R O - - T 'Dynamic albedo' - rename ALBEDO to the name of your variable, and give short description in the 8th column. 4) There are 8 columns in the file: Name History Restart Owned Import eXport Time_series Description If you want your variable in History file, leave letter H in second column, if not, just leave dash. If you want your variable in Restart file, leave letter R in third column, if not, just leave dash. If you want your variable as a part of Time series, leave letter T in seventh column, if not, just leave dash. **) Columns 4, 5 and 6 are part of "ownership suite" and are intended to be used for exchange between dynamics and physics without necessary (duplicate) allocations. O is for owned X is for export I is for import If you add new variable to the physics component, you should have O in ~/job/regression_tests/phy_state.txt (just like ALBEDO in step 3 this paragraph). If you want to use that variable in dynamics component, you should use X (for export) in phy_state.txt and I (for import) in dyn_state.txt