1 | 1. Created a new "core specific" directory |
---|
2 | |
---|
3 | mkdir dyn_exp |
---|
4 | |
---|
5 | 2. Create a test directory for experimental core |
---|
6 | |
---|
7 | mkdir test/exp_real |
---|
8 | |
---|
9 | 3. Edited top level Makefile to add targets for same |
---|
10 | |
---|
11 | 3.a. rules to build the framework and then the experimental core |
---|
12 | |
---|
13 | exp_wrf : |
---|
14 | $(MAKE) MODULE_DIRS="$(SLT_MODULES)" ext |
---|
15 | $(MAKE) MODULE_DIRS="$(SLT_MODULES)" toolsdir |
---|
16 | $(MAKE) MODULE_DIRS="$(SLT_MODULES)" framework |
---|
17 | $(MAKE) MODULE_DIRS="$(SLT_MODULES)" shared |
---|
18 | $(MAKE) MODULE_DIRS="$(SLT_MODULES)" exp_core |
---|
19 | |
---|
20 | 3.b. sub-rule to build the expimental core |
---|
21 | |
---|
22 | exp_core : |
---|
23 | @ echo '--------------------------------------' |
---|
24 | ( cd dyn_exp ; $(MAKE) ) |
---|
25 | |
---|
26 | 3.c. experimental core initialization |
---|
27 | |
---|
28 | exp_real : exp_wrf |
---|
29 | @ echo '--------------------------------------' |
---|
30 | ( cd main ; $(MAKE) MODULE_DIRS="$(EXP_MODULES)" SOLVER=exp IDEAL_CASE=exp exp_ideal ) |
---|
31 | ( cd test/exp ; /bin/rm -f ideal.exe ; ln -sf ../../main/ideal.exe . ) |
---|
32 | ( cd test/exp ; ln -sf ../../run/README.namelist . ) |
---|
33 | |
---|
34 | |
---|
35 | 3.d. add macros to specify the modules for this core |
---|
36 | |
---|
37 | EXP_MODULE_DIR = -I../dyn_exp |
---|
38 | EXP_MODULES = $(EXP_MODULE_DIR) $(INCLUDE_MODULES) |
---|
39 | |
---|
40 | |
---|
41 | |
---|
42 | 4. Edit share/solve_interface.F to add call to experimental core |
---|
43 | |
---|
44 | ELSE IF ( config_flags%dyn_opt == DYN_EXP ) THEN |
---|
45 | |
---|
46 | CALL solve_exp ( grid , & |
---|
47 | ! |
---|
48 | #include <exp_actual_args.inc> |
---|
49 | ! |
---|
50 | ) |
---|
51 | |
---|
52 | 4a. share/start_domain.F |
---|
53 | |
---|
54 | 5. Create dyn_exp/solve_exp.F |
---|
55 | |
---|
56 | It's all there and very short -- just a trivial relaxation; some of the |
---|
57 | stuff in there is just "magic," for right now. Note that the code in |
---|
58 | here is the code to do one step. The time loop is part of the driver |
---|
59 | and can be found in frame/module_integrate.F, which call |
---|
60 | solve_interface, which calls this routine. Note, too, that solve_exp |
---|
61 | doesn't do any computation itself. It is mediation layer. It calls |
---|
62 | model layer subroutines (dyn_exp/module_exp.F) to do the actual computation |
---|
63 | in 'tile-callable' fashion. |
---|
64 | |
---|
65 | 6. Create dyn_exp/module_exp.F |
---|
66 | |
---|
67 | This is the model layer code. Note that boundary tests are always |
---|
68 | encoded explicitly as conditionals using the domain indices passed |
---|
69 | in through the arg list; never implicitly as part of the loop range. |
---|
70 | |
---|
71 | 7. Edit the Registry file and create the state data assocaited with this |
---|
72 | solver. Single entry: |
---|
73 | |
---|
74 | state real x ikj dyn_exp 2 - ih "TOYVAR" |
---|
75 | |
---|
76 | This specfies a two timelevel variable 'x' that will be known at the |
---|
77 | mediation layer and below as x_1 and x_2 (since it is core associated it |
---|
78 | will be known as exp_x_1 and exp_x_2 in the driver layer; the name |
---|
79 | of the core is prepended to prevent colllisions with variables of the |
---|
80 | same name that are associated with other cores). The 'ih' means it will |
---|
81 | participate in initial data and in history data. The veriable is known |
---|
82 | externally as TOYVAR, its data name and the name the variable will have |
---|
83 | in data sets. |
---|
84 | |
---|
85 | Note that since the variable is not listed as staggered in any dimension |
---|
86 | it's logical (domain) size is ids:ide-1, kds:kde-1, jds:jde-1. This |
---|
87 | is important in the the module_exp.F code that tests for northern |
---|
88 | and eastern boundaries, and in the init code in module_initialize_exp.F |
---|
89 | |
---|
90 | 8. Edit the Registry file and create a halo-exchange for x_1. |
---|
91 | |
---|
92 | halo HALO_EXP_A 4:x_1 |
---|
93 | |
---|
94 | Note that since halo operations are called from the mediation layer, it |
---|
95 | is not necessary to pre-pend the dyncore name to the variable name x_1 |
---|
96 | when adding it to a comm operation like a halo exchange. |
---|
97 | |
---|
98 | 9. Edit the Registry file to set up '4' as the value of the |
---|
99 | namelist variable dyn_opt that means to select our exp dyncore. |
---|
100 | |
---|
101 | package dyn_exp dyn_opt==4 - - |
---|
102 | |
---|
103 | 10. Create a dyn_exp/Makefile (see that file) |
---|
104 | |
---|
105 | 11. Create an file exp/init_modules.F (also includes a couple of stubs |
---|
106 | for other dyncores already in WRF; this is not the normal or correct |
---|
107 | way of doing that; but I'm hurrying...) |
---|
108 | |
---|
109 | 12. Create a file exp/module_initialize_exp.F. This is not part of the |
---|
110 | WRF model itself; rather it is a pre-processor that produces initial |
---|
111 | data for the WRF model. |
---|
112 | |
---|
113 | 13. Edit frame/module_domain.F to add case for DYN_EXP to |
---|
114 | alloc_space_field. (This is a bug; |
---|
115 | one should never have to edit the framework code; will fix this in |
---|
116 | coming versions). Same goes for share/start_domain.F, although this |
---|
117 | is not a framework routine. |
---|
118 | |
---|
119 | 14. clean commands |
---|
120 | |
---|
121 | 15. namelist file |
---|
122 | copy from another dir and change dyn_opt |
---|
123 | boundary conditions |
---|