20080624 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 nonhadron, 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 nontrivial to repeat the setup (I can give instructions..)
I can give you the fixed IO_HERWIG upon request..
Best,
Borut

20080624 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_i000028
> > EvgenJobTransforms000608
> > Herwig_i000237
> > Photos_i010047 (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 PX PY PZ
> > ENERGY MASS VX VY VZ VC*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 PX PY PZ
> > ENERGY MASS VX VY VZ VC*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.22e01,+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
>>>> >>>>
