Update SHERPA to v2.2.8, import OpenLoops #2072
Conversation
- Upgrade SHERPA to v2.2.8 - Add new build recipe for OpenLoops - Specify Openloops version alice/v2.1.0 (customization for out-of-source builds as usually done by ALICE) - Add dependency on OpenLoops in SHERPA
ghost
requested review from
|
I created https://github.com/alisw/openloops and made you an admin. Can you move there the code? Thanks. |
|
@ktf Thanks a lot! I will move the code there. Fork was just a temporary solution. We need our own fork and cannot take the official as without the modifications OpenLoops requires the processes in the build directory, which is in case of ALICE builds different from the install directory. |
|
Openloops v2.1.0 is now imported as tag v2.1.0-alice1, together with branch alice/v2.1.0 in alisw/openloops. The build recipe is adapted. |
|
Thanks. I cleaned up stuff for the linker. In particular DYLD_LIBRARY_PATH is useless when SIP is enabled. We might have to do some magic to get |
|
Thanks! For what concerns the SHERPA: There is an official repo https://gitlab.com/sherpa-team/sherpa, and my PR (alisw/SHERPA#2) is nearly an identical clone, however as there is no configure option for disabling the manuals which create compiler errors we need disable it in the makefile ourselves and therefore need our own fork (same issue was there in v2.2.4). After the import of the SHERPA version I would adapt the build recipe for SHERPA to use the tag from the alisw fork, and the PR should be good to go. |
- GMP needed as build dependency introduced by fastjet - Several dependencies in the modulefile were misspelled, consequently the module was not loaded.
mfasDa
changed the title
|
Hi, I have looked at the jet spectrum and it seems ok |
|
@maireiphc up to you to approve. |
|
Before merging I would suggest to create the branch and tag in the ALICE SHERPA fork and adapt the build recipe once more to use the tag from the ALICE fork. |
| tag: "v2.2.4-alice1" | ||
| source: https://github.com/alisw/SHERPA | ||
| tag: "v2.2.8-alice1" | ||
| source: https://github.com/mfasDa/SHERPA |
There was a problem hiding this comment.
The intent is likely to change this l.4 before the actual merging, to pick-up the tag v2.2.8-alice1
from https://github.com/alisw/SHERPA and not from Markus' fork used for development
See the parallel alisw/SHERPA#2 where we are about to create new branch v2.2.8 and then tag v2.2.8-alice1 for alisw/SHERPA
There was a problem hiding this comment.
Of course, my own fork was just a temporary solution for the testing phase.
|
When merging the PR please squash-merge the commit (if possible keeping only the commit message of the first commit). |
For the official test, we switch from @mfasDa development repo to our official alisw repo. . The tag v2.2.8-alice1 has just been done : https://github.com/alisw/SHERPA/tree/v2.2.8-alice1 . See initial PR for details : #2072
|
For the official test, we switch from @mfasDa development repo to our official alisw repo. . The tag v2.2.8-alice1 has just been done : https://github.com/alisw/SHERPA/tree/v2.2.8-alice1 . See initial PR for details : #2072
|
Hi @mfasDa can you inspect the daily build outcome : it seems to fail on OpenLoops compilation : See Daily build console output, yesterday and 2-days ago : NB : OpenLoops is build quite soon in the package order |
|
I was able to build openloops over the weekend. The problem happens when building the process libraries, which is something handled by openloops internally. Maybe just a temporary network glitch - could you try to test building aligenerators again? |
|
To my knowledge, I do not have an hand on this test build. LIkely sthg for @ktf... |
|
Hello all, today daily tag failed due to a similar reason at the OpenLoop compilation level : |
|
Hi Markus, all, Just to add that I have test-compiled AliGenerators last week (on SL7) and it worked there. Do we/you happen to know which file it is trying to download/which server is being contacted? Could it be SL6-specific? Marco. |
|
I have compiled AliGenerators on my Ubuntu 18.04 LTC this morning after an update of alidist.
OpenLoops took super long to be through (>1h30) but in the end, it went compiled. Under /sw/ubuntu1804_x86-64/Openloops/v2.1.0-alice1-1/proclib, one can see this is 1.3G of NLO libs with 1G for the sole ppjjjj_lt (pp to 4 jets ?) Can't find the exact url behind the scene : |
|
Hi Antonin, The file sizes you list above sound very large, so I had a look at my AliGenerators directory, and indeed openloops is quite large, but so are some other packages (e.g. Herwig, EPOS and even Python-modules are all on the Gb level space wise), so I wouldn't worry about this too much.... The file sizes that I find are as follows: The URL that it is trying to acceess is something like: and the config['remote_process_url'] is: I don't know exactly what comes out of the subsequent code; in particular how the %s is filled. There is no obvious dependence on system version, though. |
|
Hi @marcovanleeuwen , Hi @maireiphc , The whole repository of the openloops processes is 15 GB. We have to select only the most fundamental processes. I have limited for the moment to pp->JJ(x), in case EW processes are desired they need to be added. For what concerns the compile time I had to reduce the number of CPUs for the process library builds because memory consumption was too high. The openloops package handler is unfortunately not very flexible and I am not sure we should hack it. The process libraries are however essential in order to be able to calculate at NLO. Cheers Markus |
|
OK, I see. Looking again at the logs, I notice that it says: which does suggest that it cannot reach the repository. @ktf, are there any restrictions on where the build hosts can download files from? The openloops scripts need to access pages on this domain: https://www.physik.uzh.ch/data/openloops/repositories |
|
Look, what about disabling Sherpa for a few days from AliGenerators ? |
|
Some input for build system admin @ktf (@pzhristov ?) to be tested on dedicated machines. Dear Antonin, apparently the Problem appears when the script tries to download the file Please ensure yourself that the internet connection is working. Here is a minimal script that you can use for testing (you might also want to try with a different URL): Best wishes, |
|
Hello @ktf @pzhristov @maireiphc @marcovanleeuwen @mfasDa and all, I can reproduce the As far as I can tell it is not an internet issue, but something possibly wrong in the Here is the line of reasoning and testingStart with this piece of You will see in the following tests that this script only fails on the ALICE SLC6 build system. ALICE SLC6 build system - DOES NOT WORKThe container is the Test internet connection and that the URL works Internet connection works and the URL is reachable. The My computer system (Ubuntu 18.04) - WORKSTest internet connection and that the URL works Internet connection works and the URL is reachable. The CERN CC7 base system - WORKSThe container is the Test internet connection and that the URL works Internet connection works and the URL is reachable. The CERN SLC6 base system - WORKSThe container is the Test internet connection and that the URL works Internet connection works and the URL is reachable. The |
|
Hello @ktf, I found the source of the issue above. I have built the docker container starting from If I keep the If I remove the As a matter of fact, it is only this line that creates the troubles So, I now have a way to screw all the other systems. |
|
to me, the solution for this is |
|
The trick works, Check the full output here. |
for out-of-source builds as usually done by ALICE)