Unable to handle Herwig++ events

[holdom]

Herwig++ 2.6.0
ThePEG 1.8.0
HepMC 2.06.09
Delphes 2.03

Delphes handles events which are showered but not hadronized, or hadronized but not decayed.

But it does not handle events which are both hadronized and decayed.

It announces that the "Total number of events to run:" is 0 or 1

I attach a file with 20 events.

[holdom]

The file has 10 events.

[Pavel Demin]

Could you also upload an example of file that works (showered or hadronized)?

[Sourav Mandal]

I presume this 10 event fragment you attached doesn't work either? One possibility is that the HepMC file has illegal floating point numbers, which occurred for a colleague of mine using a recent Herwig++ toolchain as you are. I see several coordinates in the file with exponents beyond 308, which is the limit for double-precision floats.

Try this Perl script which replaces floating point numbers of magnitude less than 1e-300 with zero:

while(<>) {
	chomp;
	my @line = split ' ';
	my @newline = ();
	foreach $token (@line) {
		if($token =~ /e-/ && abs($token) < 1e-300) {
			push(@newline, "0.0e+0");
		}
		else {
			push(@newline, $token);
		}
	}
	print "@newline\n";
	
}

Invoke with

# cat LHC-Powerheg.hepmc | perl script.pl > new.hepmc

and see if you have a better result running Delphes on the new .hepmc file.

I get around this problem by modifying Delphes to use my system HepMC library rather than the included one.

[Sourav Mandal]

HepMC files with small floats truncated to zero

[Pavel Demin]

Does your system HepMC library deals better with illegal floating point numbers? What version is it?

[Sourav Mandal]

Pavel,

It does seem so, as I had no problem running holdom's .hepmc file fragment, nor my those of my colleague who had the same issue.

I'm using HepMC 2.06.03, which is the latest "stable" version provided by Gentoo Linux.

[Pavel Demin]

The strange thing is that I can't reproduce the problem. Here is what I'm doing:

mkdir test
cd test

wget --no-check-certificate https://cp3.irmp.ucl.ac.be/projects/delphes/raw-attachment/wiki/WikiStart/Delphes_V_2.0.3.tar.gz
wget --no-check-certificate https://cp3.irmp.ucl.ac.be/projects/delphes/raw-attachment/ticket/125/LHC-Powheg.hepmc

tar -zxf Delphes_V_2.0.3.tar.gz
cd Delphes_V_2.0.3

export ROOTSYS=/nfs/soft/root/root_v5.34.01-sl5_amd64_gcc41
export PATH=$ROOTSYS/bin:$PATH
export LD_LIBRARY_PATH=$ROOTSYS/lib:$LD_LIBRARY_PATH

./configure
make

ls ../LHC-Powheg.hepmc > LHC-Powheg.list
./Delphes LHC-Powheg.list LHC-Powheg.root data/DetectorCard_CMS.dat

[holdom]

Thanks smandal,

Your script does the trick to handle that 10 event file.

I was curious about having Delphes use my installed hepmc instead, as you suggest. I naively typed
./configure --help
This deleted all my binaries...

I am also curious about using my more up to date installed fastjet.

[Sourav Mandal]

pavel,

I agree we're missing something. You're using HepMC 2.06.06 included in Delphes, and I'm using HepMC 2.06.03 installed on my system, and we're both able to read holdom's output. But holdom can't read his own output using the same Delphes setup (presumably) as you.

Then the issue may be in some system library. I'm using gcc-4.5.3 and glibc-2.14.1 on one machine, and gcc-4.4.4 and glibc-2.12.2 on another. How about you guys?

*

holdom,

You can hack the genMakefile.tcl file to accomplish. I can send you a patch after finishing my current work.

[holdom]

I am running on an up-to-date Mac with gcc 4.2.1.

[Sourav Mandal]

FWIW, my colleague with the same bug is also running an up-to-date Xcode setup with gcc-4.2.1

[Pavel Demin]

Could you run the following test on your system?

/*
commands to compile and run:
  g++ -o test test.cpp
  ./test
*/

#include <stdio.h>
#include <iostream>
#include <sstream>
#include <string>

using namespace std;

int main ()
{
  char test[] = "2.8878950987394353e-314";
  string buffer = test;

  istringstream bufferStream;

  double result;
  int rc;

  rc = sscanf(test, "%lf", &result);
  printf("result 1 -> %g\n", result);
  printf("rc 1 -> %d\n", rc);

  bufferStream.clear();
  bufferStream.str(buffer);
  
  rc = (bufferStream >> result) != 0;

  cout << "result 2 -> " << result << endl;
  cout << "rc 2 -> " << rc << endl;
  
  return 0;
}

[Sourav Mandal]

The output on my Linux setup:

result 1 -> 2.8879e-314
rc 1 -> 1
result 2 -> 2.8879e-314
rc 2 -> 1

which I believe is as expected. BTW, I had to add "-lstdc++" to the compiler commandline to link the executable successfully ...

[holdom]

I obtain

result 1 -> 2.8879e-314
rc 1 -> 1
result 2 -> 2.8879e-314
rc 2 -> 0

By the way, the original problem went away when I compiled Delphes with a newer gcc obtained from macports.
In either case your test gave the above.

[Pavel Demin]

Thanks for running this test. It looks like gcc handles numbers beyond the limit for double-precision floats. On Linux, I obtained the same results for 3 different gcc versions: 3.4, 4.1 and 4.4.

The gcc manual mentions an option called -ffloat-store that prevents undesirable excess precision:

​https://developer.apple.com/library/mac/#documentation/Darwin/Reference/ManPages/man1/gcc.1.html

May be Apple include this option in their default gcc configuration.

[cakir]

I think I also have more or less same error and could not figure it out what is the problem. I used the same procedure above and everything looks similar in my case but it does not read hepmc ascii file properly. It quits with
HepMC::Version
ERROR: File format not identified -- Exiting...

[Pavel Demin]

Could you send us the commands that you are running and first ~10 lines of your HepMC file?

[favereau]

any news ?

[Pavel Demin]

Delphes 3 returns the same error on MacOSX and on Linux when it finds the illegal floating point numbers:

** ERROR: invalid vertex format

** Exiting...