On 13 Apr 2017, at 17:14, David Gore <[email protected]> wrote: > Hi, Ian. > > Given the amount of times I've found answers to problems because someone > posts their fix, I thought it would be criminal not to do the same.
Indeed. > I have a few questions regarding the difference between configurations: > (1) You're using simfactory/mdb/optionlists and I'm using > configs/sim/config-data/make.config.defn Is there a reason to choose one > over the other? When you build Cactus, it does an "out of tree build" in configs/<config-name>, where the config name defaults to "sim" if you are building with simfactory. You can build multiple configurations with different build settings by giving a name for the configuration in the sim build command (sim build <configname>). SimFactory comes with a set of optionlists in simfactory/mdb/optionlists, mostly for different known clusters on which Cactus is commonly used, but also for different common operating systems. When you build with "sim build", if you are on a known machine, simfactory automatically selects an optionlist appropriate for that machine. Otherwise, you can specify an optionlist with --optionlist <name>, where the name should be an optionlist in simfactory/mdb/optionlists. You may also be able to pass a path to an optionlist, I'm not sure. This optionlist is then copied into configs/<configname>/OptionList, and Cactus starts to build. As part of the cactus build process, the file make.config.defn is generated containing various settings based on what was in the optionlist. I consider this to be an auto-generated file, and not one that should be edited by hand. You should be able to achieve everything you need by editing the original optionlist. One gotcha is that if you do modify the optionlist in simfactory/mdb/optionlists, the next Cactus build will NOT use this updated file unless you explicitly pass the --optionlist <optionlist> argument to sim build. You didn't actually say in your email how you are building Cactus. Are you building using simfactory, i.e. "sim build", or with the Cactus make system (which is what simfactory calls), i.e. "make sim-config"? SimFactory provides a layer on top of the Cactus make system, essentially providing a database of machines, and a mapping from machine to optionlist. What instructions are you following for building? > (2) Can I assume that OPENMP=yes is the same as CCTK_OPENMP_MODE=yes ? OPENMP is an option you can set in the optionlist, whereas CCTK_OPENMP_MODE is an internal build system variable. It is set from code in lib/make/configure and make.config.defn.in based on OPENMP from the optionlist. > (3) Is it worth while to re-compile with "CPP_OPENMP_FLAGS = -fopenmp" and > "FPP_OPENMP_FLAGS = -D_OPENMP"? I'm not sure. I think it can't hurt, and it is how the other machines that use gcc are set up. > Neither of the config.logs under configs/sim/config-data or under > configs/sim/scratch/hwloc/hwloc-1.10.1 had anything useful except for the > compile line. But this is because, when "-openmp" was passed to gcc, it made > an executable named "penmp" which the configure script wasn't looking for. > So there was no actual compilation error---it just couldn't find the > resulting binary. That made this harder to diagnose. Interesting. The error message surely must have gone somewhere though! It should have complained that it couldn't find a binary of the given name. > I am still quite the newbie when it comes to parallel-processing nomenclature > and that webpage is written for someone with more CS background than I have. > I don't know if this is expected from the cactus user base so I don't know if > it warrants any changes to the simfactory documentation. My (hopefully > short-lived) ignorance (detailed here for the world to see) tells me that > node := machine. Should the correct association be node ~= motherboard and > machine ~= cluster? Aha - I was the one who wrote that page, so this is my fault. What is meant here is that machine ~= cluster, and node ~= compute node, which would indeed have a 1:1 mapping with a motherboard, and the motherboard may contain several CPUs (corresponding to "sockets"), and each CPU will contain multiple cores. > It seems to me that faster code would occupy more cores (one process per > core), not more threads/process. But it looks like I'll be wandering down to > our CS department to clean up "process," "thread," and "hyperthread" :-) That's going a bit far :) You could also try: https://en.wikipedia.org/wiki/Process_(computing) https://en.wikipedia.org/wiki/Thread_(computing) I wouldn't worry about hyperthread for now. -- Ian Hinder http://members.aei.mpg.de/ianhin
_______________________________________________ Users mailing list [email protected] http://cactuscode.org/mailman/listinfo/users
