Contur 2.1.1->2.4.4, Rivet 3.1.5->3.1.8 upgrade #412
Conversation
Still needs testing and possibly ironing out rivet config issues
…only build LHC rivet analyses
…_2_4_1_upgrade_try2
Not something I've ever seen with YODA externally: getting the Python dir structure correct (for the particular Python install) within the given prefix has proven challenging to do portably, though I think the most recent releases without distutils do it as well as is possible, but the path prefix should always have been respected. Is this using the most recent YODA 1.9.x? |
It is using 1.9.9 |
In fact, we upgraded from 1.9.7 to fix a different issue, but this one seems to have been introduced by going from 1.9.7 -> 1.9.9 |
|
The YODA configure command:
Was changed in 1.9.7 to
in 1.9.9. This looks like this is the reason why it is trying to access the wrong location. If I just open python on the Mac and run these commands (just setting '${prefix}' to 'PREFIX'): First Case:
Second Case:
So in the updated yoda case, nothing is being replaced with the prefix. |
|
Thanks @ChrisJChang . The extra complexities in that command were to account for YODA doing some silly things with the path-completion reporting, such that we needed to strip out misattributed additional |
|
@agbuckley , a little playing around suggests that its actually the 'posix_user' option that is having the effect here. The 'userbase' option won't appear in the path unless the scheme is supplied (a few work, not only posix_user). And if they are specified, the 'userbase' option isn't necessary. i.e.
but
Looking at the documentation for this (https://docs.python.org/3/library/sysconfig.html), it seems to me like the default scheme should be one of the posix ones. However, for me it is the 'osx_framework_library' one. Perhaps the mac testing others have done had a different default scheme than my machine? |
|
Thanks for the digging, @ChrisJChang : I'm not sure exactly what's going on with the inconsistent Python behaviours re. this on different platforms, but I've added the |
|
May I ask what the status of this PR is? |
Other than the mac issues you identified above, everything is ready to go. If you give me 1-2 weeks, I can probably do the 3.1.10 upgrade, the extra analyses would be nice. It would be good to get it ready for susyrun2 post-processing, I guess. |
Awesome. Based on some discussions in the core group, and that the state of the Mac CIs has been changing a lot (e.g. I need to go and rebuild a bunch of stuff on them), I would suggest not bothering too much to fix it for the Macs right now, and if it is ready to go for Linux, then feel happy to merge if Anders has approved it for merging.
This is another option. I would suggest deciding on whether to do this based on the susyrun2 post-processing, rather than Mac builds. |
If the mac's not a blocker, then I would merge this. Then I can make a 3.1.10 PR when/if required (should hopefully be less complicated than this one) |
|
Sounds good! I justed merged the latest master into this branch, so I'll merge it once the Ubuntu CI jobs have completed successfully. |
|
Sorry, one more thing, @tprocter46: I tried to build this branch now on my Ubuntu machine and I get a some compilation errors -- see below for a list of the first few that show up. (This was starting from a clean state, after Does the branch build and run OK for you? The first few errors seem to just be related to the |
Hmmm... seems to be compiling fine on my laptop. Both the setup I was working with before, and I also did a clean build in a newly cloned repo. Is it possible you have some stuff from old contur versions kicking about? As we updated the cmake for the new contur version, then it's possible it wouldn't get cleaned out by If its still not working I can try rebuilding on the glasgow cluster, to see if I can reproduce the problem there. |
…ade_try3 Conflicts: Backends/patches/rivet/3.1.8/patch_rivet_3.1.8.dif
|
Hi @anderkve -- I've just retried this in a completely new repo (on the Glasgow cluster this time, not my laptop) and I can't reproduce the error you saw -- it seems to compile fine. If we do any postprocessing for SusyRun2 it would be good to use a more up-to-date contur version -- with that in mind, I've changed the PR target to SusyRun2, but am happy to change it back if that complicates things further. (Separately, in trying to rebuild gambit on the glasgow cluster I noticed something weird is going on with cmake and finding GSL -- if I get to the bottom of it I may try and make another PR) |
|
I just did a fresh build test, and I can confirm that it is successfully building for me too. @anderkve , would you have time to test again? Alternatively, we could say that this is ready to merge in. |
This PR updates the version of Rivet from 3.1.5 to 3.1.8; and Contur from 2.1.1 to 2.4.1.
The main improvement this brings us is a lot more rivet analyses (and hence measurements for contur to examine), as well as some updates to how contur runs.
There are a few other changes that needed to be made as a result of this:
Contur_outputclass has been redesigned to handle the new way contur returns results.Contur_get_analyses_from_beamconvenience function rewritten completely due to redesign of the contur database.Some remaining questions:
Multi_contur...functions? 2.4.1 by default already calculates both theory and SMBG likelihoods, which was our original motivation for creating these. I guess there are still situations where the multi versions do things we couldn't do otherwise, but I struggle to see where this'd be useful.Everything seems to run fine on my system, but given recent experience, a cross-check on a mac probably wouldn't hurt.
Also, just to note, there's a slightly hacky thing done to the python path for rivet in backends.cmake because 3.1.8 behaves slightly unpredictable in where it installs the python libraries. Hopefully it's fixed in 3.1.9/3.2.0.