SHERPA HEPMC output

[dirkzerwas]

Hi @apricePhy,

I ran the FermionProduction with a uubar final state to debug the conversion HepMC -> EDM4HEP.

HEPMC is 3.2.7, so according to page 6 of https://arxiv.org/pdf/1912.08005.pdf I would have expected the colorflow as vector when retrieving the attribute "flows", but the pointer is empty (info not present).

Here is the first event:
SherpaOut.txt

So it seems like the colorflow is there, but coded as flow1 and flow2, which is (page 10) the pre-3.2.0 style.

Could you check whether in the sherpa 3 and/or more recent sherpa2 versions the change was made?

I guess we could do a bootstrap (check for flow1, flow2 first, if not present check for flows) to compensate, but.......

Dirk

[dirkzerwas]

Related question for the weights:
the implementation looks old style, but pre-3.2.0 I would have expected weights1, weightsN, here it is
weight instead of weights and starts at 0.

[dirkzerwas]

Correction:
in the file the line marked "W" in the first column contains the weights retrievable as a vector, so I guess I do not know what weight0 means?

Reading weights:
Reading weights of value 8839.1
Reading weights of value 0.000415632
Reading weights of value 8882.93
Reading weights of value 1
Reading weights of value 0

But I am confused:
Why do we have five weights? The "weight_names" vector is empty, that explains maybe the WARNING?

[apricePhy]

!This was sent yesterday but never left my outbox
Hi Dirk,

I will raise the colorflow issue with the sherpas as well as the weights.
Hepmc does provide some backwards capabilities which may be simpler
than a bootstrap just set the following options
"particle_flows_are_separated", "vertex_weights_are_separated “
using the Reader::set_options(…)

The four weights are as follows
Event Weight
Matrix element weight
Normalization
Number of events

Sherpa 3 has a much more sophisticated treatment with proper weight names.
For us the first weight should be sufficient.

Cheers,
Alan

[dirkzerwas]

Thanks, I found something else:
HepMC3 defines the attributes
signal_vertex_id (refers to OID of the vertex)
signal_process_id (generator specific)

in the Sherpa output I found a linear combination :)
signal_process_vertex
so the our reader now tries first "signal_vertex_id" and if that fails: "signal_process_vertex", but it might be thing to change in the future :)

The weights are correctly read (my mistake) via the vector, but the "weightN" stuff seems to be either old or additional information :)