On 28 May 2012, at 21:13, Erik Schnetter wrote:
We should really brush up our autoconf. We should remove all the fancy stuff, and try to use cc/c++/f90 (or mpicc/mpic++/mpif90) for building, using -O and -g as optimisation/debug options.
The remaining complexity would be to autodetect how to build C99 code (instead of C90 code), and how to link against the Fortran run-time library. We should be able to automate this.
This way, the option lists may improve performance, but people would have a fighting chance to build out of the box. This probably wouldn't help on all the crazy systems, but would simplify things for people's laptops and workstations.
We probably would also need to detect various kinds of configuration problems, such as mis-installed compilers or MPI libraries.
Yes, this is something I've been thinking about in the last few days. I would like Cactus to be able to automatically configure itself on the most common platforms. The "magic" is all in the known_architectures file, correct? This seems to be a monolithic file which contains all the compiler detection, and is then duplicated for each architecture. Would it make sense to modularise this? We have pulled the library configuration out of Cactus itself into thorns. Would it be possible to provide thorns for compilers as well, rather than have this knowledge as part of the flesh? The build process might prohibit this, since configuration happens before the thorn scripts are run, and we need a compiler then. As an alternative, maybe the known_architectures scripts could be split up into smaller parts (e.g. sub-script for each compiler etc).
In a related note, it would be good if the simfactory optionlists could be simplified. They should really just be there to specify library locations that cannot be auto-detected, and compiler flags for exceptional cases. At the moment they are several screens long, and very intimidating.
-erik
On Mon, May 28, 2012 at 2:24 PM, Ian Hinder ian.hinder@aei.mpg.de wrote:
On 28 May 2012, at 18:34, Comer Duncan wrote:
Hi Frank,
Well, I have in mind developing/testing on my mac laptop (Lion) and doing real computation on the Ohio Supercomputer Center (OSC) clusters. I had tried to get WaveDemo working on my laptop and have trouble getting things to build. So I have now switched to the OSC frontend and am trying to get the same demo working there. So, my questions below are relative to building there.
On the OSC machine I have downloaded the development version. I also downloaded the WaveDemo.th. In the Cactus directory I have done the following:
make WaveDemo THORNLIST=./WaveDemo.th >& makewavedemo.out
with the makewavedemo.out file attached. The upshot is that it detects some fortran compile options it does not like and I think that probably is sufficient to make BLAS, LAPACK, and LORENE fail to compile.
I have a feeling that there is a need or needs to supply more info to make about where things are, e.g. mpi, which fortran (can use ifort and the rest of the intel compilers if better), and maybe other things.
Yes - for anything but a very simple setup, you need to specify an "option list" to Cactus. You tell Cactus to use a specific option list at configuration time:
make WaveDemo-config options=<optionlist>If you don't specify an option list, Cactus attempts to automatically detect the locations and flags for compilers, libraries etc.
There is more information about option lists (also called "configuration files") in the Cactus documentation (http://cactuscode.org/documentation/usersguide/UsersGuidech6.html#x9-18000B2).
We have a large collection of Cactus option lists for different machines in SimFactory (simfactory.org). You can take a look at them here:
https://svn.cct.lsu.edu/repos/numrel/simfactory2/trunk/mdb/optionlists/I don't think we have one for the Ohio Supercomputing Center, but you should be able to piece one together from the documentation and the examples above. It can be a bit tricky to get all the libraries and thorns working together, and a number of people on this list have a lot of experience with this, so please ask for help if you get stuck! If you get something working, it would also be great if you could send us the result, so we can put it in the repository for others to use in future.
Can you please advise?
Thanks,
Comer
On Sat, May 26, 2012 at 8:25 PM, Frank Loeffler knarf@cct.lsu.edu wrote:
On Fri, May 25, 2012 at 01:10:41PM -0400, Comer Duncan wrote:
I am trying to get WaveDemo built on my local laptop. I have done the following:
make WaveDemo--config make WaveDemo
while in the Cactus directory with the result that seemingly _all_ resident thorns have been compiled/configed. As I doubt that all are needed for the WaveDemo example, I find this a bit strange. Can someone please explain?
If this is all you specified (meaning you didn't specify a thornlist), Cactus creates a thornlist from everything there is. Usually you either use simfactory (sim build --thornlist=<FILE>) or make WaveDemo THORNLIST=<FILE>
Secondly, at the end of the make WaveDemo it crashes complaining that LSUThorns/Vectors is needed but not present. This is associated with several thorns including CarpetLib, ML_BSSN, ML_BSSN_02, and WeylScal4. I have added the line LSUThorns/Vectors to the Thornlist file and have rerun the make WaveDemo but still I get no find of LSUThorns/Vectors. Can someone please let me know the correct procedure here?
Which thornlist did you add this to? If this was not the one inside the 'configs' directory, Cactus ignored this and continues the (now) existing thornlist there (because again you didn't specify the changed thornlist on the command line).
Does this help?
Frank
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux)
iQIcBAEBCAAGBQJPwXSAAAoJEOkzpip+I59kKZ4P/jipgymiVyuTMHU0WI89mj1X gSUa544AjcYuL12YDFbtzypwIl8vtTkSHSONN6iBadGFbOMhTGx+c0ipbLh1fAzL /g9JM67FZru30RCzYb7ni1eHR+5v+SElAB982XTiOvIuyHY3k3oJr5hLBT+MhPyt BtHRQTirTl/51D6H+JBTEkrTiHEkKm4xx7xtFXrNcEtscjFOEx1n9ybPfk3IqFiW floy8c617ONghLkVJ+v+We36VgDOwhNFWRm9tJTrWZOu13OrLLKC5YSCaTyUsuw5 ItFp3TJ6Wo9B1a/R58TYNXc6kA+2YXH2YkKMUVF6Tur8LLtfbVRVzAS9R5Kag3Er ci4PcW524lVZFZoijdiww9P3UyKdkqT5TnSG/+JKbRhyI5o9n5x08Gdt4e09+0HX 6oDtFug7Dap3NpYLqHywvCLDx3tydQBqjJtet17sdXq2EZ2BwEUVvSAV/4jV5r7k 5gFgGjieN5TiyOzZ6HAxerpZP8K3T/DuKCMGegbin/OJNCXvHIaRaql/3XWICZ0g ulPAGFcq29ToXwL45o8X/2SEXYqTzHyQZgX1Axtf7GHamKxuMA+mA7Wh6HUp2GGq h7WzHOl/rCkBUQfXN9ZrI2qqs4YQgP1m0ocuq7ePf7xTzGLUj+EizD2IbiMcYHVw guYyxihF2ItSKiawt4Vc =ltSb -----END PGP SIGNATURE-----
<makewavedemo.out>_______________________________________________ Users mailing list Users@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users
-- Ian Hinder http://numrel.aei.mpg.de/people/hinder
Users mailing list Users@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users
-- Erik Schnetter schnetter@cct.lsu.edu http://www.perimeterinstitute.ca/personal/eschnetter/