Open yuanchao opened 6 years ago
Currently, I try to manually patch the Makefile and see the result. Somehow the LesHouches.f and LesHouchesreg.f caught the following errors: ` gfortran -fno-automatic -ffpe-trap=invalid,zero,overflow -O0 -ggdb -O0 -I/utmp/yuanchao/test_source_compilation/CMSSW_9_3_1/src/my_disquark/POWHEG-BOX/disquark/squark_antisquark/../include -I/utmp/yuanchao/test_source_compilation/CMSSW_9_3_1/src/my_disquark/POWHEG-BOX/disquark/squark_antisquark/../../include -I/utmp/yuanchao/test_source_compilation/CMSSW_9_3_1/src/my_disquark/POWHEG-BOX/disquark/squark_antisquark/../Tools/Looptools_27/include -I/utmp/yuanchao/test_source_compilation/CMSSW_9_3_1/src/my_disquark/POWHEG-BOX/disquark/squark_antisquark -I/utmp/yuanchao/test_source_compilation/CMSSW_9_3_1/src/my_disquark/POWHEG-BOX/disquark/squark_antisquark/FormCalc_Virtual/include -c -o obj/LesHouchesreg.o /utmp/yuanchao/test_source_compilation/CMSSW_9_3_1/src/my_disquark/POWHEG-BOX/disquark/squark_antisquark/../LesHouchesreg.f pwhg_rad.h:151:72:
Error: Expected another dimension in array declaration at (1) pwhg_rad.h:151:72:
Error: Expected another dimension in array declaration at (1) pwhg_rad.h:185:23:
Error: Symbol 'rad_real_arrad_normfact' at (1) has no IMPLICIT type pwhg_rad.h:194:58:
Error: Symbol 'rad_split_sign35' at (1) has no IMPLICIT type pwhg_rad.h:195:27:
Error: Symbol 'rad_split_sign45' at (1) has no IMPLICIT type pwhg_rad.h:185:23:
Error: Symbol 'rad_real_arrad_normfact' at (1) has no IMPLICIT type pwhg_rad.h:194:58:
Error: Symbol 'rad_split_sign35' at (1) has no IMPLICIT type pwhg_rad.h:195:27:
Error: Symbol 'rad_split_sign45' at (1) has no IMPLICIT type Makefile:105: recipe for target 'LesHouchesreg.o' failed make: *** [LesHouchesreg.o] Error 1 `
Dear Yuan,
is there any update on the issues? What is the timescale to address the problems?
Can you clarify why the errors above don't appear standalone ? Do we need to follow-up with the Powheg authors?
Cheers, Alexander for MEFG.
Let me check with newer version from POWHEG BOX svn.
I've checked out the latest version from SVN. ( http://cms-project-generators.web.cern.ch/cms-project-generators/slc6_amd64_gcc481/powheg/V2.0/src/powhegboxV2_rev3581_date20180801.tar.gz ) The situation is the same: undefined function type as mentioned previously. With a quick look, the author kept a private version of powheg box source in its sub-directory. If I replaced them with those in the parent directories, they can be successfully compiled. (pwhg_analysis_driver.f, LesHouchesreg.f ... ) But eventually they will conflict with the source of disquark part. Will try to contact the sub-process author.
(gcc 6.3.0, fastjet 3.1.0, lhapdf 6.2.1)
Thanks. Maybe you can put Roberto, Kenneth, Vitaliano and myself in cc.
My email sent to the author got rejected... eva.popenda@psi.ch account not exist. Though I found other co-authors in CERN phonebook. michael.spira@psi.ch mkraemer@physik.rwth-aachen.de Just sent the email to them and see if I can get responses.
any news from them? i think i only saw the email to evo, but not michael and michael?
@agrohsje Sorry forgot to put your names on the 2nd email. Still I got no response from them.
Finally got a reply from Michael Spira. According to the author, part of the powheg box code is modified to perform the calculation, so the process is version dependent. Will have to wait for the author to fix the issue.
I'm checking the compiling issue as mentioned in #1755 . This is just to open a separated ticket as the issues are crossing different revisions. Basically, taking dislepton process as an example, the path structure are different from others, the actual Makefiles are under squark_antisquark/ and squark_squark/ . Therefore some specially treatments needed for them. Previously there seem to have some issue on 'dijet' too. Though it seems to be some error handling on the test_source_compilation.sh script. This process does get compiled.