bugHepMC - a C++ Event Record for Monte Carlo Generators - Bugs: bug #38173, Problems with Alpgen W+0 parton...

 
 
Show feedback again

You are not allowed to post comments on this tracker with your current authentication level.

bug #38173: Problems with Alpgen W+0 parton events in csc_evgen08_trf.py 14.1.0.3

Submitted by:  Wouter Verkerke <verkerke>
Submitted on:  2008-06-24 16:13  
 
Category: NoneSeverity: 3 - Normal
Priority: 5 - NormalItem Group: None
Status: FixedPrivacy: Public
Assigned to: Lynn Garren <garren>Open/Closed: Closed

(Jump to the original submission Jump to the original submission)

2008-07-03 22:05, comment #12:

These pages are for bug reports and comments directly related to HepMC, not to Atlas builds. Discussion of this bug is now locked.

Lynn Garren <garren>
Project AdministratorIn charge of this item.
2008-07-03 21:55, comment #11:

Dear Andreu,

There was a report about the update: HepMC 2.03.09 is in 14.2.10 and 14.1.0.4 (see #38282). I am not sure if it is in 14.1.0.4, I am checking with Judith. Input file, jobOption is actually already attached in this page by Wouter (at the bottom of the page).
- Osamu

Osamu Jinnouchi <osamu>
2008-07-03 19:25, comment #10:

Dear Jon,

Thanks. I apologize. I will check with them.

Best regards, Andreu

Andreu Pacheco Pages <pacheco>
2008-07-03 19:13, comment #9:

Hi Andreu,

I think your request needs to be directed at Wouter or Osamu - Lynn is a HepMC developer, not ATLAS.

Cheers,
Jon

Jon Butterworth <jmb>
2008-07-03 19:10, comment #8:

Dear Lynn,

Can you provide the transform and the input files needed to reproduce the bug? I would like to test in the nightlies.

Best regards, Andreu

Andreu Pacheco Pages <pacheco>
2008-06-25 06:41, comment #7:

This fix is now available in HepMC 2.03.09.

Lynn Garren <garren>
Project AdministratorIn charge of this item.
2008-06-24 16:13, comment #6:

This item has been reassigned from the project Atlas Generators bugs tracker to your tracker.

The original report is still available at bugs #37994

Following are the information included in the original report:

  • [field #0] Item ID: 37994
  • [field #1] Group ID: 145
  • [field #2] Open/Closed: Open
  • [field #3] Severity: 3 - Normal
  • [field #4] Privacy: Public
  • [field #8] : Unknown bugs Field Display Type
  • [field #9] Category: AlpGen_i
  • [field #10] Submitted by: verkerke
  • [field #11] Assigned to: jmb
  • [field #12] Submitted on: 2008-06-19 13:25
  • [field #13] Summary: Problems with Alpgen W+0 parton events in csc_evgen08_trf.py 14.1.0.3
  • [field #14] Original Submission: Hi,

Running csc_evgen08_trf.py on alpgen W+0 parton events
crashes using either AtlasProduction 14.1.0.3 or
nightly 14.1.0.Y rel_3.

The crash is in PHOTOS, but this is just a symptom of
something wrong with the event structure (quoting mail
from Borut here)

-----------------

here is what I found:

-hwdtau indeed calls photos and it should not - someone please comment out the
lines or we get double-counting.

-If I comment out the lines the crash disappears if I exclude Photos_i.

-However if I now switch Photos on we get a crash (infinite loop) because the
HepMC record of Alpgen is crap:

From PrintMC:

24 2101 ud 3 -20 0 ( +0,
25 24 W++ 155 -1 -22 (
26 -11 e-+ 123 -22 -23
27 12 nu(e)0 124 0 -24
28 -11 e-+ 1 -23 0
29 12 nu(e)0 1 -24 0

as you can see the neutrino (27) has no parent, which confuses photos to no end
(it should have -22 as electron(26) );
even if the thing would not run amok we would get no photons from W decays!

Something is amiss with either ALPGEN input, alpgen reading or HepMC conversion..

---------------

How to reproduce (use either 14.1.0.3 or 14.1.0.Y rel_3 )

csc_evgen08_trf.py 107680 1 500 12345 MC8.107680.AlpgenJimmyWenuNp0_pt20.py evgen.pool.root NONE NONE alpgen.107680.WenuNp0.pt20._00001.tar.gz

the needed files

jobOptions file: MC8.107680.AlpgenJimmyWenuNp0_pt20.py
input tar ball: alpgen.107680.WenuNp0.pt20._00001.tar.gz

are attached to this bug report

Wouter

  • [field #16] Item Group: Run-time Error or Warning
  • [field #17] Status: None
  • [field #18] Component Version: None
  • [field #19] Operating System: None
  • [field #20] Reproducibility: None
  • [field #21] Size (loc): None
  • [field #22] Fixed Release: None
  • [field #23] Planned Release: None
  • [field #24] Effort: 0.00
  • [field #28] Priority: 5 - Normal
  • [field #31] Percent Complete: 0%
  • [field #33] Release: None
  • [field #36] Originator Email: -unavailable-
  • [field #58] Custom Select Box #1: None
  • [field #59] Custom Select Box #2: None
  • [field #60] Custom Select Box #3: None
  • [field #61] Custom Select Box #4: None
  • [field #62] Custom Select Box #5: None
  • [field #63] Custom Select Box #6: None
  • [field #64] Custom Select Box #7: None
  • [field #65] Custom Select Box #8: None
  • [field #66] Custom Select Box #9: None
  • [field #67] Custom Select Box #10: None
Jon Butterworth <jmb>
2008-06-24 13:32, comment #5:

Thanks Borut. If you email me the fixed version, I will submit an urgent bug fix request via Genser, and we will see.

Jon Butterworth <jmb>
2008-06-24 13:29, comment #4:

Ok, I believe I found the culprit:

The problem is that IO_HERWIG was written before HWHGUP (reading external files) and not updated enough... The resonances appear through HWHGUP with status code 155 ('beam spectator', strange but possibly an unused/adequate code) whereas the exceptions in IO_HERWIG were only for internal processes.

it's the lines:

// When the direct descendants of the hard process are hadrons,
// then the 2nd child contains color flow information, and so
// we zero it.
// However, if the direct descendant is status=195, then it is
// a non-hadron, and so the 2nd child does contain real mother
// daughter relationships. ( particularly relevant for H->WW,
// April 18, 2003 )
if ( HEPEVT_Wrapper::status(i) != 195) {
HEPEVT_Wrapper::set_children(i,HEPEVT_Wrapper::first_child(i),0);
}
}
in IO_HERWIG.cc
which looses e.g. the neutrino from W (setting second child to zero).

I think this mod was still made by Matt (I did not do it).

The problem is that HWHGUP sets resonances to status 155 and due to above the following happens:
-if the hard vertex (stat 120) points directly to these resonances (and is a resonance, e.g. W) they loose the second daughter (e.g. W+0j).
-if the hard vertex (stat 120) has multiple descendants (e.g. W+1j) it's not a particle and the descendants are kept.

It's easy to fix in IO_HERWIG, extending the 'if':
if ( HEPEVT_Wrapper::status(i) != 195 && HEPEVT_Wrapper::status(i) != 155 ) {

But I don't have a guesstimate on how long the propagation to HepMC will take..

There is also another thingy that is basically HWHGUP inconsistency: hard (120) W entry is there and points to the (155) W but the latter one gives the incoming quarks as parents instead of the (120) W.. issue only for external processes of W+0j type - not a problem in prod., just wrong navigation (causes (120) W to point to nowhere..

I tested the fixes and they seem to work. It is however non-trivial to repeat the setup (I can give instructions..)

I can give you the fixed IO_HERWIG upon request..

Best,

Borut

Borut Paul Kersevan <borut>
2008-06-24 12:19, comment #3:

Hi all,
Copied discussion from mail thread - can we use this ticket for future dicussion please?

Also added Cano re the HepMC issue.

If this is a HepMC issue, do we know was it fixed in the old ATLAS internal HepMC or is it really a new bug? And Cano can you look into it and we can talk to Alberto and the Genser people about an urgent fix?

Thanks,
Jon


Hi Osamu,

hmm, the bug seems to be indeed in IO_HERWIG of HepMC. The easiest thing to do would be to ask Vladimir to make a fix in Photos_i which anticipates such exceptions (and get HepMC fixed.. )

Best,

Borut

Osamu Jinnouchi wrote:

> > Hi all,
> >
> > Here is my observation.
> >
> > - I could reproduce the same situation with 14.1.0.3 with
> > AlpGen_i-00-00-28
> > EvgenJobTransforms-00-06-08
> > Herwig_i-00-02-37
> > Photos_i-01-00-47 (new)
> >
> > - the symptom (Photos in infinite loop) is equivalent to the
> > collapse of HepMC recode (enu has no parent), so I checked
> > this other versions.
> > 13.0.40.5 -- same
> > 12.0.7 -- same
> > 11.0.42 -- (I could not confirm with PrintMC but Herwig event
> > record output shows the same symptom which other release shows
> > for W+0j process)
> > ==> so the first conclusions
> > this is not new (nothing to do with HepMC migration, Alpgen/Herwig
> > interface change, )
> >
> > - between W0j and W1j, there is significant difference in event records
> > which can be checked in three ways.
> >
> > *** PrintMC (as already shown by Borut)--> nu(e)0 has no parent
> > //////////////////////////////////////////////////////////////////////
> > W0j
> > 19 -24 W+- 155 -1 -16
> > (+1.07e+03,+1.22e+04,+3.58e+05,+3.67e+05, 8.04e+04)
> > 20 11 e-- 123 -16 -17
> > (+1.28e+04,+4.04e+04,+2.82e+05,+2.85e+05, 0.511)
> > 21 -12 nu(e)0 124 0 -18
> > (-1.18e+04,-2.82e+04,+7.63e+04,+8.22e+04, 0)
> > 22 11 e-- 1 -17 0
> > (+1.28e+04,+4.04e+04,+2.82e+05,+2.85e+05, 0.511)
> > 23 -12 nu(e)0 1 -18 0
> > (-1.18e+04,-2.82e+04,+7.63e+04,+8.22e+04, 0)
> > W1j
> > 27 24 W++ 3 -6 -25
> > (+7.88e+03,+2.54e+04,+9.36e+04,+1.26e+05, 8.04e+04)
> > 28 24 W++ 155 -25 -26
> > (+7.88e+03,+2.54e+04,+9.36e+04,+1.26e+05, 8.04e+04)
> > 29 -11 e-+ 123 -26 -27
> > (-2.22e+04,+2.59e+04, +7.4e+03,+3.49e+04, 0.511)
> > 30 12 nu(e)0 124 -26 -28
> > (+3.01e+04, -427,+8.62e+04,+9.13e+04, 0)
> > 31 -11 e-+ 1 -27 0
> > (-2.22e+04,+2.59e+04, +7.4e+03,+3.49e+04, 0.511)
> > 32 12 nu(e)0 1 -28 0
> > (+3.01e+04, -427,+8.62e+04,+9.13e+04, 0)
> >
> > *** Herwig Event record
> > /////////////////////////////////////////////////////////////////////////
> > W0j
> > ---HARD SUBPROCESS---
> >
> > IHEP ID IDPDG IST MO1 MO2 DA1 DA2 P-X P-Y P-Z
> > ENERGY MASS V-X V-Y V-Z V-C*T
> > 4 SQRK 3 121 6 5 7 5 0.00 0.00 362.8
> > 362.8 0.00 0.000E+00 0.000E+00 0.000E+00 0.000E+00
> > 5 CBAR -4 122 6 4 E 4 0.00 0.00 -4.4
> > 4.4 0.00 0.000E+00 0.000E+00 0.000E+00 0.000E+00
> > 6 W- -24 120 4 4 16 16 1.07 12.24 358.4
> > 367.5 80.11 0.000E+00 0.000E+00 0.000E+00 0.000E+00
> >
> > W1j
> > ---HARD SUBPROCESS---
> >
> > IHEP ID IDPDG IST MO1 MO2 DA1 DA2 P-X P-Y P-Z
> > ENERGY MASS V-X V-Y V-Z V-C*T
> > 4 GLUON 21 121 6 7 9 5 0.00 0.00 146.6
> > 146.6 0.00 0.000E+00 0.000E+00 0.000E+00 0.000E+00
> > 5 SBAR -3 122 6 4 11 7 0.00 0.00 -23.8
> > 23.8 0.00 0.000E+00 0.000E+00 0.000E+00 0.000E+00
> > 6 HARD 0 120 4 5 7 8 -3.66 3.81 122.8
> > 170.5 118.19 0.000E+00 0.000E+00 0.000E+00 0.000E+00
> > 7 CBAR -4 123 6 5 17 4 -13.30 -28.41 25.4
> > 40.4 0.00 0.000E+00 0.000E+00 0.000E+00 0.000E+00
> > 8 W+ 24 124 6 8 20 8 13.30 28.41 97.4
> > 130.1 80.31 0.000E+00 0.000E+00 0.000E+00 0.000E+00
> >
> >
> > *** HepMC --> print
> > NOTE: two W's in out going particles from same vertex for W0j case !!!
> > ///////////////////////////////////////////////////////////////////////////
> > W0j
> > Barcode PDG ID ( Px, Py, Pz, E ) Stat
> > DecayVtx
> > ______________________________________________________________________________
> >
> > GenVertex: -1 ID: 0 (X,cT):0
> > I: 2 3 3 +0.00e+00,+0.00e+00,+3.63e+02,+3.63e+02
> > 121 -1
> > 4 -4 +0.00e+00,+0.00e+00,-4.42e+00,+4.42e+00
> > 122 -1
> > O: 4 5 -24 +1.07e+00,+1.22e+01,+3.58e+02,+3.67e+02
> > 120 -2 <<===
> > 6 3 -8.22e-01,+3.71e+00,+3.74e+02,+3.73e+02
> > 141 -5
> > 12 -4 +1.89e+00,+8.54e+00,-1.52e+01,-6.03e+00
> > 142 -10
> > 19 -24 +1.07e+00,+1.22e+01,+3.58e+02,+3.67e+02
> > 155 -16
> >
> > W1j
> > Barcode PDG ID ( Px, Py, Pz, E ) Stat
> > DecayVtx
> > ______________________________________________________________________________
> >
> > GenVertex: -1 ID: 0 (X,cT):0
> > I: 2 3 21 +0.00e+00,+0.00e+00,+1.47e+02,+1.47e+02
> > 121 -1
> > 4 -3 +0.00e+00,+0.00e+00,-2.38e+01,+2.38e+01
> > 122 -1
> > O: 5 37 0 -5.80e+00,-6.49e+00,-8.30e+01,+8.75e+01
> > 120 -2
> > 5 -4 -1.33e+01,-2.84e+01,+2.54e+01,+4.04e+01
> > 123 -5
> > 6 24 +1.33e+01,+2.84e+01,+9.74e+01,+1.30e+02
> > 124 -6
> > 7 21 -1.85e+00,+6.35e+00,+1.48e+02,+1.46e+02
> > 141 -7
> > 14 -3 -1.81e+00,-2.54e+00,-2.48e+01,+2.47e+01
> > 142 -13
> >
> > As I looked through the AlpGen_i, W reconstruction process (alpgen input
> > has
> > only e, enu), I don't see any suspicous point (nothing particular for
> > W0j process)
> >
> > In Herwig.cxx,
> > StatusCode Herwig::fillEvt(GenEvent* evt)
> >
> > hepio.fill_next_event(evt);
> >
> > is calling for,
> > http://lcgapp.cern.ch/project/simu/...
> >
> >
> > which look for the "hard" entry with status code=120 and put new vertex
> > in the record. As I can see from Herwig record, in case of W0j event,
> > status
> > code=120 is W itself (indicated with <<=== above). It looks to me this
> > is the
> > reason why we have two W's in HepMC record, and may screw up the
> > connections
> > (... I could not confirm the last point though.)
> >
> > If this is the case, do you think we need to fix the HepMC? or shall we
> > change the status code of W inside Herwig.cxx to something not equal to
> > 120?
> >
> > best regards,
> > Osamu
> >
> >
> > (2008/06/19 15:44), Osamu Jinnouchi wrote::
>> >> Hi Wouter,
>> >>
>> >> Thanks a lot. I hope I can pin down the problematic
>> >> point during today.
>> >>
>> >> best regards,
>> >> Osamu
>> >>
>> >>
>> >>
>> >> (2008/06/19 15:42), Wouter Verkerke wrote::
>>> >>> done.
>>> >>>
>>> >>> Wouter
>>> >>>
>>> >>> On Thu, 19 Jun 2008, Osamu Jinnouchi wrote:
>>> >>>
>>>> >>>> Hi Wouter,
>>>> >>>>
>>>> >>>> Yes, please attach W+1 configuration also.
>>>> >>>>
>>>> >>>> best regards,
>>>> >>>> Osamu
>>>> >>>>

Jon Butterworth <jmb>
2008-06-19 18:24, comment #2:

I have now added the hwdtau change to Herwig_i, and tagged it Herwig_i-00-02-38 (not yet collected anywhere).

Jon Butterworth <jmb>
2008-06-19 15:40, comment #1:

Hi,

I've also added the setup for sample 107681
(W+1 parton) for comparison which does not
seem to have this problem (no crashes in any
of my trial runs w and w/o photos)

Wouter

(file #6506)

Wouter Verkerke <verkerke>
2008-06-24 16:13, original submission:

Hi,

Running csc_evgen08_trf.py on alpgen W+0 parton events
crashes using either AtlasProduction 14.1.0.3 or
nightly 14.1.0.Y rel_3.

The crash is in PHOTOS, but this is just a symptom of
something wrong with the event structure (quoting mail
from Borut here)

-----------------

here is what I found:

-hwdtau indeed calls photos and it should not - someone please comment out the
lines or we get double-counting.

-If I comment out the lines the crash disappears if I exclude Photos_i.

-However if I now switch Photos on we get a crash (infinite loop) because the
HepMC record of Alpgen is crap:

From PrintMC:

24 2101 ud 3 -20 0 ( +0,
25 24 W++ 155 -1 -22 (
26 -11 e-+ 123 -22 -23
27 12 nu(e)0 124 0 -24
28 -11 e-+ 1 -23 0
29 12 nu(e)0 1 -24 0

as you can see the neutrino (27) has no parent, which confuses photos to no end
(it should have -22 as electron(26) );
even if the thing would not run amok we would get no photons from W decays!

Something is amiss with either ALPGEN input, alpgen reading or HepMC conversion..

---------------

How to reproduce (use either 14.1.0.3 or 14.1.0.Y rel_3 )

csc_evgen08_trf.py 107680 1 500 12345 MC8.107680.AlpgenJimmyWenuNp0_pt20.py evgen.pool.root NONE NONE alpgen.107680.WenuNp0.pt20._00001.tar.gz

the needed files

jobOptions file: MC8.107680.AlpgenJimmyWenuNp0_pt20.py
input tar ball: alpgen.107680.WenuNp0.pt20._00001.tar.gz

are attached to this bug report

Wouter

Wouter Verkerke <verkerke>

 

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by osamu (Posted a comment)
  • -unavailable- added by pacheco (Posted a comment)
  • -unavailable- added by garren (Posted a comment)
  • -unavailable- added by borut (Posted a comment)
  • -unavailable- added by jmb
  • -unavailable- added by jmb
  • -unavailable- added by jmb
  • -unavailable- added by jmb
  • -unavailable- added by jmb
  • -unavailable- added by jmb (Posted a comment)
  • -unavailable- added by verkerke (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independantly of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

     

     

    Follow 6 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    2008-07-03 22:05garrenDiscussion LockUnlocked=>Locked
    2008-06-25 06:41garrenStatusNone=>Fixed
      Assigned toNone=>garren
      Open/ClosedOpen=>Closed
      Closed on2008-06-25 06:41=>2008-06-25 06:41
    2008-06-24 16:13jmbReassign itemAtlas Generators, bug #37994=>HepMC - a C++ Event Record for Monte Carlo Generators, bug #38173
    Show feedback again

    Back to the top


    Powered by Savane SVN (toward 3.1)

    This project has been migrated to a new system.
    You will be redirected in 5 seconds.
    Or click here to go now.
    Let me continue in Savannah