Problems with hep2lhe

Asked by teddym on 2014-02-21

Hi~

  I Enter the directory of my own process and run ./bin/madevents and run "pythia run_01" ( I've run the whole analysis parton+pythia+delphes when using "launch" ) and runing the model pythia+delphes.

However It does not work well:
"
Creating Pythia LHE File
Generating pythia lhe events
Warning! Never use this pythia lhe file for detector studies!
Creating Pythia LHE Root File
** Calculating number of events to process. Please wait...
** Input file contains 0 events
** Exiting...
"

And when I use "hep2lhe" to convert .hep file to .lhe myself it crashed and display:
"
 mcfio_NextEvent: Error Repositioning stream

     STDXRD: unrecognized status - stop
"

I don't know why, because when first running this process using launch there is no such problems. I wonder whether the .hep have some problems and would affect the result of delphes? ( delphes runs without problems and gives the required number of events )

Question information

Language:
English Edit question
Status:
Answered
For:
MadGraph5_aMC@NLO Edit question
Assignee:
Pavel Demin Edit question
Last query:
2014-04-09
Last reply:
2015-01-30
Whiteboard:
Hi Pavel, Could you check that your fix for large STDHEP file was correctly include in this version? The UpdateNotes said that is was done but maybe not correctly... Cheers, Olivier

This question was reopened

teddym (niepanchongsheng) said : #1

Furthermore, when using ExRootSTDHEPConverter to convert the .hep file to .lhe file, it works well!

teddym (niepanchongsheng) said : #2

I'm sorry, it should be " convert .hep file to .root file"

teddym (niepanchongsheng) said : #3

It seems like that the program "hep2lhe" constrains the max Number of particles in one events, is this the reason? and how could I modify the hep2lhe.f file?

Hi,

indeed they are a limit to 4000 entry by event.
you can increase this number if you want:

They are two lines to modify:
around line 21
      COMMON/PYJETS/N,NPAD,K(4000,5),P(4000,5),V(4000,5)
around line 54
      PARAMETER (NMXHEP=4000)

Cheers,

Olivier

teddym (niepanchongsheng) said : #5

I'm sorry, after I modified the max number of particles for each event, the problem is still there.

"
mcfio_NextEvent: Error Repositioning stream

     STDXRD: unrecognized status - stop

"

This was the message appeared in the hep2lhe.log file.

Thanks

Hi Looks like this is hardcoded in a lot of place,

src/ME2pythia.f: PARAMETER (NMXHEP=4000)
src/ME2pythia.f: PARAMETER (NMXHEP=4000)
src/ME2pythia.f: PARAMETER (NMXHEP=4000)
src/getjet.f: PARAMETER (NMXHEP=4000)
src/getjet.f: PARAMETER (NMXHEP=4000)
src/hep2lhe.f: COMMON/PYJETS/N,NPAD,K(4000,5),P(4000,5),V(4000,5)
src/hep2lhe.f: PARAMETER (NMXHEP=4000)
src/pythia.f: COMMON/PYJETS/N,NPAD,K(4000,5),P(4000,5),V(4000,5)
src/pythia.f: PARAMETER (NMXHEP=4000)

and in a lot of file of this directory:
libraries/pylib/src/

Did you change all of them as well?

teddym (niepanchongsheng) said : #7

Hi~
     I think I've found the problems. It has nothing to do with the number defined by pythia itself, but with the stdhep file:

In the directory

./pythia-pgs/libraries/PGS4/src/stdhep-dir/mcfio/src

The file " mcfio_Direct.c " contains the error info which I've seen in the hep2lhe.log file. ( Line 529 )

It uses "fseeko(FILE *stream, off_t offset, int fromwhere)".

 The problem perhaps is related to the second argument "off_t offset ". My pythia.hep is too big (larger than 2GB), so at this step the function fseeko return -1 instead of 0, and print the error message "mcfio_NextEvent: Error Repositioning stream"

So I think it may also affect the PGS-running (I have not used it ) when the pythia.hep file is too large.

However, I do not know how to solve such problem.

Teddy

Hi,

Which version of pythia-pgs are you using?

I fought that this kind of problem was fixed in the latest version.

Cheers,

Olivier

On Mar 14, 2014, at 5:46 AM, teddym <email address hidden> wrote:

> Question #244320 on MadGraph5_aMC@NLO changed:
> https://answers.launchpad.net/mg5amcnlo/+question/244320
>
> Status: Answered => Open
>
> teddym is still having a problem:
> Hi~
> I think I've found the problems. It has nothing to do with the number defined by pythia itself, but with the stdhep file:
>
> In the directory
>
> ./pythia-pgs/libraries/PGS4/src/stdhep-dir/mcfio/src
>
> The file " mcfio_Direct.c " contains the error info which I've seen in
> the hep2lhe.log file. ( Line 529 )
>
> It uses "fseeko(FILE *stream, off_t offset, int fromwhere)".
>
> The problem perhaps is related to the second argument "off_t offset ".
> My pythia.hep is too big (larger than 2GB), so at this step the function
> fseeko return -1 instead of 0, and print the error message
> "mcfio_NextEvent: Error Repositioning stream"
>
> So I think it may also affect the PGS-running (I have not used it ) when
> the pythia.hep file is too large.
>
> However, I do not know how to solve such problem.
>
> Teddy
>
> --
> You received this question notification because you are an answer
> contact for MadGraph5_aMC@NLO.

teddym (niepanchongsheng) said : #9

The version of pythia-pgs on my computer is 2.2.1

I have just reinstalled it recently, for I've messed up the source files.

Thanks

Teddy

Pavel Demin (pavel-demin) said : #10

Normally, on the 64-bit systems fseeko returns a result that is 64-bit.

For 32-bit systems, the following compilation flag should be added:

-D_FILE_OFFSET_BITS=64

Could you, please provide more information about your OS: name, version 32 or 64 bit.

Thanks,

Pavel

teddym (niepanchongsheng) said : #11

Hi~
     It is Ubuntu 12.04 - 64bit

Thanks!

Teddy

Pavel Demin (pavel-demin) said : #12

Thanks for the information about your OS.

I'll try to reproduce this problem on a similar system.

Actually, I've replaced xdr_getpos/xdr_setpos with ftello/fseeko in mcfio_Direct.c and other files to fix the problem with files larger than 4GB:

https://bugs.launchpad.net/mg5amcnlo/+bug/1218842

Hi Pavel,

So actually the current version of pythia-pgs still use xdr_getpos.
So I've retry to apply the patch that you provide in the sus-mentionned bug report.
and actually those are already the file present in the current pythia-pgs package.
So looks like that you tar.gz the original files instead of those with your modification.

Would you be able to recreate the file?

Cheers,

Olivier

Pavel Demin (pavel-demin) said : #14

Hi,

I've modified only the files that are used by the pythia-pgs interface.

mcf_evt_xdr.c and mcfio_Sequential.c are not used by the pythia-pgs interface.

So, there is no need to patch them.

Cheers,

Pavel

Pavel Demin (pavel-demin) said : #15

I've just checked the line 529 in mcfio_Direct.c.

I'd suggest to change the type of nextLocator (line 83 in mcf_xdr.h) from int to off_t.

You can just download new version of this file from

http://cp3.irmp.ucl.ac.be/downloads/mcf_xdr.h

Here are the commands to apply this patch for MG5:

cd pythia-pgs/libraries/PGS4/src/stdhep-dir/mcfio/src
rm mcf_xdr.h
wget http://cp3.irmp.ucl.ac.be/downloads/mcf_xdr.h

and here are the commands to apply this patch for MG5_aMC:

cd vendor/StdHEP/mcfio/src
rm mcf_xdr.h
wget http://cp3.irmp.ucl.ac.be/downloads/mcf_xdr.h

Thanks Pavel,

I have made the change to both codes,

Thanks ,

Olivier
On Mar 19, 2014, at 2:51 PM, Pavel Demin <email address hidden> wrote:

> Question #244320 on MadGraph5_aMC@NLO changed:
> https://answers.launchpad.net/mg5amcnlo/+question/244320
>
> Pavel Demin proposed the following answer:
> I've just checked the line 529 in mcfio_Direct.c.
>
> I'd suggest to change the type of nextLocator (line 83 in mcf_xdr.h)
> from int to off_t.
>
> You can just download new version of this file from
>
> http://cp3.irmp.ucl.ac.be/downloads/mcf_xdr.h
>
> Here are the commands to apply this patch for MG5:
>
> cd pythia-pgs/libraries/PGS4/src/stdhep-dir/mcfio/src
> rm mcf_xdr.h
> wget http://cp3.irmp.ucl.ac.be/downloads/mcf_xdr.h
>
> and here are the commands to apply this patch for MG5_aMC:
>
> cd vendor/StdHEP/mcfio/src
> rm mcf_xdr.h
> wget http://cp3.irmp.ucl.ac.be/downloads/mcf_xdr.h
>
> --
> You received this question notification because you are an answer
> contact for MadGraph5_aMC@NLO.

Keith Pedersen (kpeders1) said : #17

Pavel,

I was getting the same error as you before you posted this fix; Pythia could generate a large HEP file, but PGS pooped out while reading it (for me it read 72199 events without error, then died).

I applied the newest patch (mcf_xdr.h), but now PGS stops after only 99 events (on seperate runs of 100 K events for pp>jj and pp>jjj). The new error is:

mcfio_NextEvent: Error Repositioning stream

Did you encounter anything similar in your trials?

I also noticed that there a lot of errors in my "/pythia-pgs/libraries/PGS4/src/stdhep-dir/log.mcfio" complaining about type conversions.

Keith

teddym (niepanchongsheng) said : #18

Unfortunately, after I replace those files, the error is still there when I handle with a .hep file larger than 2G
And it does affect the running of pgs. How could I fix it?

Then I guess the only practical way is to limit your number of event by run and run multiple times.
that's the idea of the multi-run actually.

The command is
./bin/madevent multi_run X
where X is the number of times that you want to run sequentially.

for more information on that command
type
./bin/madevent
this open a new shell where you can type
help multi_run

Cheers,

Olivier

teddym (niepanchongsheng) said : #20

Hi:
     Maybe this is the only method now.
    Thank you very much.

Ted

Doyoun Kim (abistp00) said : #21

I have also the similar problem, while my .hep file size is just 214MB.
In the tag_1_pgs.log file, the message says:
  1 --------------------------------------
  2 | PGS 4 - release 120611 |
  3 --------------------------------------
  4 mcfio_NextEvent: Error Repositioning stream
  5 Now at event number 10 of 10002 (Triggered on: 10 )
  6 Now at event number 20 of 10002 (Triggered on: 20 )
  7 Now at event number 30 of 10002 (Triggered on: 30 )
  8 Now at event number 40 of 10002 (Triggered on: 40 )
  9 Now at event number 50 of 10002 (Triggered on: 50 )
 10 Now at event number 60 of 10002 (Triggered on: 60 )
 11 Now at event number 70 of 10002 (Triggered on: 70 )
 12 Now at event number 80 of 10002 (Triggered on: 80 )
 13 Now at event number 90 of 10002 (Triggered on: 90 )
 14 I will merge non-isolated muons with jets...
 15 Thank you for using the olympics output cleaner.

Please note that I have generated 10K events p p > t1 t1~ in the mssm model. This happens also for the sm p p > t t~ case with 10K events. I am sure this is only a problem with PGS related routine, "mcfio_Direct.c", since interestingly, Delphes gives the correct result.

Just for my study, I wanted to compare PGS and Delphes results based on the lhco files. I put both of PGS and Delphes cards in the Template/Common/Cards dir and ran 10K events. While PGS gives only "99 events" (common number in various posts), Delphes has exactly "10K events". Ah, please see above that the PGS log file still claims that the total number of events are 10002!

I have already tried "-D_FILE_OFFSET_BITS=64" option in various ways which are suggested in other posts, but without success. My system is mac osx 10.9.2 using clang from the latest version of Xcode, and gfortran from homebrew.

I wanted to compare PGS and Delphes results for the same event generation, and fortunately I've already done it such that I decided to go for Delphes. So this thing won't affect my study any more.

Ah, two days ago, when I did the same thing for t t~ in sm and t1 t1~ in mssm, PGS and Delphes both gave 10K events without any problem. This is why I have compared PGS and Delphes results already, but I don't understand why now I can't. All I have done is just re-installation of MG5/pythia-pgs/delphes packages.

Doyoun Kim (abistp00) said : #22

Let me add this.

Subroutine pgs_user_trig in pythia-pgs/libraries/PGS4/examples/ is responsible for pgs log file above.

1104 ievent = ievent + 1
1105 if(trigword.ne.0) ntrigged = ntrigged + 1
1106
1107 if (ievent.lt.100.and.mod(ievent,10).eq.0) then
1108 write(6,*) 'Now at event number', ievent, ' of', nevpgs,
1109 . ' (Triggered on:', ntrigged, ')'
1110 write(pgs_log_unit,*)
1111 . 'Now at event number', ievent, ' of', nevpgs,
1112 . ' (Triggered on:', ntrigged, ')'
1113 else if (ievent.lt.1000.and.mod(ievent,100).eq.0) then
1114 write(6,*) 'Now at event number', ievent, ' of', nevpgs,
1115 . ' (Triggered on:', ntrigged, ')'
1116 write(pgs_log_unit,*)
1117 . 'Now at event number', ievent, ' of', nevpgs,
1118 . ' (Triggered on:', ntrigged, ')'
1119 else if (mod(ievent,1000).eq.0) then
1120 write(6,*) 'Now at event number', ievent, ' of', nevpgs,
1121 . ' (Triggered on:', ntrigged, ')'
1122 write(pgs_log_unit,*)
1123 . 'Now at event number', ievent, ' of', nevpgs,
1124 . ' (Triggered on:', ntrigged, ')'
1125 end if
1126
1127 return
1128 end

And because of some reason this subroutine stops being called so that ievent cannot go beyond 100.

teddym (niepanchongsheng) said : #23

Hi:

Aha after reinstalling the pythia-pgs package, the problem becomes worse. The PGS could only read 866 events out of 10000 events for my test process p p > t t~ with both top decay hadronic. The .hep file is about 530MB even not larger than 2GB. Previously only are the .hep file larger than 2G, there would be such problem.

Is there any change in the package pythia-pgs?

Ted

teddym (niepanchongsheng) said : #24

I'm sorry, the PGS only read no more than 100 events with about 866 objects the log file is following:

_______________________________________________________________________________
 Now at event number 10 of 10002 (Triggered on: 10 )
 Now at event number 20 of 10002 (Triggered on: 20 )
 Now at event number 30 of 10002 (Triggered on: 30 )
 Now at event number 40 of 10002 (Triggered on: 40 )
 Now at event number 50 of 10002 (Triggered on: 50 )
 Now at event number 60 of 10002 (Triggered on: 60 )
 Now at event number 70 of 10002 (Triggered on: 70 )
 Now at event number 80 of 10002 (Triggered on: 80 )
 Now at event number 90 of 10002 (Triggered on: 90 )

     STDXRD: unrecognized status - stop

This problem may not be ignored by setting the event number not too much.

Doyoun Kim (abistp00) said : #25

Yes, it is why I have said "99 events" are "common number in various posts". Whatever you generate in any models, 99 events are recorded in the LHE file. But std hep file and Delphes-generated LHCO file seems fine.

teddym (niepanchongsheng) said : #26

Hi:
   I found a solution to these problems!

   If you have installed ExRootAnalysis in the MadGraph then you could copy all the files in
 MG-directory/ExRootAnalysis/mcfio/
to
/MG-directory/pythia-pgs/libraries/PGS4/src/stdhep-dir/mcfio/src/
replace all the files with the same name, then
go to /MG-directory/pythia-pgs/ and do

make clean
make

Now everything works well, it even can deal with the .hep file larger than 2GB.

Aha~~ So great.

I don't know what's the difference between the files in ExRootAnalysis and those in pythia-pgs, but it works!

Doyoun Kim (abistp00) said : #27

Excellent! On both macosx 10.9 and CentOS, it works well.
Thanks!

Pavel Demin (pavel-demin) said : #28

I'd like to summarize the current state of the problem.

By copying ExRootAnalysis/mcfio to stdhep-dir/mcfio/src you return to the original version of the mcfio/stdhep library.

This version can't write files greater than 4GB.

Replacing xdr_getpos/xdr_setpos with ftello/fseeko in mcfio_Direct.c and other files fixes the problem with writing files larger than 4GB but breaks reading.

The patched mcfio/stdhep version that can write files larger than 4GB works with Delphes3 and MadAnalysis5 but does not work with PGS/hep2lhe/MadAnalysis4.

The original version works with PGS/hep2lhe/MadAnalysis4 but can't write files larger than 4GB.

Possible solutions:
 - try to find a better patch for the mcfio/stdhep library
 - keep current patched version of the mcfio/stdhep library and definitely replace PGS/hep2lhe/MadAnalysis4 with Delphes3/MadAnalysis5
 - replace the mcfio/stdhep library with a more modern one (stdhep from Delphes3, HepMC, ProMC, ROOT, etc)

TMartin (tmartin-4) said : #29

I am having a similar problem, but one that is not fixed by the solution posted here.

For certain parameter values in the MSSM, I am getting ~1% of events passing through Pythia. So I end up with fewer events than generated.

I thought it might have been random, but it does appear to be for very specific values of the parameter space, because repeated runs give the same/similar results, hanging the number of events generated in MadGraph does not improve the issue, and reinstalling from scratch also does not improve the issue.

Pavel Demin (pavel-demin) said : #30

Hi all,

I think I've found how to solve the "99 events" problem. Only to test my solution I need to reproduce this problem.

Could someone, please provide an exact (and preferable short) list of commands to generate a stdhep file and to run PGS and/or hep2lhe?

Regards,

Pavel

Doyoun Kim (abistp00) said : #31

I think mine is one of shortest.

First I set up the package as follows:
1. Untar mg5_amc
2. run mg5/mg5_amc interaction mode then "install pythia-pgs" and "install Delphes."
3. copy Template/LO/Card/pythia_card_dedault.dat to Template/LO/Card/pythia_card.dat
    and Template/Common/Card/pgs_card_dedault.dat Template/Common/Card/pgs_card.dat

Then in the main directory,
$ ./bin/mg5_amc proc_card.dat

That's all.

Pavel Demin (pavel-demin) said : #32

Great! Thanks! I'll try it right now.

Pavel Demin (pavel-demin) said : #33

I've finally made a patch that solves the problem with files larger than 4GB and works with hep2lhe and PGS.

This patch is available in 2.1.2.

More details about this patch are available at

https://bugs.launchpad.net/mg5amcnlo/+bug/1218842

Fabrizio Nesti (fnesti) said : #34

Hello, sorry to revive an old thread.
This issue is present even with last mg5 (2.2.2).

Steps to reproduce the issue:

  - untar MG5_aMC_v2.2.2.tar.gz
  - install pythia-pgs
  - generate p p > z z
  - launch (with 100000 events and pythia on)

the result is an empty lhe (and btw also empty Delphes)

 933337691 gen 29 16:19 tag_1_pythia_events.hep
             5755 gen 29 16:19 tag_1_pythia_events.lhe.gz

and by running manually hep2lhe on the unzipped file, one gets the error as above " STDXRD: unrecognized status - stop"

The unzipped hep file is 2.28G.

With a previous version (2.2.1) everything works fine, apparently, even with 500k events and filesizes of 20GB...

What is the situation now?
Thanks for your help!

Fabrizio

Fabrizio Nesti (fnesti) said : #35

System specs

Ubuntu 14.04.1 LTS (GNU/Linux 3.13.0-44-generic i686)

8 cores - for instance:

processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 60
model name : Intel(R) Core(TM) i7-4770 CPU @ 3.40GHz
stepping : 3
microcode : 0x1a
cpu MHz : 800.000
cache size : 8192 KB
physical id : 0
siblings : 8
core id : 0
cpu cores : 4
apicid : 0
initial apicid : 0
fdiv_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm ida arat epb xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm
bogomips : 6784.76
clflush size : 64
cache_alignment : 64
address sizes : 39 bits physical, 48 bits virtual

Can you try if the following patch helps?

=== modified file 'madgraph/various/misc.py'
--- madgraph/various/misc.py 2014-11-14 17:46:50 +0000
+++ madgraph/various/misc.py 2015-01-24 18:44:58 +0000
@@ -736,6 +736,8 @@
     if os.path.getsize(path) > 1e9:
         call(['gzip', '-f', path])
         if stdout:
+ if not stdout.endswith(".gz"):
+ stdout = "%s.gz" % stdout
             shutil.move('%s.gz' % path, stdout)
         return

Cheers,

Olivier
On 29 Jan 2015, at 18:21, Fabrizio Nesti <email address hidden> wrote:

> Question #244320 on MadGraph5_aMC@NLO changed:
> https://answers.launchpad.net/mg5amcnlo/+question/244320
>
> Fabrizio Nesti posted a new comment:
> System specs
>
> Ubuntu 14.04.1 LTS (GNU/Linux 3.13.0-44-generic i686)
>
> 8 cores - for instance:
>
> processor : 0
> vendor_id : GenuineIntel
> cpu family : 6
> model : 60
> model name : Intel(R) Core(TM) i7-4770 CPU @ 3.40GHz
> stepping : 3
> microcode : 0x1a
> cpu MHz : 800.000
> cache size : 8192 KB
> physical id : 0
> siblings : 8
> core id : 0
> cpu cores : 4
> apicid : 0
> initial apicid : 0
> fdiv_bug : no
> f00f_bug : no
> coma_bug : no
> fpu : yes
> fpu_exception : yes
> cpuid level : 13
> wp : yes
> flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm ida arat epb xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm
> bogomips : 6784.76
> clflush size : 64
> cache_alignment : 64
> address sizes : 39 bits physical, 48 bits virtual
>
> --
> You received this question notification because you are an answer
> contact for MadGraph5_aMC@NLO.

Fabrizio Nesti (fnesti) said : #37

Hi Olivier - thanks. That fix is good, because it adds the .gz suffix which indeed was missing (I think it fixes an other problem in running delphes alone later from madevent)

But it does not solve the above problem. E.g. the hep2lhe.log still shows the same issue:
          ********************************************************
                  STDHEP version 5.04.01 - Aug. 29, 2005
          ********************************************************
 STDXROPEN: successfully opened input stream 1
          title: PYTHIA file
          date: Thu Jan 29 23:52:20 2015
                             0 events
                             8 blocks per event
     STDXRD: unrecognized status - stop
 Using GETJET for jet finding (ijetalg=1)
 Reading pythia input card
 Generating all events
-------------------------------------------------------------------------------------------------------

Note, even unzipping the hep fie and running hep2lhe gives the above behavior and empty output....

Sorry,

Then I have no idea, i have test your example in my laptop and this is working fine (I actually use 2.2.3 which is not yet release).

The two potential workaround is to use the file
madgraph/various/misc.py from 2.2.1 (since that one was working)
or to use the multi_run method to avoid to have large hep file.

Cheers,

Olivier

On 29 Jan 2015, at 23:01, Fabrizio Nesti <email address hidden> wrote:

> Question #244320 on MadGraph5_aMC@NLO changed:
> https://answers.launchpad.net/mg5amcnlo/+question/244320
>
> Fabrizio Nesti posted a new comment:
> Hi Olivier - thanks. That fix is good, because it adds the .gz suffix
> which indeed was missing (I think it fixes an other problem in running
> delphes alone later from madevent)
>
> But it does not solve the above problem. E.g. the hep2lhe.log still shows the same issue:
> ********************************************************
> STDHEP version 5.04.01 - Aug. 29, 2005
> ********************************************************
> STDXROPEN: successfully opened input stream 1
> title: PYTHIA file
> date: Thu Jan 29 23:52:20 2015
> 0 events
> 8 blocks per event
> STDXRD: unrecognized status - stop
> Using GETJET for jet finding (ijetalg=1)
> Reading pythia input card
> Generating all events
> -------------------------------------------------------------------------------------------------------
>
> Note, even unzipping the hep fie and running hep2lhe gives the above
> behavior and empty output....
>
> --
> You received this question notification because you are an answer
> contact for MadGraph5_aMC@NLO.

Fabrizio Nesti (fnesti) said : #39

Oh, I got the problem - embarrassing - the system above was 32 bit (i686) (!). Apologies.

I confirm that all versions are ok with large even numbers on 64bit.

best,
Fabrizio

Can you help with this problem?

Provide an answer of your own, or ask teddym for more information if necessary.

To post a message you must log in.