On Thu, Apr 13, 2017 at 12:54 PM, Ian Hinder <[email protected]> wrote:
> > On 13 Apr 2017, at 17:14, David Gore <[email protected]> wrote: > ... 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. > This is good to know, but I assume that simply copying the make.config.defn file to mymachine.mydomain.edu in /mdb/optionlists will probably not work. Is there a preferred way to know how to populate the 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"? > > What instructions are you following for building? > I am compiling via ./simfactory/bin/sim build [--clean] --thornlist=manifest/einsteintoolkit.th But you say that even if I create a mymachine.mydomain.edu optionlist, when I recompile, I will need to add "--optionlist=mymachine.mydomain.edu" to that build line? To be fair, I *was* kinda hoping that the build would be similar to WaveToyDemo. But when I first started by building on my debian laptop, I followed the instructions I found here: https://docs.einsteintoolkit.org/et-docs/Simplified_Tutorial_for_New_Users So I stuck with the altered build method. > 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. > It simply said that the compiler doesn't produce executables. I'm guessing it was looking for a.out. > 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. > Ok, so for a *single* computer, machine = node. I don't have such grand designs as running on a cluster. Yet. :-) > > 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) > Too late. I almost didn't get to my class on time after poking the bears in our CS department. :-) I'm a little more educated, but it still seems that---although there are caveats---one process per core is usually the faster option. > > I wouldn't worry about hyperthread for now. > Vielen Dank. ;-) > > -- > Ian Hinder > http://members.aei.mpg.de/ianhin > > -- David Gore, Ph.D., Lecturer in Physics Department of Physics, Computer Science and Engineering Christopher Newport University Office: 309 Luter Hall Voice: 757 594 7827 <%28757%29%20594-7827>
_______________________________________________ Users mailing list [email protected] http://cactuscode.org/mailman/listinfo/users
