[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