Development for LHC@home

... $ cat /proc/cmdline
BOOT_IMAGE=/vmlinuz-3.10.0-514.10.2.el7.x86_64 root=/dev/mapper/cl_teec15-root ro rd.lvm.lv=cl_teec15/root rd.lvm.lv=cl_teec15/swap rhgb quiet LANG=en_GB.UTF-8 user_namespace.enable=1 namespace unpriv_enable=1

There may be a missing ".".
You may try "namespace.unpriv_enable=1" instead of "namespace unpriv_enable=1".

Well spotted, many thanks....(bigger font...more powerful glasses...more coffee...)

Unfortunately it didn't change anything.

I think this is what you need to do. From the 7.4 release notes:

User namespace is now fully supported
The user namespace feature, previously available as a Technology Preview, is now fully supported. It provides additional security to servers running Linux containers by providing better isolation between the host and the containers. Administrators of a container are no longer able to perform administrative operations on the host, which increases security. (BZ#1138782)

Upgrade to 7.6 if you can.

Waitng for cheap internet time... hopefully it won't break anything.

I think this is what you need to do. From the 7.4 release notes:

User namespace is now fully supported
The user namespace feature, previously available as a Technology Preview, is now fully supported. It provides additional security to servers running Linux containers by providing better isolation between the host and the containers. Administrators of a container are no longer able to perform administrative operations on the host, which increases security. (BZ#1138782)

Upgrade to 7.6 if you can.

Waitng for cheap internet time... hopefully it won't break anything.

After upgrading, I get this

[m@TeeC15 ~]$ sudo echo 100 > /proc/sys/user/max_user_namespaces
-bash: /proc/sys/user/max_user_namespaces: Permission denied

But this

$ cat /proc/sys/user/max_user_namespaces
32767

indicates that it should work.

From here https://stackoverflow.com/questions/39215025/how-to-check-if-linux-user-namespaces-are-supported-by-current-os-kernel

This
You could check if your current process' /proc/[pid]/ns/ directory has a file called user:

l'm not sure how to find the pid but the one for the boinc process (which has been running throughout) does have this file, but it's empty.



The task fails like this

00:51:44 (5769): wrapper (7.7.26015): starting
00:51:44 (5769): wrapper: running ../../projects/lhcathomedev.cern.ch_lhcathome-dev/cranky-0.0.14 ()
cranky-0.0.14 INFO: Starting
cranky-0.0.14 INFO: Detected Theory App
cranky-0.0.14 INFO: Checking CVMFS.
cranky-0.0.14 INFO: Checking runc.
cranky-0.0.14 INFO: Creating the filesystem.
cranky-0.0.14 INFO: Using /cvmfs/cernvm-prod.cern.ch/cvm3
cranky-0.0.14 INFO: Updating config.json.
cranky-0.0.14 INFO: Running Container 'runc'.
cranky-0.0.14 ERROR: Container 'runc' failed.
00:55:27 (5769): cranky exited; CPU time 20.553370
00:55:27 (5769): app exit status: 0xce
00:55:27 (5769): called boinc_finish(195)

Not very informative but no unshare error.and no runc error either.

Host is running an Atlas native task at the moment - just as a check that things still work - OK so far.

I got shut out before I could finish editing this

After upgrading, I get this

[m@TeeC15 ~]$ sudo echo 100 > /proc/sys/user/max_user_namespaces
-bash: /proc/sys/user/max_user_namespaces: Permission denied

But this

$ cat /proc/sys/user/max_user_namespaces
32767

looks right

The file permissions are:-

{ user]$ ls -l
total 0
-rw-r--r--. 1 root root 0 Feb 13 03:26 max_ipc_namespaces
-rw-r--r--. 1 root root 0 Feb 13 03:26 max_mnt_namespaces
-rw-r--r--. 1 root root 0 Feb 13 03:26 max_net_namespaces
-rw-r--r--. 1 root root 0 Feb 13 03:26 max_pid_namespaces
-rw-r--r--. 1 root root 0 Feb 13 01:30 max_user_namespaces
-rw-r--r--. 1 root root 0 Feb 13 03:26 max_uts_namespaces
[ user]$

Are these right? they don't look right

The task fails like this

00:51:44 (5769): wrapper (7.7.26015): starting
00:51:44 (5769): wrapper: running ../../projects/lhcathomedev.cern.ch_lhcathome-dev/cranky-0.0.14 ()
cranky-0.0.14 INFO: Starting
cranky-0.0.14 INFO: Detected Theory App
cranky-0.0.14 INFO: Checking CVMFS.
cranky-0.0.14 INFO: Checking runc.
cranky-0.0.14 INFO: Creating the filesystem.
cranky-0.0.14 INFO: Using /cvmfs/cernvm-prod.cern.ch/cvm3
cranky-0.0.14 INFO: Updating config.json.
cranky-0.0.14 INFO: Running Container 'runc'.
cranky-0.0.14 ERROR: Container 'runc' failed.
00:55:27 (5769): cranky exited; CPU time 20.553370
00:55:27 (5769): app exit status: 0xce
00:55:27 (5769): called boinc_finish(195)

Not very informative but no unshare error.and no runc error either.

Host is running an Atlas native task at the moment - just as a check that things still work - OK so far

...
This has been successfully tested using Ubuntu 18:10.
..

Did you notice, that when suspending the native Theory task in BOINC it looks suspended in BOINC Manager, but it keeps on running full speed in the background . . .

...
This has been successfully tested using Ubuntu 18:10.
..

Did you notice, that when suspending the native Theory task in BOINC it looks suspended in BOINC Manager, but it keeps on running full speed in the background . . .

Even though I don't get to run these CP is right and I'm sure knows that when you suspend in the Boinc Manager it is a good idea to make sure they are suspended and saved in the VB Manager.

I have had some that suspend fast but others I have had to also suspend them in the VB Manager before rebooting.

Did you notice, that when suspending the native Theory task in BOINC it looks suspended in BOINC Manager, but it keeps on running full speed in the background . . .

The only process the BOINC client is aware of is the wrapper script (see client_state.xml).
I suspect that BOINC sends the pause/continue signals only to the wrapper.
The wrapper's signal handler is responsible to correctly forward those signals to all running processes of the scientific app, especially the event generator and rivet.
This should be checked by the developers.

... that when you suspend in the Boinc Manager it is a good idea to make sure they are suspended and saved in the VB Manager.

I have had some that suspend fast but others I have had to also suspend them in the VB Manager before rebooting.

Magic, we are testing here Theory native tasks, so VBox is not involved (VirtualBox is even not installed).

I got a native sherpa:

===> [runRivet] Thu Feb 14 07:29:44 UTC 2019 [boinc pp winclusive 7000 -,-,10 - sherpa 2.2.4 default 2000 16]

2000 events, mostly they are running endless. Give it a try . . .

... sherpa

Could you monitor the (log)file sizes?
Maybe you'll find out when or why it "explodes".

I think that I might rewrite cranky in bash to be more portable.

I have rewritten the script in bash to make is more portable between Linux systems.

I have rewritten the script in bash to make is more portable between Linux systems.

I got cranky-0.0.15 as well as cranky-0.0.16.
Although a task is running this seems to be a bit weird.

See a snippet from client_state.xml:

<app_version>
    <app_name>Theory</app_name>
    <version_num>408</version_num>
    <platform>x86_64-pc-linux-gnu</platform>
    <avg_ncpus>1.000000</avg_ncpus>
    <max_ncpus>1.000000</max_ncpus>
    <flops>5087108857.088130</flops>
    <plan_class>native_mt</plan_class>
    <api_version>7.7.0</api_version>
    <cmdline>--nthreads 1</cmdline>
    <file_ref>
        <file_name>wrapper_26015_x86_64-pc-linux-gnu</file_name>
        <main_program/>
    </file_ref>
    <file_ref>
        <file_name>cranky-0.0.16</file_name>
        <open_name>cranky</open_name>
    </file_ref>
    <file_ref>
        <file_name>Theory_job_2018_12_12.xml</file_name>
        <open_name>job.xml</open_name>
    </file_ref>
    <file_ref>
        <file_name>cranky-0.0.15</file_name>
    </file_ref>
    <dont_throttle/>
    <is_wrapper/>
    <needs_network/>
</app_version>

On my older host the first task failed as the script required xmllint which was not installed by default.
https://lhcathomedev.cern.ch/lhcathome-dev/result.php?resultid=2752560

2nd task is now running.
<edit>
finished successfully
https://lhcathomedev.cern.ch/lhcathome-dev/result.php?resultid=2752491
</edit>

[quote]I have rewritten the script in bash to make is more portable between Linux systems.

I got cranky-0.0.15 as well as cranky-0.0.16.

I forget to delete cranky-0.0.15. It is not used. Will remove this in another update soon when I remove the multicore planclass

I got a native sherpa:

===> [runRivet] Thu Feb 14 07:29:44 UTC 2019 [boinc pp winclusive 7000 -,-,10 - sherpa 2.2.4 default 2000 16]

2000 events, mostly they are running endless. Give it a try . . .

It doesn't look good.
Last log-line now 6 hours ago: starting the calculation at 07:30:18. Lean back and enjoy ... .
Normally integration time is shown here and time left.
Sherpa is running 100%, but nothing is added in any log file. Only the boinc_mmap_file is updated.
I'll let it run for a few more hours, else I'll abort that task.

I got a native sherpa:

===> [runRivet] Thu Feb 14 07:29:44 UTC 2019 [boinc pp winclusive 7000 -,-,10 - sherpa 2.2.4 default 2000 16]

2000 events, mostly they are running endless. Give it a try . . .

It doesn't look good.
Last log-line now 6 hours ago: starting the calculation at 07:30:18. Lean back and enjoy ... .
Normally integration time is shown here and time left.
Sherpa is running 100%, but nothing is added in any log file. Only the boinc_mmap_file is updated.
I'll let it run for a few more hours, else I'll abort that task.

If you do a hard link to the log file. It will stay around after the task has finished e.g:

sudo ln -f /var/lib/boinc-client/slots/0/cernvm/shared/runRivet.log  /tmp/runRivet.log

Also as a comment on this message, you don't need the watch command. The -f option for the tail command will 'follow' the log. From the man page:

       -f, --follow[={name|descriptor}]
              output appended data as the file grows;

              an absent option argument means 'descriptor'

       -F     same as --follow=name --retry

By default -f works on the descriptor. If a file is deleted, you can use -F to keep trying on the name. eg:

tail -F /var/lib/boinc-client/slots/0/cernvm/shared/runRivet.log 

This will always follow the log file and you will get a file truncated message when is recreated.

Got 2 singlecores (v4.09):
https://lhcathomedev.cern.ch/lhcathome-dev/result.php?resultid=2752578
https://lhcathomedev.cern.ch/lhcathome-dev/result.php?resultid=2752579

My first impression is that they use the CPU resources more gently than the multicore.
Especially during the startup phase when the scientific apps are compiled.
Multicore apps show a larger CPU peak during that phase which may unbalance systems with lots of CPUs when many tasks start up concurrently.

The "disadvantage" is that the startup phase will need a few seconds longer.

Yes. I am copying jobs from the production Theory queue. Will look at sending the results back to MCPlots later this week.

I am working on the integration with MCPlots so we will be back to manual task submission and the queue may dry up.

Sherpa is running 100%, but nothing is added in any log file. Only the boinc_mmap_file is updated.
I'll let it run for a few more hours, else I'll abort that task.

If you do a hard link to the log file. It will stay around after the task has finished e.g:

sudo ln -f /var/lib/boinc-client/slots/0/cernvm/shared/runRivet.log  /tmp/runRivet.log

I aborted the task after another few hours run, without new log info.
Thanks Laurence for your Linux cmd-hints. I saved the runRivet.log.
===> [runRivet] Thu Feb 14 07:29:44 UTC 2019 [boinc pp winclusive 7000 -,-,10 - sherpa 2.2.4 default 2000 16]

Setting environment...
grep: /etc/redhat-release: No such file or directory
MCGENERATORS=/cvmfs/sft.cern.ch/lcg/external/MCGenerators_lcgcmt67c
g++ = /cvmfs/sft.cern.ch/lcg/external/gcc/4.8.4/x86_64-slc6/bin/g++
g++ version = 4.8.4
RIVET=/cvmfs/sft.cern.ch/lcg/external/MCGenerators_lcgcmt67c/rivet/2.6.1/x86_64-slc6-gcc48-opt
Rivet version = rivet v2.6.1
RIVET_REF_PATH=/cvmfs/sft.cern.ch/lcg/external/MCGenerators_lcgcmt67c/rivet/2.6.1/x86_64-slc6-gcc48-opt/share/Rivet
RIVET_ANALYSIS_PATH=/shared/analyses
GSL=/cvmfs/sft.cern.ch/lcg/external/GSL/1.10/x86_64-slc6-gcc48-opt
HEPMC=/cvmfs/sft.cern.ch/lcg/external/HepMC/2.06.08/x86_64-slc6-gcc48-opt
FASTJET=/cvmfs/sft.cern.ch/lcg/external/fastjet/3.0.3/x86_64-slc6-gcc48-opt
PYTHON=/cvmfs/sft.cern.ch/lcg/external/Python/2.7.4/x86_64-slc6-gcc48-opt
ROOTSYS=/cvmfs/sft.cern.ch/lcg/app/releases/ROOT/5.34.26/x86_64-slc6-gcc48-opt/root

Input parameters:
mode=boinc
beam=pp
process=winclusive
energy=7000
params=-,-,10
specific=-
generator=sherpa
version=2.2.4
tune=default
nevts=2000
seed=16

Prepare temporary directories and files ...
workd=/shared
tmpd=/shared/tmp/tmp.Lm2CC3L8rl
tmp_params=/shared/tmp/tmp.Lm2CC3L8rl/generator.params
tmp_hepmc=/shared/tmp/tmp.Lm2CC3L8rl/generator.hepmc
tmp_yoda=/shared/tmp/tmp.Lm2CC3L8rl/generator.yoda
tmp_jobs=/shared/tmp/tmp.Lm2CC3L8rl/jobs.log
tmpd_flat=/shared/tmp/tmp.Lm2CC3L8rl/flat
tmpd_dump=/shared/tmp/tmp.Lm2CC3L8rl/dump
tmpd_html=/shared/tmp/tmp.Lm2CC3L8rl/html

Prepare Rivet parameters ...
analysesNames=ATLAS_2011_S9002537

Unpack data histograms...
dataFiles =
/cvmfs/sft.cern.ch/lcg/external/MCGenerators_lcgcmt67c/rivet/2.6.1/x86_64-slc6-gcc48-opt/share/Rivet/ATLAS_2011_S9002537.yoda
output = /shared/tmp/tmp.Lm2CC3L8rl/flat
make: Entering directory `/shared/rivetvm'
g++ yoda2flat-split.cc -o yoda2flat-split.exe -std=c++11 -Wfatal-errors -Wl,-rpath /cvmfs/sft.cern.ch/lcg/external/MCGenerators_lcgcmt67c/yoda/1.7.1/x86_64-slc6-gcc48-opt/lib `/cvmfs/sft.cern.ch/lcg/external/MCGenerators_lcgcmt67c/yoda/1.7.1/x86_64-slc6-gcc48-opt/bin/yoda-config --cppflags --libs`
make: Leaving directory `/shared/rivetvm'

/shared/rivetvm/complete.sh ./REF_ATLAS_2011_S9002537_d02-x01-y01.dat
/shared/rivetvm/complete.sh ./REF_ATLAS_2011_S9002537_d02-x02-y01.dat
/shared/rivetvm/complete.sh ./REF_ATLAS_2011_S9002537_d01-x01-y01.dat

Building rivetvm ...
make: Entering directory `/shared/rivetvm'
g++ rivetvm.cc -o rivetvm.exe -std=c++11 -DNDEBUG -DHIMODE=0 -Wfatal-errors -Wl,-rpath /cvmfs/sft.cern.ch/lcg/external/MCGenerators_lcgcmt67c/rivet/2.6.1/x86_64-slc6-gcc48-opt/lib -Wl,-rpath /cvmfs/sft.cern.ch/lcg/external/HepMC/2.06.08/x86_64-slc6-gcc48-opt/lib `/cvmfs/sft.cern.ch/lcg/external/MCGenerators_lcgcmt67c/rivet/2.6.1/x86_64-slc6-gcc48-opt/bin/rivet-config --cppflags --ldflags --libs` -lHepMC
make: Leaving directory `/shared/rivetvm'

Run sherpa 2.2.4 and Rivet ...
generatorExecString = ./rungen.sh boinc pp winclusive 7000 -,-,10 - sherpa 2.2.4 default 2000 16 /shared/tmp/tmp.Lm2CC3L8rl/generator.hepmc
rivetExecString = /shared/rivetvm/rivetvm.exe -a ATLAS_2011_S9002537 -i /shared/tmp/tmp.Lm2CC3L8rl/generator.hepmc -o /shared/tmp/tmp.Lm2CC3L8rl/flat -H /shared/tmp/tmp.Lm2CC3L8rl/generator.yoda -d /shared/tmp/tmp.Lm2CC3L8rl/dump
INFO: display service switched off
===> [rungen] Thu Feb 14 07:29:53 UTC 2019 [boinc pp winclusive 7000 -,-,10 - sherpa 2.2.4 default 2000 16 /shared/tmp/tmp.Lm2CC3L8rl/generator.hepmc]

Setting environment for sherpa 2.2.4 ...
tree = LCG_87
MCGENERATORS=/cvmfs/sft.cern.ch/lcg/releases/LCG_87/MCGenerators
LCG_PLATFORM=x86_64-slc6-gcc49-opt
gcc = /cvmfs/sft.cern.ch/lcg/releases/gcc/4.9.3/x86_64-slc6/bin/gcc
gcc version = 4.9.3
AGILE=/cvmfs/sft.cern.ch/lcg/releases/LCG_87/MCGenerators/agile/1.4.1/x86_64-slc6-gcc49-opt
HEPMC=/cvmfs/sft.cern.ch/lcg/releases/LCG_87/HepMC/2.06.09/x86_64-slc6-gcc49-opt
AGILE_GEN_PATH=/cvmfs/sft.cern.ch/lcg/releases/LCG_87/MCGenerators
LHAPDF=/cvmfs/sft.cern.ch/lcg/releases/LCG_87/MCGenerators/lhapdf/6.1.6.cxxstd/x86_64-slc6-gcc49-opt
LHAPATH=/cvmfs/sft.cern.ch/lcg/releases/LCG_87/MCGenerators/lhapdf/5.9.1/x86_64-slc6-gcc49-opt/../share/PDFsets
LHAPDF_DATA_PATH=/cvmfs/sft.cern.ch/lcg/releases/LCG_87/MCGenerators/lhapdf/6.1.6.cxxstd/x86_64-slc6-gcc49-opt/share/LHAPDF:/cvmfs/sft.cern.ch/lcg/releases/LCG_87/../../external/lhapdfsets/current
GSL=/cvmfs/sft.cern.ch/lcg/releases/LCG_87/GSL/2.1/x86_64-slc6-gcc49-opt

Input parameters:
mode=boinc
beam=pp
process=winclusive
energy=7000
params=-,-,10
specific=-
generator=sherpa
version=2.2.4
tune=default
nevts=2000
seed=16
outfile=/shared/tmp/tmp.Lm2CC3L8rl/generator.hepmc

Prepare temporary directories and files ...
workd=/shared
tmpd=/shared/tmp/tmp.Lm2CC3L8rl
tmp_params=/shared/tmp/tmp.Lm2CC3L8rl/generator.params

Decoding parameters of generator...
pTmin = 0
pTmax = 7000
mHatMin = 10
mHatMax = 7000

processCode=winclusive

beam1=2212
beam2=2212
beam energy = 3500.
INFO: streering file template = configuration/sherpa-winclusive.params
Prepare sherpa 2.2.4 parameters ...
seed numbers = 17 1 1 1
=> /shared/tmp/tmp.Lm2CC3L8rl/generator.params :
# steering file based on example from Sherpa 1.2.3 distribution:
# share/SHERPA-MC/Examples/Tevatron_WJets/Run.dat

(run){
# disable colorizing of text printed on screen:
PRETTY_PRINT = Off

# number of events:
EVENTS = 2000

# set random seed:
# (see section "6.1.3 RANDOM_SEED" of Sherpa manual for details)
RANDOM_SEED = 17 1 1 1

# Event output file:
EVENT_OUTPUT = HepMC_GenEvent[sherpa]
# full name of output file will be:
# "sherpa.hepmc2g"

# disable splitting of HepMC output file:
FILE_SIZE = 1000000000

# Makes particles with c*tau > 10 mm stable:
MAX_PROPER_LIFETIME = 10.0
}(run)

(beam){
BEAM_1 = 2212; BEAM_ENERGY_1 = 3500.;
BEAM_2 = 2212; BEAM_ENERGY_2 = 3500.;
}(beam)

# Setup for W->e,nu and W->mu,nu, with up to two CKKW merged jets.
# Allow for slightly lower precision on the 3- and 4-parton cross sections.
(processes){
Process 93 93 -> 11 -12 93{2}
Order (*,2)
CKKW sqr(30/E_CMS)
Integration_Error 0.01 {3};
Integration_Error 0.02 {4};

Process 93 93 -> -11 12 93{2}
Order (*,2)
CKKW sqr(30/E_CMS)
Integration_Error 0.01 {3};
Integration_Error 0.02 {4};

Process 93 93 -> 13 -14 93{2}
Order (*,2)
CKKW sqr(30/E_CMS)
Integration_Error 0.01 {3};
Integration_Error 0.02 {4};

Process 93 93 -> -13 14 93{2}
Order (*,2)
CKKW sqr(30/E_CMS)
Integration_Error 0.01 {3};
Integration_Error 0.02 {4};

End process;
}(processes)

(selector){
# Set cuts

# <l nu> inv. mass constrain
Mass -11 12 %mMin% %mMax%
Mass 11 -12 %mMin% %mMax%
Mass -13 14 %mMin% %mMax%
Mass 13 -14 %mMin% %mMax%
}(selector)

(me){
ME_SIGNAL_GENERATOR = Internal Comix
}(me)

(mi){
MI_HANDLER = Amegic # None or Amisic
}(mi)

# Parameter specifications for 'default': -------------------
#%tuneFile%
# ---------------------------------------------
--------------------------------------

SHERPA=/cvmfs/sft.cern.ch/lcg/releases/LCG_87/MCGenerators/sherpa/2.2.4/x86_64-slc6-gcc49-opt
Run sherpa 2.2.4 ...
generatorExecString = /cvmfs/sft.cern.ch/lcg/releases/LCG_87/MCGenerators/sherpa/2.2.4/x86_64-slc6-gcc49-opt/bin/Sherpa -f /shared/tmp/tmp.Lm2CC3L8rl/generator.params
Welcome to Sherpa, <unknown user>. Initialization of framework underway.
The local time is Thu Feb 14 07:30:00 2019.
Run_Parameter::Init(): Setting memory limit to 3.75422 GB.
Random::SetSeed(): Seeds set to 17 1 1 1
-----------------------------------------------------------------------------
----------- Event generation run with SHERPA started ....... -----------
-----------------------------------------------------------------------------
................................................ | +
................................................ || | + +
................................... .... | | / +
................. ................ _,_ | .... || +| + +
............................... __.' ,\| ... || / +| +
.............................. ( \ \ ... | | | + + \ +
............................. ( \ -/ .... || + | +
........ ................... <S /()))))~~~~~~~~## + /\ +
............................ (!H (~~)))))~~~~~~#/ + + | +
................ ........... (!E (~~~))))) /|/ + +
............................ (!R (~~~))))) ||| + + +
..... ...................... (!P (~~~~))) /| + + +
............................ (!A> (~~~~~~~~~## + + +
............................. ~~(! '~~~~~~~ \ + + + +
............................... `~~~QQQQQDb // | + + + +
........................ .......... IDDDDP|| \ + + + + + +
.................................... IDDDI|| \ +
.................................... IHD HD|| \ + + + + + + + +
................................... IHD ##| :-) + +\ +
......... ............... ......... IHI ## / / + + + + +\ +
................................... IHI/ / / + + + + +
................................... ## | | / / + + + + / +
....................... /TT\ ..... ##/ /// / + + + + + + +/ +
......................./TTT/T\ ... /TT\/\\\ / + + + + + + +/ \ +
....................../TTT/TTTT\...|TT/T\\\/ + ++ + /
-----------------------------------------------------------------------------

SHERPA version 2.2.4 (Cho Oyu)

Authors: Enrico Bothmann, Stefan Hoeche, Frank Krauss,
Silvan Kuttimalai, Marek Schoenherr, Holger Schulz,
Steffen Schumann, Frank Siegert, Korinna Zapp
Former Authors: Timo Fischer, Tanju Gleisberg, Hendrik Hoeth,
Ralf Kuhn, Thomas Laubrich, Andreas Schaelicke,
Jan Winter

This program uses a lot of genuine and original research work
by other people. Users are encouraged to refer to
the various original publications.

Users are kindly asked to refer to the documentation
published under JHEP 02(2009)007

Please visit also our homepage

http://sherpa.hepforge.org

for news, bugreports, updates and new releases.

-----------------------------------------------------------------------------

SVN branch branches/rel-2-2-4, revision 30888.

Beam_Spectra_Handler :
type = Monochromatic*Monochromatic
for P+ ((3500,0,0,3500))
and P+ ((3500,0,0,-3500))
WARNING: M_TOP=0 replacing with SHERPA top mass: M_TOP=173.21
PDF set 'NNPDF30NNLO' loaded for beam 1 (P+).
WARNING: M_TOP=0 replacing with SHERPA top mass: M_TOP=173.21
PDF set 'NNPDF30NNLO' loaded for beam 2 (P+).
Initialized the ISR: (SF)*(SF)
WARNING: M_TOP=0 replacing with SHERPA top mass: M_TOP=173.21
WARNING: M_TOP=0 replacing with SHERPA top mass: M_TOP=173.21
One_Running_AlphaS::One_Running_AlphaS() {
Setting \alpha_s according to PDF
perturbative order 2
\alpha_s(M_Z) = 0.118
}
One_Running_AlphaS::One_Running_AlphaS() {
Setting \alpha_s according to PDF
perturbative order 2
\alpha_s(M_Z) = 0.118
}
List of Particle Data
IDName kfc MASS[<kfc>] WIDTH[<kfc>] STABLE[<kfc>] MASSIVE[<kfc>] ACTIVE[<kfc>] YUKAWA[<kfc>]
d 1 0.01 0 1 0 1 0
u 2 0.005 0 1 0 1 0
s 3 0.2 0 1 0 1 0
c 4 1.42 0 1 0 1 0
b 5 4.8 0 1 0 1 0
t 6 173.21 2 0 1 1 173.21
e- 11 0.000511 0 1 0 1 0
ve 12 0 0 1 0 1 0
mu- 13 0.105 0 1 0 1 0
vmu 14 0 0 1 0 1 0
tau- 15 1.777 2.26735e-12 0 0 1 0
vtau 16 0 0 1 0 1 0
G 21 0 0 1 0 1 0
P 22 0 0 1 0 1 0
Z 23 91.1876 2.4952 0 1 1 91.1876
W+ 24 80.385 2.085 0 1 1 80.385
h0 25 125 0.00407 0 1 1 125

List of Particle Containers
IDName kfc Constituents
l 90 {e-,e+,mu-,mu+,tau-,tau+}
v 91 {ve,veb,vmu,vmub,vtau,vtaub}
j 93 {d,db,u,ub,s,sb,c,cb,b,bb,G}
Q 94 {d,db,u,ub,s,sb,c,cb,b,bb}
r 99 {d,db,u,ub,s,sb,c,cb,b,bb,G}

Hadron_Init::Init(): Initializing kf table for hadrons.
Initialized the Fragmentation_Handler.
Initialized the Soft_Collision_Handler.
CS_Shower::CS_Shower(): Set respect Q2 mode 0
CS_Shower::CS_Shower(): Set color setter mode 0
CS_Shower::CS_Shower(): Set respect Q2 mode 0
CS_Shower::CS_Shower(): Set color setter mode 0
Initialized the Shower_Handler.
ME_Generator_Base::SetPSMasses(): Massive PS flavours for Internal: (c,cb,b,bb,e-,e+,mu-,mu+,tau-,tau+)
ME_Generator_Base::SetPSMasses(): Massive PS flavours for Comix: (c,cb,b,bb,e-,e+,mu-,mu+,tau-,tau+)
+----------------------------------+
| |
| CCC OOO M M I X X |
| C O O MM MM I X X |
| C O O M M M I X |
| C O O M M I X X |
| CCC OOO M M I X X |
| |
+==================================+
| Color dressed Matrix Elements |
| http://comix.freacafe.de |
| please cite JHEP12(2008)039 |
+----------------------------------+
Matrix_Element_Handler::BuildProcesses(): Looking for processes .................................................................................................................................................................................... done ( 47 MB, 11s / 10s ).
Matrix_Element_Handler::InitializeProcesses(): Performing tests .................................................................................................................................................................................... done ( 47 MB, 0s / 0s ).
Initialized the Matrix_Element_Handler for the hard processes.
Initialized the Beam_Remnant_Handler.
Hadron_Decay_Map::Read: Initializing HadronDecays.dat. This may take some time.
Initialized the Hadron_Decay_Handler, Decay model = Hadrons
Initialized the Soft_Photon_Handler.
Variations::InitialiseParametersVector(0 variations){
Named variations:
}
Process_Group::CalculateTotalXSec(): Calculate xs for '2_2__j__j__e-__veb' (Comix)
Starting the calculation at 07:30:18. Lean back and enjoy ... .

Running CentOS Linux 7 .6
(Core) 3.10.0-957.5.1.el7.x86_64

Whatever caused this:-

00:51:44 (5769): wrapper (7.7.26015): starting
00:51:44 (5769): wrapper: running ../../projects/lhcathomedev.cern.ch_lhcathome-dev/cranky-0.0.14 ()
cranky-0.0.14 INFO: Starting
cranky-0.0.14 INFO: Detected Theory App
cranky-0.0.14 INFO: Checking CVMFS.
cranky-0.0.14 INFO: Checking runc.
cranky-0.0.14 INFO: Creating the filesystem.
cranky-0.0.14 INFO: Using /cvmfs/cernvm-prod.cern.ch/cvm3
cranky-0.0.14 INFO: Updating config.json.
cranky-0.0.14 INFO: Running Container 'runc'.
cranky-0.0.14 ERROR: Container 'runc' failed.
00:55:27 (5769): cranky exited; CPU time 20.553370
00:55:27 (5769): app exit status: 0xce
00:55:27 (5769): called boinc_finish(195)

was fixed between cranky 0.0.14 and 0.0.17 (I didn't try xx15 or xx16)
Perhaps because Laurence wrote:-

I have rewritten the script in bash to make is more portable between Linux systems.

Now running OK.

I've still got some tidying up to do...

This sherpa was running OK (and fast)

===> [runRivet] Fri Feb 15 15:43:49 UTC 2019 [boinc pp top-mc 7000 - - sherpa 2.2.4 default 100000 18]

https://lhcathomedev.cern.ch/lhcathome-dev/result.php?resultid=2752621