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 -config MPI= 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 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_ | grep Header to see all the version information for all source files, and strings cactus_ | grep Header | grep to look for a particular file. (Note that this only works for files using the CCTK_FILEVERSION macro) -------------------------------------------------------------------------------