[Users] Cactus build problems

Ian Smith the.pond at dsl.pipex.com
Wed Aug 20 09:21:15 CDT 2014


On 20/08/14 14:58, Frank Loeffler wrote:
> On Wed, Aug 20, 2014 at 02:53:24PM +0100, Ian Smith wrote:
>> $ cat simfactory/mdb/machines/sumo.ini
>> [generic]
>
> Change this to [sumo] - because then simfactory will know that this
> machine's name is 'sumo'.
>
>> # Access to this machine
>> hostname        = generic.some.where
>> aliaspattern    = ^generic\.some\.where$
>
> You should probably change this to match sumo as well. This way you
> don't have to give the machine file for every command.
>
>> # Source tree management
>> sourcebasedir   = /home/@USER@
>> optionlist      = generic.cfg
>> submitscript    = generic.sub
>> runscript       = generic.run
>
> The 'generic' option list is quite 'reduced'. It might make more sense
> to use a more specific option list here (debian/ubuntu/...).
>
>> ppn             = 2   # or more
>> max-num-threads = 2  # or more
>> num-threads     = 2   # or more
>> nodes           = 1
>
> This looks good, assuming this is a one machine with two cores.
>
> Frank
>

Hi Frank,

I have now solved the problem, just trying to understand precisely what 
I did to fix it!  It seems that I already had a machine file (not sure 
at what point it was created) but unfortunately I didn't notice it earlier:

$ cat simfactory/mdb/machines/sumo.doitto.me.uk.ini

[sumo.doitto.me.uk]

# Machine description
nickname        = sumo.doitto.me.uk
name            = sumo.doitto.me.uk
location        = somewhere
description     = Whatever
status          = personal

# Access to this machine
hostname        = sumo.doitto.me.uk
aliaspattern    = ^generic\.some\.where$

# Source tree management
sourcebasedir   = /opt/EinsteinToolkit
optionlist      = 
/opt/EinsteinToolkit/Cactus/simfactory/mdb/optionlists/debian.cfg
submitscript    = generic.sub
runscript       = 
/opt/EinsteinToolkit/Cactus/simfactory/mdb/runscripts/debian.sh
make            = make -j2
basedir         = /home/ian/simulations
ppn             = 2
max-num-threads = 2
num-threads     = 2
nodes           = 1
submit          = exec @SCRIPTFILE@ < /dev/null > /dev/null 2> /dev/null 
& echo $!
getstatus       = ps @JOB_ID@
stop            = kill @JOB_ID@
submitpattern   = (.*)
statuspattern   = "^ *@JOB_ID@ "
queuedpattern   = $^
runningpattern  = ^
holdingpattern  = $^
exechost        = echo localhost
exechostpattern = (.*)
stdout          = cat @SIMULATION_NAME at .out
stderr          = cat @SIMULATION_NAME at .err
stdout-follow   = tail -n 100 -f @SIMULATION_NAME at .out @SIMULATION_NAME at .err

So I did a build with this file as the --mdb oarameter, and now the 
command I use is:

./simfactory/bin/sim submit static_tov 
--parfile=par/static_tov_small.par --walltime=8:0:0

ie. I am not specifying cores or machines for the simulation on the 
command line any more.  This now seems to work on two cores!  So, if I 
had seen the file earlier, I might have just got away with editing it. 
As it is I rebuilt simfactory with the proper file, I don't know if I 
needed to.  I might just reinstall tomorrow to settle it, but for now I 
think I'll continue to try out the software . . .

Thanks to everyone for your patience!

Cheers,

Ian.



More information about the Users mailing list