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
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
|
Cactus Code Frequently Asked Questions
$Header: /mnt/data2/cvs2svn/cvs-repositories/Cactus/doc/FAQ,v 1.17 2001-05-05 23:35:06 allen Exp $
Also available at http://www.cactuscode.org/Documentation/FAQ
-------------------------------------------------------------------------------
1) The make system says "Checking status of libXXX.a" and then just
sits there. What can I do ?
The first thing to do whenever a problem arises from the make system
is to run with the "SILENT=no" option.
In this case, 'though, first check that the clocks on the machine on
which you are editing files and the clock on the machine you are compiling
on are synchronised. If the compilation machine's clock is slow, then the
newly made dependency files will still be `older' than the file you edited,
and the system will loop until this situation changes.
-------------------------------------------------------------------------------
2) Compilation of Cactus fails with the error:
identifier "DECLARE_CCTK_PARAMETERS" is undefined?
You have to include the header:
#include "cctk_Parameters.h"
-------------------------------------------------------------------------------
3) I get 'g77: cannot specify -o with -c or -S and multiple compilations' when
compiling with the Pacific VAST90 compiler.
If the libvast90.a library is in the same directory as your F90 script,
F90 passes -lvast90 to the underlying G77 compile, which is of course only
a valid switch when linking. The solution is to seperate these files,
e.g. into bin and lib directories.
-------------------------------------------------------------------------------
4) Why do I have to use e.g. "mpirun -np 1 ./exe/cactus_myconfig -O" to see
the compiled parameters, can't the parameters be output before MPI is
initialised?
Alas some MPIs add their own command-line options, so we need to do
MPI_Init before parsing the command line, or parse it twice, once before
the MPI_Init and once after, to detect invalid options.
-------------------------------------------------------------------------------
5) When doing a cvs update I get 'not enough slashes in ...' .
It seems that CVS sometimes gets confused with multiple repositories.
Check that you are using the latest version of CVS, otherwise moving into
the arrangements directory and performing another 'cvs update', followed
by a final one in the toplevel directory should complete your update.
There is now a Cactus make target "gmake cvsupdate" which avoids this
problem by updating the flesh and checked out thorns explicitly.
-------------------------------------------------------------------------------
6) How do I compile with MPI? Why isn't it automatic like in Cactus 3?
The standard MPI driver (PUGH) is in a thorn now (CactusPUGH/PUGH), so
there is now the possibility to add other parallel drivers using
alternative message passing schemes as separate thorns. To compile with
MPI, when you make a configuration, use
gmake <configuration>-config MPI=<MPI_TYPE>
where the allowed values of MPI_TYPE are discussed in the documentation.
For machines where Cactus 3 used to use MPI by default, the correct option
is probably MPI=NATIVE
-------------------------------------------------------------------------------
7) I can't compile because the compiler complains that a routine name has been
previously defined ... but I can't find it repeated?
If it is a C routine, whose name is either all in capitals or all in
lowercase, and the routine has a Fortran wrapper, then it could be that
the compiler doesn't attach underscores to the Fortran name and there is a
conflict. To remove this possibility always use mixed case names for C
routines with Fortran wrappers.
-------------------------------------------------------------------------------
8) How can I make sure that one thorn is compiled before another? For example
to make sure that F90 module files from ArrangementA/ThornA are available
for ArrangementB/ThornB.
Add a dependency to a ThornB's make.configuration.deps file, for example
ifneq (,$(findstring ArrangementA/ThornA,$(THORNS)))
$(CCTK_LIBDIR)$(DIRSEP)libThornB.a : $(CCTK_LIBDIR)$(DIRSEP)libThornA.a
endif
we will try to modify the make system to make this more automatic in the
future.
-------------------------------------------------------------------------------
9) On my SUN I start a configuration process with gmake, but on the second
gmake it wants to set up the configuration again and again ....
Why is this ?
You are using a version of gmake which is too outdated (even though
this version may pefectly work on other architectures). We found
that GNU Make version 3.79 works fine.
-------------------------------------------------------------------------------
10) How do I compile Cactus in 32 bit mode on a 64 bit irix machine?
gmake <config>-config IRIX_BITS=32
-------------------------------------------------------------------------------
11) What can I do if I don't have enough disk space to compile Cactus?
If you have access to some scratch space, or temporary space, you can
instruct Cactus to put the "configs" directory there (with all the
object files and intermediate files).
For example, to use the directory /scratch/myconfigs with csh or tcsh,
setenv CACTUS_CONFIGS_DIR /scratch/myconfigs
or with bash
CACTUS_CONFIGS_DIR=/scratch/myconfigs
export CACTUS_CONFIGS_DIR
-------------------------------------------------------------------------------
12) Why isn't a BOOLEAN parameter a LOGICAL in Fortran?
There is no way we can guarantee the way the Fortran logical type is
represented at machine level, and since all Fortran variables need
to be mapped internally to C data structures, we use integers to ensure
portability.
-------------------------------------------------------------------------------
13) I'm trying to run Cactus with MPI using "mpirun", but I just get an error
"Unknown option -np", what's the problem?
It looks like the MPI implementation on the machine you're using isn't
removing it's arguements correctly, so they are being passed to the
Cactus run. You need to use the "-i" command line option for Cactus to
ignore the MPI arguements, e.g.
mpirun ./cactus_foo foobar.par -i -np 8
-------------------------------------------------------------------------------
14) Why is there an MPI call in the Flesh (MPI_Init)? I thought that the
Cactus flesh was independent of any parallel protocol, why isn't this
call made from a driver thorn?
We would love to get rid of the last remaining MPI calls from the flesh,
unfortunately in MPI 1, MPI implementations are allowed to play around
with the argument list, so we need to call MPI_Init before parsing the
command line argument, and this makes it very difficult to have it
called from the driver, since we don't even know what the parameter
file is at that stage, so we don't even know which driver to activate!
MPI 2 allows NULL to be passed to MPI_Init, which gets around the
problem, but the only machines currently with MPI 2 are Japanese
supercomputers.
It is the only MPI call made before the driver is activated, and it
sets a global variable to tell you it's been done, so it isn't a
major problem apart from being extremely ugly. You can even turn
it off with an environment variable, but then if you run with MPICH
you'll find the code complaining about unknown command line arguments
like -p4grp. If we had a precise list of the arguments passed by each
MPI implementation we could guard against them, but that's an even
uglier option.
-------------------------------------------------------------------------------
15. While implementing some MPI code in Cactus, I came across the problem of
getting an MPI communicator. I basically have the choice between using
MPI_COMM_WORLD, assuming that no processors have been set aside by the
driver, or tying myself to a certain driver, such as PUGH, and using the
driver's internal data structures. Both choices are clearly not
desirable.
We are aware of this, and in fact, it is the reason why some of the
I/O thorns are directly dependent on the PUGH driver.
The solution for all this will be the Cactus Communication
Infrastructure (CCI: http://www.cactuscode.org/Development/Specs/CCI.txt)
which will eventually be integrated into the flesh and will provide a
generic function interface for communicating data.
Thus when you plug in different communication drivers, I/O thorns
won't need to be changed if they use the CCI routines.
-------------------------------------------------------------------------------
16. When I compile Cactus I get an error like
/home/allen/Cactus/arrangements/MineStuff/Test/src/metric.F90:3:
unterminated character constant
make[2]: *** [metric.F90.d] Error 33
But then when I type gmake again the compilation proceeds without problem?
You are probably using Linux, and the C preprocessor is complaining
about single apostrophes in a Fortran comment line when it is creating the
dependency file for metric.F90. Make continues the second time because
the dependency file now exists (although it won't necessarily contain
the right information).
We could remove this problem by removing comments from Fortran files
before using the C preprocessor, but we don't want to add this overhead
at the moment, since we are writing a Cactus preprocessor which won't
have this problem (and will solve a number of other preprocessing
problems). You should try and remove any single apostrophes in
Fortran comments for now, or use gmake twice.
-------------------------------------------------------------------------------
17. Is there anyway to tell what CVS version of individual source files
was used to build an executable.
Actually there is, just issue the Unix command:
strings cactus_<config> | grep Header
to see all the version information for all source files, and
strings cactus_<config> | grep Header | grep <filename>
to look for a particular file.
(Note that this only works for files using the CCTK_FILEVERSION macro)
-------------------------------------------------------------------------------
|
