Changeset 262 for trunk/MESOSCALE_DEV/MANUAL/SRC/faq.tex

Timestamp:

Aug 5, 2011, 4:48:44 AM (13 years ago)

Author:

aslmd

Message:

MESOSCALE: major commit at an absurd hour. new version for user manual finished.

File:

• trunk/MESOSCALE_DEV/MANUAL/SRC/faq.tex (modified) (8 diffs)

trunk/MESOSCALE_DEV/MANUAL/SRC/faq.tex

@@ -1 @@
-\chapter{Frequently Asked Questions, Tips and Troubleshooting}
+\chapter{Frequently Asked Questions, Tips and Troubleshooting}\label{faq}
 
 \vk
@@ -8 +8 @@
 \item your operating system and machine are in good health.
 \end{citemize}
+You might also read this chapter out of curiosity: it might be useful for your experience as an user.
+
+\mk
+\section{General questions}
+
+\sk
+\noindent \textbf{I don't know anything about mesoscale meteorology. Does that prevent me from becoming an user of your model?}
+\begin{finger}
+\item Not really. It is the purpose of this user manual to help you with running simulations with the LMD Martian Mesoscale Model. Now, you will probably not be able to interpret simulation results that easily, but we will then be happy to help you with our expertise on atmospheric science and to advise good books so that you learn more about this topic.
+\end{finger}
+
+\sk
+\noindent \textbf{I don't have time, or feeling overwhelmed by learning how to use the model.}
+\begin{finger}
+\item There are particular cases in which our team might be able to run the simulation for your study. Or help someone you would hire to do the work with learning about how to use the model and answer to questions. We are open to discussion.
+\end{finger}
 
 \mk
@@ -13 +29 @@
 
 \sk
-\noindent \textbf{The model compiled perfectly yesterday; then this morning, without changing anything, it does not compile.}
+\noindent \textbf{The model compiled yesterday. Now, with no apparent changes, it does not compile.}
 \begin{finger}
-\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:
+\item This is one of the most frustating situation. Remember though that there is $99\%$ chance that the reason for the problem is either stupid or none of your responsability. Please check that:
 \begin{citemize}
 \item Disk quota is not exceeded;
 \item You are working on the same machine as the day before;
-\item No source file has been accidentally modified;
+\item No source file has been accidentally modified; no links broken;
 \item No updates has been performed on your system during the night;
-\item No symbolic links has been broken in the meantime.
+\item Recompiling with \ttt{makemeso -f} does not solve the problem.
 \end{citemize}
 \end{finger}
@@ -38 +54 @@
 
 \sk
-\noindent \textbf{I am afraid I explored a given compilation directory in \ttt{\$MMM} (say \ttt{g95\_32\_single} and broke something, e.g. deleted some links or break some links. The model does not compile anymore.}
+\noindent \textbf{I am afraid I explored a given compilation directory in \ttt{\$MMM} (say \ttt{g95\_32\_single} and broke something, e.g. deleted or break some links. The model does not compile anymore.}
 \begin{finger}
-\item Delete the corresponding compilation directory. Since it is mostly filled with symbolic links, you will only lose previously the compiled executables and the (possibly modified) \ttt{Registry.EM}. Save those files prior to deletion of the compilation directory if you would like to keep those. Then run again \ttt{makemeso} for the same combination of compiler/system and a new clean version of the compilation directory will reappear, while the model executables are recompiled from scratch.
+\item Delete the corresponding compilation directory. Since it is mostly filled with symbolic links, you will only lose the previously compiled executables and the (possibly modified) \ttt{Registry.EM} file. Save those files prior to deletion of the compilation directory if you would like to keep those. Then run again \ttt{makemeso} for the same combination of compiler/system and a new clean version of the compilation directory will reappear, while the model executables are recompiled from scratch.
 \end{finger}
 
 \sk
-\noindent \textbf{I update the model's sources through \ttt{svn update} and the compilation failed with a new version}
+\noindent \textbf{I update the model's sources through \ttt{svn update} and the compilation failed with the new version}
 \begin{finger}
-\item It rarely happens that we move, create or delete some files in \ttt{\$MMM/SRC} while developing new capabilities or bug fixes for the model -- and commit the changes to the reference version of the model. Please apply the solution proposed in the previous point and the model would be able to compile. The need to do so can be anticipated by having a look to commit log through the command \ttt{svn log}.
+\item It could happen (but this is not usual) that we move, create or delete some files in \ttt{\$MMM/SRC} while developing new capabilities or bug fixes for the model -- and commit the changes to the reference version of the model. Please apply the solution proposed in the previous point and the model can be compiled again (because our rule is to commit only versions of the model which could be compiled). Possible problems can be anticipated by having a look to commit log through the command \ttt{svn log}. The vast majority of our commits, and subsequent reference model changes, is perfectly transparent for the user.
 \end{finger}
 
@@ -65 +81 @@
 
 \sk
+\noindent \textbf{I would like to have smoother surface properties.}
+\begin{finger}
+\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}).
+\end{finger}
+
+\sk
+\noindent \textbf{I would like to know more about customizing the calculations made by \ttt{geogrid.exe} and \ttt{metgrid.exe}.}
+\begin{finger}
+\item You probably want to know more about various settings in \ttt{WPS/geogrid/GEOGRID.TBL} and \ttt{WPS/geogrid/METGRID.TBL}. A detailed description can be found here \url{http://www.mmm.ucar.edu/wrf/users/docs/user_guide/users_guide_chap3.html} (some parameters are not relevant for Mars).
+\end{finger}
+
+\sk
 \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}).}
 \begin{finger}
 \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).
-\end{finger}
-
-\sk
-\noindent \textbf{I would like to have smoother surface properties.}
-\begin{finger}
-\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}).
 \end{finger}
 
@@ -83 +105 @@
 
 \sk
-\noindent \textbf{I would like to define my own vertical levels one by one.}
+\noindent \textbf{I would like to define my own vertical levels.}
 \begin{finger}
 \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}
@@ -97 +119 @@
 
 \sk
-\noindent \textbf{I don't know which timestep should I choose to prevent the model from crashing.}
+\noindent \textbf{I would like to know how much time my simulation will last.}
 \begin{finger}
-\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.
+\item Check the log information while \ttt{wrf.exe} is running. The effective time to realize each integrating or writing step is indicated. Hence you can extrapolate and predict the total simulation time. If you use parallel computations, have a look in \ttt{rsl.error.0000} to get this information.
+\end{finger}
+
+\sk
+\noindent \textbf{With default settings, I have one \ttt{wrfout*} file per simulated day, each one of those containing fields hour by hour. I want to change this.}
+\begin{finger}
+\item If you want to have an output frequency higher [lower] than one per hour, decrease [increase] the parameter \ttt{history\_interval} in \ttt{namelist.input} (remember that each unit of \ttt{history\_interval} is $100$~seconds). If you want to have more [less] data in each individual file, increase [decrease] the parameter \ttt{frames\_per\_outfile} in \ttt{namelist.input}.
+\end{finger}
+
+\sk
+\noindent \textbf{Looks like in the model (cf. \ttt{namelist.input}, a Martian hour is~$3700$ seconds. The reality is closer to~$3699$ seconds.}
+\begin{finger}
+\item This is true, though obviously the \ttt{3700} figure is much more convenient and choosing this instead of~$3699$ has no impact whatsoever on simulations which last typically less than one month, and most often only a few days. 
+\end{finger}
+
+\sk
+\noindent \textbf{I want to know the local time for a given model output.}
+\begin{finger}
+\item Time management in the model, which includes the way output files are named, relates to UTC time, i.e. local time at longitude~$0^{\circ}$. The time given in the name of each \ttt{wrfout*} file refers to the first frame written in the file -- using \ttt{history\_interval} allows you to infer universal time for all frames in the file. Another method is to look at the variable \ttt{Times} in \ttt{wrfout*}. Once you know about universal time, you can check the domain longitudes in \ttt{XLONG} to calculate local time at any location.
 \end{finger}
 
@@ -108 +148 @@
 \end{finger}
 
+\sk
+\noindent \textbf{I don't know which timestep should I choose to prevent the model from crashing.}
+\begin{finger}
+\item The answer depends on the horizontal resolution according to the CFL condition -- and whether the dynamical core is used in hydrostatic or non-hydrostatic mode, plus other factors (e.g. slopes, temperature gradients, etc\ldots). Please refer to the table in \textit{Spiga and Forget} [2009] for guidelines about timestep. A rule-of-thumb to start with is to set \ttt{time\_step} to the value of \ttt{dx} in kilometers; this value can be sometimes raised to get faster integrations. If the \ttt{time\_step} parameter is too large for the horizontal resolution~\ttt{dx} and violates the CFL criterion, \ttt{wrf.exe} usually issues warnings about CFL violation in the first integration steps. 
+\end{finger}
+
+\sk
+\noindent \textbf{Looks like \ttt{wrf.exe} is crashing because there are dynamical instabilities on the lateral boundaries apparently close to a topographical obstacle.}
+\begin{finger}
+\item Check that no steep slope (mountain, crater) is located at the domain boundaries. Otherwise, change the domain's center so that no major topographical gradient is located close to the domain boundaries (in the relaxation zone). This is also true for nested simulations at the boundary between parent and nested domains.
+\end{finger}
+
+
+%%% DIFFUSION FOR TRACERS
+%%% GRAVITY WAVE ABSORBING LAYER
+
+
 \clearemptydoublepage