aboutsummaryrefslogtreecommitdiff
path: root/doc/documentation.tex
blob: 725ebd923eac17276d049279db2d3c4ea31cdea4 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
% Thorn documentation template
\documentclass{article}
\begin{document}

\title{NaNChecker}
\author{Thomas Radke}
\date{26 May 2001}
\maketitle

\abstract{Thorn NaNChecker reports NaN values found in variables.}

\section{Purpose}

The NaNChecker thorn can be used to analyze Cactus grid variables (that is grid
functions, arrays or scalars) of real or complex data type for NaN
(Not-a-Number) and (on availability of {\tt finite(3)}) infinite
values. Grid variables can be periodically checked, or a call can 
be inserted into a thorn to check at a specific point.

This thorn is a utility thorn, designed to be used for debugging and
testing code for uninitialised variables, or for variables which 
become corrupted during a simulation, for example following a division
by zero or illegal memory usage.

On many architectures, uninitialised variables will be given the value
zero, and simulations using such variables will seeming run perfectly 
well. However, not only is it dubious programming practise to assume such
behaviour, but also moving to a new machine may well cause pathalogical 
problems (for example, with Alpha processors used in Compaq or Cray machines).
It is thus recommended to test codes periodically with the NaNChecker, 
and to fix any problems as soon as they are seen.

\section{Periodic Testing}

Periodic testing of variables can easily be achieved by adding NaNChecker
to the {\tt ActiveThorns} parameter, and setting the parameters 

\noindent
{\tt NaNChecker::check\_every} and {\tt NaNChecker::check\_vars} 

\noindent
to the required
values. (For most testing purposes these can be set to {\tt 1} and {"all"} 
respectively).

The NaNChecker then registers a routine at {\bf CCTK\_POSTSTEP} which checks
at every {\tt NanChecker::check\_every} iteration all the variables listed in
{\tt NaNChecker::check\_vars} for NaN or infinite values (depending on {\tt
NaNChecker::check\_for}) and -- if such a value is found -- performs an
action as specified in {\tt NaNChecker::action\_if\_found}.\\

Currently these actions can be to
\begin{itemize}
 \item{\tt just\_warn} (the default) 

   just print a level 1 warning message telling you where NaNs/Infs were found
   and how many (for grid array variables).\\
   For grid arrays it will also print level 2 warnings with the array index
   (in fortran order) for all NaN/Inf elements. You can limit the number of
   such warnings by setting the {\tt NanChecker::report\_max} parameter.

 \item{\tt terminate} 

also set the CCTK termination flag so that Cactus will stop the evolution
   loop and gracefully terminate at the next time possible (giving you the
   choice of outputting the data from the last evolution timestep),

 \item{\tt abort} 

print the warning message(s) and immediately terminate Cactus
   by a call to {\tt CCTK\_Abort()}
\end{itemize}

By default, the current timelevel of the variables given in
{\tt NaNChecker::check\_vars} will be checked. This can be overwritten by
an optional string {\tt [timelevel=<timelevel>]} appended to the
variable/group name. For example, to apply the NaNChecker to timelevel 0
of the variable grid::x, timelevel 1 of {\tt grid::y} and timelevel 2 of 
{\tt grid::z} you would use the parameter

\noindent
{\tt NaNChecker::check\_vars = "grid::x grid::y[timelevel=1] grid::z[timelevel=2"}

%
\section{NaNChecker API}
%
Thorn NaNChecker also provides a function API which can be used by other code
to invoke the NaNChecker routines to test for NaN/Inf values or to set NaN
values for a list of variables:

\vskip .2cm
\noindent{\bf C API}

\begin{verbatim}
  int NaNChecker_CheckVarsForNaN (const cGH *cctkGH,
                                  int report_max,
                                  const char *vars,
                                  const char *check_for,
                                  const char *action_if_found);

  int NaNChecker_SetVarsToNaN (const cGH *cctkGH,
                               const char *vars);
\end{verbatim}

\vskip.2cm
\noindent
{\bf Fortran API}

\begin{verbatim}
  call NaNChecker_CheckVarsForNaN (ierror, cctkGH, report_max,
                                   vars, check_for, action_if_found)

                                   integer ierror
                                   CCTK_POINTER cctkGH
                                   integer report_max
                                   character*(*) vars
                                   character*(*) check_for
                                   character*(*) action_if_found

  call NaNChecker_SetVarsToNaN (ierror, cctkGH, vars)

                                integer ierror
                                CCTK_POINTER cctkGH
                                character*(*) vars
\end{verbatim}

The {\tt report\_max, check\_vars, check\_for} and {\tt action\_if\_found}
arguments have the same semantics as their parameter counterparts.\\
If {\tt action\_if\_found} is given as a NULL pointer (C API) or as an empty
string (Fortran API) the routine will be quiet and just return the number of
NaN values found.\\

The C function {\tt NaNChecker\_CheckVarsForNaN()} returns the total number of
NaN/Inf values found, {\tt NaNChecker\_SetToNaN()} returns the total number of
variables set to NaN; this return value is stored in the {\tt ierror} argument
for the corresponding fortran wrapper routines.
%
% Automatically created from the ccl files 
% Do not worry for now.
\include{interface}
\include{param}
\include{schedule}

\end{document}