Propagating Weight ID's from LHEF to HepMC

Asked by Simonas Drauksas on 2020-10-13

Dear MG developers,

I have a question about weight ID's in HepMC files.

First, the setup and what happens.
When reweighting and naming various parameter points it would be great to have these names/ids written in the HepMC file.
For example, let's say I have an event in an LHEF file (along with the header):

<weightgroup name='mg_reweighting' weight_name_strategy='includeIdInWeightName'>
<weight id='point1'>set param_card mass 34 1000.0 # orig: 3000.0
set param_card ssmcoup 1 0.9 # orig: 1.0
<weight id='point2'>set param_card mass 34 2000.0 # orig: 3000.0
set param_card ssmcoup 1 0.5 # orig: 1.0
# Number of Events : 5
# Integrated weight (pb) : 0.010046
2212 2212 6.500000e+03 6.500000e+03 0 0 230000 230000 -4 1
1.004600e-02 1.268800e-04 1.016000e-02 0
<generator name='MadGraph5_aMC@NLO' version='2.8.0'>please cite 1405.0301 </generator>
 5 0 +1.0160000e-02 2.99912800e+03 7.81616400e-03 8.00755700e-02
       -2 -1 0 0 0 501 -0.0000000000e+00 +0.0000000000e+00 +9.8323714599e+02 9.8323714599e+02 0.0000000000e+00 0.0000e+00 1.0000e+00
        1 -1 0 0 501 0 +0.0000000000e+00 -0.0000000000e+00 -2.2870299871e+03 2.2870299871e+03 0.0000000000e+00 0.0000e+00 -1.0000e+00
      -34 2 1 2 0 0 +0.0000000000e+00 +0.0000000000e+00 -1.3037928411e+03 3.2702671331e+03 2.9991284316e+03 0.0000e+00 0.0000e+00
       13 1 3 3 0 0 -4.3939456193e+02 +3.0684611657e+02 -2.1790372204e+03 2.2439753404e+03 0.0000000000e+00 0.0000e+00 -1.0000e+00
      -14 1 3 3 0 0 +4.3939456193e+02 -3.0684611657e+02 +8.7524437929e+02 1.0262917927e+03 0.0000000000e+00 0.0000e+00 1.0000e+00
<wgt id='point1'> +9.6275264e-06 </wgt>
<wgt id='point2'> +2.3461820e-06 </wgt>

If I shower this event with Pythia8 and use the default pythia8_card.dat, the HepMC file starts like this:

HepMC::Version 2.06.09
E 0 -1 -1.0000000000000000e+00 -1.0000000000000000e+00 -1.0000000000000000e+00 9999 0 431 1 2 0 3 1.7672388399999997e-05 3.7847199999999997e-06 2.0034000000000002e-03
N 3 "1000.0_#_ORIG:_3000.0
SET_PARAM_CARD_SSMCOUP_1_0.9_#_ORIG:_MERGING=0.000" "2000.0_#_ORIG:_3000.0
C 2.0034000000000002e-03 1.0017000000000000e-02

The important lines are these:
N 3 "1000.0_#_ORIG:_3000.0
SET_PARAM_CARD_SSMCOUP_1_0.9_#_ORIG:_MERGING=0.000" "2000.0_#_ORIG:_3000.0

In these lines the weight "names" are encoded and it is rather difficult to decode them back into human-readable form.

After some hacking of I am able to get a much more usable HepMC file that starts like this:

HepMC::Version 2.06.09
E 0 -1 -1.0000000000000000e+00 -1.0000000000000000e+00 -1.0000000000000000e+00 9999 0 207 1 2 0 3 2.0320000000000008e-03 1.9255052800000001e-06 4.6923640000000006e-07
N 3 "Weight_MERGING=0.000" "point1_MERGING=0.000" "point2_MERGING=0.000"

Again, the important line is
N 3 "Weight_MERGING=0.000" "point1_MERGING=0.000" "point2_MERGING=0.000"

which now contains easily readable weight ids in a single line.

So, finally, my question is whether there is an "official" way to do this without hacking the MG5aMC_PY8_interface?
Also, is there some deeper reason for the current weight naming in HepMC files?



Question information

English Edit question
MadGraph5_aMC@NLO Edit question
No assignee Edit question
Last query:
Last reply:


This is technically a question for pythia8 authors. Since they wrote that interface.
But I do not think that they are good reason for not doing what you are doing.
The only important point is to keep the current convention for name associated to scale variation.

Now It would be nice if you can share what you did. I will then propose this for merging in the official version (or you can do the proposal yourself if you prefer).



Simonas Drauksas (tehmeh) said : #2

Sure, sharing is eazy. It's a bit faster for me if I just copy the relevant parts here as there aren't too many changes.

So one change here is to accomodate labels without spaces (and I also removed the transformation to uppercase)

// Function to convert aMC@NLO weight names to "HepMC convention".
string convertFromAMCATNLO( string input) {
  string output="";
  // Count number of blanks in weight name.
  int appearances = 0;
  for(int n = input.find(" ", 0); n != int(string::npos);
          n = input.find(" ", n)) {
  // Cut string by position of blanks.
  vector <string> pieces;
  for(int i =0; i < appearances;++i) {
    int n = input.find(" ", 0);
    input = input.substr(n+1,input.size());
  // Now pieces contains the details of the weight name.
  for(int i = 4; i < int(pieces.size()); ++i) {
    // Make upper case.
    transform(pieces[i].begin(),pieces[i].end(),pieces[i].begin(), ::toupper);
    // Add piece to weight name, with "_" as separator.
    output+=pieces[i] + "_";
  // S.D. For labels without spaces
   //transform(input.begin(), input.end(), input.begin(), ::toupper);
   output=input + "_";

  return output;

The second change is within the #ifdef HEPMCHACK block


              // Get name.
              string name;
              for ( std::map<string,string>::const_iterator
                it_att = it_w->second.attributes.begin();
                it_att != it_w->second.attributes.end(); ++it_att)
                name += it_att->first + "=" + it_att->second + "_";

              // In aMC@NLO, the weight names should be extracted from the
              // weight tag contents, not its attributes.
              // S.D. id actually contains the weight name!
              if (it_w->second.attributes.size()==0)
                name = convertFromAMCATNLO(it_w->;

            } // Done looping through weights.
          } // Done looping through weight groups.
        } // Done looping through cuts.

Above I simply have
name = convertFromAMCATNLO(it_w->;
Instead of
name = convertFromAMCATNLO(it_w->second.contents);


Thanks for mentioning the naming conventions, I had scale variations turned off for now.
These changes only work when use_syst = False in the run_card.dat.
When systematics are used the interface works as before. The conventions are in tact, but then the weight names are back to being cryptic again. So there needs to be some sort of separation between the two.



Stefan Prestel (prestel) said : #3

Hi again,

the interface was designed by Valentin & myself some years back. At that point, we agreed that it was reasonable to use the *content* of the weight tag, since for the conventional 1001-1009 scale variation weights, this content is more in line with the guidelines on how to name weights for HepMC (see, page 162). Maybe Valentin remembers better...

Now it would of course not be ideal to use "1001" as weight name for these conventional scale variations... but I do see the point that in some cases, using the weight id might be more human-readable. Just shows again that it would be very helpful to have a proper naming convention for weights in the HepMC file (something I've been pushing without success since 2013, it seems :D )

Note that in the last pythia 8.3 release, we opted for a scheme were we internally, in Pythia, translate 1001-1009 to the names that we should use, while keeping all the other weights with names determined from their id's, prefixed with a string "AUX_" (indicating that we did not know how to translate these ids internally). Also, all weights are automatically written by the HepMC-converter, so you'll never have to touch the weights explicitly. That might help for you as well.

So from my side:
- a complete change of the MG5_PY8 interface to use weight ids as name might be a bit dangerous
- maybe a translation could be added, and a flag that would allow switching from the current version to your update
- i would very much value feedback on Pythia 8.3003, which should have the behavior you expected - although the MG5_PY8 interface might have to be updated a little to comply with 8.3-syntax.


Simonas Drauksas (tehmeh) said : #4


I ran the main44 example on my lhe file with Pythia-8303.
The weights are named just as they should be - the weights are named after their IDs in the lhe file and there is "AUX_" attached in front.
It would be great to have this or analogous functionality when running Pythia through MadGraph!



Can you help with this problem?

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

To post a message you must log in.