1 | \chapter{Frequently Asked Questions, Tips and Troubleshooting} |
---|
2 | |
---|
3 | \vk |
---|
4 | Browse this chapter if you encounter problems or issues while using the LMD Martian Mesoscale Model. Before reading what follows, please ensure that: |
---|
5 | \begin{citemize} |
---|
6 | \item you made no errors in using the model; |
---|
7 | \item your problem is not addressed in the previous chapters; |
---|
8 | \item your operating system and machine are in good health. |
---|
9 | \end{citemize} |
---|
10 | |
---|
11 | \mk |
---|
12 | \section{Compilation} |
---|
13 | |
---|
14 | \sk |
---|
15 | \noindent \textbf{The model compiled perfectly yesterday; then this morning, without changing anything, it does not compile.} |
---|
16 | \begin{finger} |
---|
17 | \item This is one of the most frustating situation. Remember though that there is $99\%$ chance that the reason for this problem is either stupid or none of your responsabilities. Please check that: |
---|
18 | \begin{citemize} |
---|
19 | \item Disk quota is not exceeded; |
---|
20 | \item You are working on the same machine as the day before; |
---|
21 | \item No source file has been accidentally modified; |
---|
22 | \item No updates has been performed on your system during the night; |
---|
23 | \item No symbolic links has been broken in the meantime. |
---|
24 | \end{citemize} |
---|
25 | \end{finger} |
---|
26 | |
---|
27 | \sk |
---|
28 | \noindent \textbf{The model is no longer compiling, after I abruptly stopped the \ttt{makemeso} script because I realized that I made a mistake (e.g. I was compiling on the wrong machine).} |
---|
29 | \begin{finger} |
---|
30 | \item Recompile the model from scratch by using the option \ttt{-f} to \ttt{makemeso}. |
---|
31 | \end{finger} |
---|
32 | |
---|
33 | \sk |
---|
34 | \noindent \textbf{I am asking for compiling the model on a huge grid (e.g. over $200 \times 200 \times 100$ for a single-processor run). The compilation fails with ``relocated fits" errors.} |
---|
35 | \begin{finger} |
---|
36 | \item Try to lower the number of grid points (either horizontal or vertical) or consider using parallel computations where computations over the model grid will be split over several processors. |
---|
37 | \end{finger} |
---|
38 | |
---|
39 | \sk |
---|
40 | \noindent \textbf{I would like to learn more about the interface between the WRF dynamical core and the LMD Martian physical parameterizations.} |
---|
41 | \begin{finger} |
---|
42 | \item The program source that is responsible for the interface between the dynamical core and the physical parameterizations is \ttt{module\_lmd\_driver.F} in \ttt{\$MMM/SRC/WRFV2/phys/}. |
---|
43 | \end{finger} |
---|
44 | |
---|
45 | \sk |
---|
46 | \noindent \textbf{I think I found a bug in the model.} |
---|
47 | \begin{finger} |
---|
48 | \item This is not impossible! Please double check then contact us. |
---|
49 | \end{finger} |
---|
50 | |
---|
51 | \mk |
---|
52 | \section{Preprocessing steps} |
---|
53 | |
---|
54 | \sk |
---|
55 | \noindent \textbf{To speed up initializations, I would like to define GCM constraints at the domain boundaries each 6 Martian hours, instead of each one or two hours as it is usually done (cf. \ttt{interval\_seconds = 3700}).} |
---|
56 | \begin{finger} |
---|
57 | \item It is not a good idea. Near-surface atmospheric fields undergo a strong daily cycle on Mars which you will not be able to capture if \ttt{interval\_seconds} is higher than 7400 seconds (i.e. two Martian hours). |
---|
58 | \end{finger} |
---|
59 | |
---|
60 | \sk |
---|
61 | \noindent \textbf{I would like to have smoother surface properties.} |
---|
62 | \begin{finger} |
---|
63 | \item Increase the smoothing parameter \ttt{smooth\_passes} in the file \ttt{WPS/geogrid/GEOGRID.TBL} for each field you would like to get smoother, then restart at step 2 (execution of \ttt{geogrid.exe}). |
---|
64 | \end{finger} |
---|
65 | |
---|
66 | \sk |
---|
67 | \noindent \textbf{\ttt{real.exe} is sometimes crashing with certain (low) values of \ttt{p\_top\_requested}.} |
---|
68 | \begin{finger} |
---|
69 | \item The program \ttt{real.exe} attempts to come up with nice equally-spaced-in-altitude vertical levels above the boundary layer up to the model top. This is done by an iterating algorithm integrating the hydrostatic equation which sometimes does not converge if the model top is too high (typically for values of \ttt{p\_top\_requested} below~$5$~Pa). Try to lower \ttt{force\_sfc\_in\_vinterp}, increase \ttt{max\_dz}, or modify \ttt{tiso} to help the algorithm to converge. |
---|
70 | \end{finger} |
---|
71 | |
---|
72 | \sk |
---|
73 | \noindent \textbf{I would like to define my own vertical levels one by one.} |
---|
74 | \begin{finger} |
---|
75 | \item Create a file \ttt{levels} with all your mass-based model levels (see chapter~\ref{whatis}) in it then add the optional setting in \ttt{\&domains} in \ttt{namelist.input} |
---|
76 | \begin{verbatim} |
---|
77 | eta_levels = 1.000000, |
---|
78 | 0.000000 |
---|
79 | \end{verbatim} |
---|
80 | You might also want to use \ttt{eta\_levels} to prescribe directly in \ttt{namelist.input} the list of your custom model levels. Please ensure that the lowermost model level is $1$, the uppermost is $0$ and vertical resolution is refined in the boundary layer ($\sim 8$ vertical levels above surface). |
---|
81 | \end{finger} |
---|
82 | |
---|
83 | \sk |
---|
84 | \section{Runtime} |
---|
85 | |
---|
86 | \sk |
---|
87 | \noindent \textbf{I don't know which timestep should I choose to prevent the model from crashing.} |
---|
88 | \begin{finger} |
---|
89 | \item It depends on the horizontal resolution according to the CFL condition -- and whether the dynamical core is used in hydrostatic or non-hydrostatic mode. Please refer to the table in \textit{Spiga and Forget} [2009] for guidelines about timestep. |
---|
90 | \end{finger} |
---|
91 | |
---|
92 | \sk |
---|
93 | \noindent \textbf{The executable \ttt{wrf.exe} crashes a few seconds after launching and I don't know why.} |
---|
94 | \begin{finger} |
---|
95 | \item Please check all outputs from \ttt{wrf.exe}: information log and \ttt{wrfout*} files. It is usually possible to find hints about the problem(s) which make the model become unstable or crash. Sometimes it is just one file that is missing. If \ttt{cfl} warnings are reported in information log, it is probably a good idea to lower the timestep, but this will not fix the problem all the time especially if there are wrong settings and subsequent physical inconsistencies. If everything looks fine in the information log, try to lower \ttt{history\_interval} to $1$ in \ttt{namelist.input} so that much frequent outputs can be obtained in the \ttt{wrfout*} files and the problem can be further diagnosed through analyzing simulated meteorological fields. |
---|
96 | \end{finger} |
---|