MadGraph5_aMC@NLO

Common block and variables definitions in bias

Asked by Benjamin Grinstein

I want to write a bias file similar to the sample one ptj_bias.f for sampling of jet pt but for other particles (in particular for pt of tau leptons). The ptj is handled in the example by using a common block to_specisa that includes the logical variables is_a_j, is_a_a, etc and then computing pt from the 3-momentum p of the particle. Where and how are these variables defined? I searched through all source files and not one uses this common block. (Presumably a library, but in the absence of documentation how are we supposed to know?)

More generally, is there documentation that establishes what variables are available and their properties and usage?

Question information

Language:
English Edit question
Status:
Solved
For:
MadGraph5_aMC@NLO Edit question
Assignee:
No assignee Edit question
Solved by:
Olivier Mattelaer
Solved:
Last query:
Last reply:
Revision history for this message
Benjamin Grinstein (bgrinstein) said (last edit ): 		#1

Just noticed that the run card in https://answers.launchpad.net/mg5amcnlo/+question/694515 has lines

#*********************************************************************
# Generation bias, check the wiki page below for more information: *
# 'cp3.irmp.ucl.ac.be/projects/madgraph/wiki/LOEventGenerationBias' *
#*********************************************************************
  None = bias_module ! Bias type of bias, [None, ptj_bias, -custom_folder-]
  {} = bias_parameters ! Specifies the parameters of the module.
#
#

which do not seem to be present in current run cards: the one in MG5_aMC_v3_5_1 at Template/LO/Cards/run_card.dat has instead:

#*********************************************************************
# Customization (custom cuts/scale/bias/...) *
# list of files containing fortran function that overwrite default *
#*********************************************************************
 %(custom_fcts)s = custom_fcts ! List of files containing user hook function
#*******************************

Is it then that "bias" is gone? (I searched for "bias" in the list of updates, historically, and could not find any reference to that). If gone, is reweighting replacing it? How?

Thx
Ben

Revision history for this message
Best Olivier Mattelaer (olivier-mattelaer) said : 		#2

Hi,

bias module, custom_fcts, code hacking, plugin are quite advanced methods which are designed for quite expert developer.
We try to provide "real" example where such feature can be used but this is obviously quite far away from an extensive documentation.

The point of all such features is that you are NOT constrained by any API. In other word, you can use ALL (global) variable/function defined in the code for customizing MG5aMC in the way you want. Documenting ALL common block/function would be quite a task obviously and would be only complete if this is automated by a code. The issue is then that such documentation will then be quite long and quite un-usable. We were providing such type of documentation in the past but I do not think that anyone read it (ok me excepted but even me it was quite exceptional).

Concerning the bias module at LO, it is indeed true that I would like to replace it completely by the custom_fcts feature that I found more flexible. But 3.5.1, does not offer yet the bias feature natively via custom_fcts (looks like I forgot to finish the implementation/test). This will be include in 3.5.2 normally (I'm fixing the code/ write an example right now for it).
For 3.5.0/3.5.1, I have indeed hidden the LO bias module, thinking that the custom_fcts was ready (it was very close to be actually) to replace it. But it is just hidden, not removed (and it will not be removed in 3.5.2) so you can still use it if you know the line to add in the run_card.

Concerning the common block "to_specisa", that block is initialised in setcuts.f.
It is initialised based on the "pdg" information into class of particles that should be safe to use within the symmetry of the code.
One crucial point to be aware when using pdg information is that madgraph does not always know which pdg code is going to be written in the lhef file (that decision will be taken only if the event passes the first unweighting stage, which is occurring very/very late).

Cheers,

Olivier

Revision history for this message
Benjamin Grinstein (bgrinstein) said : 		#3

Thanks Olivier Mattelaer, that solved my question.