#16 closed enhancement (fixed)
HepEvt common block size requested to be 10000 by ATLAS
Reported by: | Frank Siegert | Owned by: | Frank Siegert |
---|---|---|---|
Priority: | minor | Milestone: | |
Component: | Unknown | Version: | 1.1.3 |
Keywords: | HEPEVT | Cc: | ozenin@cern.ch |
Description
Since ATLAS wants to use TAUOLA and PHOTOS on top of Sherpa, the sizes of the HEPEVT common blocks of these have to match ours (which is 4000 right now).
Attachments (2)
Change History (16)
comment:1 Changed 16 years ago by
comment:2 Changed 16 years ago by
comment:3 Changed 16 years ago by
Resolution: | → fixed |
---|---|
Status: | new → closed |
Fixed on trunk (r11084). Will be in bug-fix release 1.1.3.
Changed 16 years ago by
Attachment: | SHERPA-MC-1.1.3-hepevt.patch added |
---|
comment:4 Changed 16 years ago by
Resolution: | fixed |
---|---|
Status: | closed → reopened |
Type: | defect → enhancement |
One remark on the default HEPEVT size setting:
E.g., CMS is known to still use HEPEVT size = 4000.
Can `--enable-hepevt=<hepevt_size>' option be provided for configure script, just like this is implemented in the attached patch?
Thank you.
comment:5 Changed 16 years ago by
Cc: | Alberto.Ribon@cern.ch Mikhail.Kirsanov@cern.ch added |
---|---|
Version: | 1.1.2 → 1.1.3 |
comment:6 Changed 16 years ago by
Cc: | Alberto.Ribon@cern.ch Mikhail.Kirsanov@cern.ch removed |
---|
comment:7 Changed 16 years ago by
Keywords: | HEPEVT added |
---|
comment:9 Changed 16 years ago by
Cc: | ozenin@cern.ch added |
---|
Hi Oleg,
thanks for your suggestion. I don't quite understand your patch: You can't do an #include "config.h" in a Fortran file, can you? And what purpose does the renaming of pythia6214.f to pythia6214.F have?
Frank
comment:10 Changed 16 years ago by
Hi Frank,
Preprocessor directives like #include are correctly processed by g77 and gfortran compilers which use the `cpp' preprocessor for this purpose.
The .F' extension indicates that the fortran source must be processed by
cpp' before being passed to the fortran compiler. On the other hand, `.f' files are
not preprocessed unless the compiler is invoked with `-x f77-cpp-input'.
Thus, renaming pythia6214.f to pythia6214.F may be the easiest way to run the preprocessor first.
WBR, Oleg.
comment:11 Changed 16 years ago by
Resolution: | → fixed |
---|---|
Status: | reopened → closed |
Thanks for the explanation. I have prepared a patch which avoids having to run cpp on the fortran files, but does the replacement already during configure.
I am attaching it here, and you can apply it with patch -p0 < hepevt-size.patch
. I had to leave the default at 10000 (because that's what we just communicated to our users as the new default), but that shouldn't be a problem for you, right?
Please give me feedback whether everything works as expected.
Thanks, Frank
Changed 16 years ago by
Attachment: | hepevt-size.patch added |
---|
comment:12 Changed 16 years ago by
Sorry, that patch was too big to upload (because of moving all of pythia code around). I uploaded it to http://www.ippp.dur.ac.uk/~fsiegert/hepevt-size.patch
Frank
comment:13 Changed 13 years ago by
Milestone: | → rel-old |
---|
One possible solution: Disable compilation of Lund and the Lund_Interface, such that we don't initialize a HEPEVT common block at all. Of course this means that fragmentation and decays can't be done through Lund anymore.
Implemented as r11024 on trunk.