summaryrefslogtreecommitdiff
path: root/doc/FAQ
blob: 1829c33308b6c0ac2634e670b7d151822abdbd25 (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
Cactus Code Frequently Asked Questions

$Header: /mnt/data2/cvs2svn/cvs-repositories/Cactus/doc/FAQ,v 1.6 2000-02-28 12:24:42 allen Exp $

The latest version of this FAQ is always available from the main Cactus Code web
site 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) Parallel make sometimes fails.

   It seems that the make program sometimes gets confused in parallel makes.
   Just doing gmake <config> again will let it continue.  You should be able
   to continue with another parallel make afterwards.

-------------------------------------------------------------------------------------

6) When doing a cvs update I get 'not enough slashes in ...' .

   It seems that CVS sometimes gets confused with multiple modules.  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.

-------------------------------------------------------------------------------------

7) 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 

-------------------------------------------------------------------------------------

8) 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.
   
-------------------------------------------------------------------------------------