Sherpa3

[apricePhy]

Hi,
We have officially released Sherpa 3.0.0 (https://sherpa-team.gitlab.io/changelog.html#sherpa-3-0-0-erebus) which contains many improvements, some especially dedicated to e+e-. I would recommend including this in the Key4hep framework.

Sherpa3 is built with cmake and should be reasonably simple. Let me know if you need any assistance.

Cheers,
Alan

[jmcarcell]

Has the format for the run cards changed in 3.0.0? I'm trying to run with

(run){
 RANDOM_SEED 42;
 BEAM_1 11;
 BEAM_2 -11;
 BEAM_ENERGY_1 125.0;
 BEAM_ENERGY_2 125.0;
 MODEL HEFT;
 PDF_LIBRARY None;
 EVENTS 10000;


 MASS[25] 125;
 WIDTH[25] 0.00407;
 MASS[23] 91.1876;
 WIDTH[23] 2.4952;
 MASS[24] 80.379;
 WIDTH[24] 2.085;
 EVENT_OUTPUT HepMC3_GenEvent[ZHDecay250.hepmc3g];
 EVENT_GENERATION_MODE unweighted;
 MASSIVE[13] 1;
 ME_SIGNAL_GENERATOR Amegic;
}(run)

(processes){
  Process 11 -11 -> 23[a] 25[b] ;
  Decay 23[a]  -> 15 -15 
  Decay 25[b]  -> 13 -13 
  Order (0,4);
  End process;
}(processes)

(selector){
 PT 15 20 125
 PT 13 20 125
 PT -13 20 125
}(selector)

but it isn't working with:

...
Particle containers:
┌─────────────────────────────────────────────────────────────────────────────────────────┐
│      Name  Kf-code  Constituents                                                        │
├─────────────────────────────────────────────────────────────────────────────────────────┤
│         l       90  e-, e+, mu-, mu+, tau-, tau+                                        │
│         v       91  ve, veb, vmu, vmub, vtau, vtaub                                     │
│         f       92  d, db, u, ub, s, sb, c, cb, b, bb, e-, e+, mu-, mu+,                │
│                     tau-, tau+, 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                                   │
│       ewj       98  d, db, u, ub, s, sb, c, cb, b, bb, G, P                             │
└─────────────────────────────────────────────────────────────────────────────────────────┘
Fatal error thrown:
Invalid syntax
WARNING: You are using an unsupported development branch.
┌──────────────────────────────────────────────────────────┐
│ Please cite the publications listed in 'References.tex'. │
└──────────────────────────────────────────────────────────┘
Terminator_Object_Handler::Exit: Exiting Sherpa with code (1)

[apricePhy]

Hi Juan,

Yes, that is one of the major changes, we now use yaml. You can find an example to test in Jets_at_LeptonColliders/LEP_Jets/Sherpa.yaml which should validate the default setup for e+e-.

Alan

[apricePhy]

Maybe if its not too painful, could we have a distinct sherpa3 and sherpa where sherpa is the old 2.y.z? This will allow for an easier transition for the users

[jmcarcell]

Then I have to change the executable since in both cases it would be Sherpa (and if I give it another name then it has to be changed again when both versions stop being together in the stack) and if nothing fails there is never an incentive to move to version 3. I think you are probably the main users so we can do as you want but I think the least headache inducing way is to switch one day to version 3 and use older nightlies (while they exist) or the last release if you want version 2, and from then onwards everything would be version 3.

[jmcarcell]

An additional detail, this seems not to have been disabled for the release: https://gitlab.com/sherpa-team/sherpa/-/blob/master/ATOOLS/Org/Run_Parameter.C#L470 and the message "You are using an unsupported development branch." appears several times when running.

[apricePhy]

Hi Juan,
I have a solution to both the issues. I would recommend that you checkout the rel-3-0-x branch which is a maintenance branch for this release series including further bugfixes. Then I would add the cmake option DSHERPA_ENABLE_VERSIONING=ON. Then when Sherpa is built the executable will Sherpa-3-0-0. This will remain unchanged with minor bug updates. Then when minor and major physics releases come we can revisit this.

Having this type of control over the version could be beneficial in the future. It is not unheard of that differen physics analysis groups prefer different versionst

[tmadlener]

One thing that would speak for a dedicated package for sherpa3 is that older versions of sherpa use autotools, but sherpa3 ha switched to cmake. I am not sure if spack actually supports version dependent build tools.

[jmcarcell]

One thing that would speak for a dedicated package for sherpa3 is that older versions of sherpa use autotools, but sherpa3 ha switched to cmake. I am not sure if spack actually supports version dependent build tools.

They do, see spack/spack#45101

[jmcarcell]

Hi Juan, I have a solution to both the issues. I would recommend that you checkout the rel-3-0-x branch which is a maintenance branch for this release series including further bugfixes. Then I would add the cmake option DSHERPA_ENABLE_VERSIONING=ON. Then when Sherpa is built the executable will Sherpa-3-0-0. This will remain unchanged with minor bug updates. Then when minor and major physics releases come we can revisit this.

Having this type of control over the version could be beneficial in the future. It is not unheard of that differen physics analysis groups prefer different versions

I don't like the idea of building from a branch, then one has to save the commit to make sure that it can be reproduced, if the branch is deleted then it's not easy anymore, etc. I propose the following solution which doesn't break current compatibility and just adds Sherpa v3:

• I added another package that I called sherpa2 which is the recipe that was used to build 2.X.X, this is being built in the stack as it was before, so Sherpa hasn't changed. In the stack, it will appear as sherpa2 if one looks in the folders or lists the packages.
• I also installed Sherpa 3.0.0 but moved the executable to be Sherpa3. So now, with the nightlies and on AlmaLinux 9:

$ Sherpa3 --version
Sherpa version 3.0.0 (Erebus)
$ Sherpa3-config --version
3.0.0

In the stack, it will appear as sherpa as I'm picking up the recipe from Spack that now has 3.0.0.

From some quick testing it seems the installations don't interfere with each other (I was able to run successfully both) so that it's possible to keep them both like this. Note that the choice of calling it Sherpa3 I made it myself, but I also didn't like Sherpa-3-0-0 because I think this means when the version changes the executable name changes? We probably don't want that. Please have a look and let me know if this works.