LO bias and additional jets via "add process"

Asked by Hannes on 2017-11-17

Dear authors,

I am trying to implement a bias function that depends on the extra jets in events like
> p p > w+
> add process p p > w+ j
> add process p p > w+ j j

However, I do not know an easy way to actually access the kinematics of the extra jets because "nexternal" (as used in the example ptj_bias module) always corresponds to the number of particles of the lowest-multiplicity subprocess and I cannot loop over the additional jets.
I am probably missing something obvious, how would I access the momenta of the extra jets from within the bias module in such a case?

Cheers,
Hannes

Question information

Language:
English Edit question
Status:
Solved
For:
MadGraph5_aMC@NLO Edit question
Assignee:
No assignee Edit question
Solved by:
Hannes
Solved:
2017-11-20
Last query:
2017-11-20
Last reply:
2017-11-17

Hi Hannes,

This is a design flaw of such routine, this need to be rewritten if someone wants to have this working with more than one multiplicity.
I’m looking at it but this is more complex than anticipated.

Cheers,

Olivier

> On Nov 17, 2017, at 17:17, Hannes <email address hidden> wrote:
>
> New question #660866 on MadGraph5_aMC@NLO:
> https://answers.launchpad.net/mg5amcnlo/+question/660866
>
> Dear authors,
>
> I am trying to implement a bias function that depends on the extra jets in events like
>> p p > w+
>> add process p p > w+ j
>> add process p p > w+ j j
>
> However, I do not know an easy way to actually access the kinematics of the extra jets because "nexternal" (as used in the example ptj_bias module) always corresponds to the number of particles of the lowest-multiplicity subprocess and I cannot loop over the additional jets.
> I am probably missing something obvious, how would I access the momenta of the extra jets from within the bias module in such a case?
>
> Cheers,
> Hannes
>
> --
> You received this question notification because you are an answer
> contact for MadGraph5_aMC@NLO.

Hannes (hannes3) said : #2

Hi Olivier,

thanks for the quick reply and for looking into this.
It is good to know that it is indeed non-trivial and I have not been missing something obvious.
I don't know whether this feature is urgently needed, but being able to bias e.g. based on HT might be useful.

Cheers,
Hannes

Hi,

After a bunch of reflexion and some test. I think that I have finally found a good strategy.
I will write it here such that I have a place where it is written down (and I will use it later for documentation of that point).

The idea is to create one bias library per multiplicity. and to link each subprocess directory to the correct bias library.

This requires:
1) to add in make_opts the maximal value of multiplicity (or the list of mulitplicity to consider)
2) to have a local make_opts in each SubProcesses/P directory to be allow the makefile to link the correct library (or having a function to figure out which one by reading nexternal.inc)

3) that the makefile need to create all the library rather than a single one (need to be carefull about the parralelization of the compilation). To have the correct compilation for each library one might need to overwrite nexternal.inc in the local directory from the makefile.

So this an example of makefile that seems to work for the dummy case (assuming maxparticles defined in make_opts).

include ../../make_opts

all: $(BIASLIBDIR)$(BIASLIBRARY)
        for i in `seq 3 $(maxparticles)`; do echo $$i ;make $(BIASLIBDIR)libbias_$$i.$(libext);done

clean:
        $(RM) *.o $(BIASLIBDIR)$(BIASLIBRARY)

#
# Compilation of the module dummy
#

$(BIASLIBDIR)$(BIASLIBRARY): dummy.o
        $(call CREATELIB, $(BIASLIBDIR)$(BIASLIBRARY), $^)

$(BIASLIBDIR)libbias_%.$(libext): $(BIASLIBDIR)$(BIASLIBRARY)
        cp $(BIASLIBDIR)$(BIASLIBRARY) $@

#
# List of the requirements for this module.
# 'VALID' is the keyword that *must* be returned if everything is in order.
#
requirements:
        @echo "VALID"