Question about different behavior when using DIM6=1 and DIM6^2=2 syntaxes

Asked by Kelci Mohrman on 2019-06-17

Hello MG experts,

I have a question about an error that is produced when trying to run a pp to tth plus jet process. We are using the dim6top_LO_UFO model and MadGraph version is 2.6.5. When we use the following syntax:

    generate p p > t t~ h j DIM6^2=2

Everything works as expected, but the following syntax:

    generate p p > t t~ h j DIM6=1

Gives this error:

    Error when reading /afs/crc.nd.edu/user/k/kmohrman/MadGraph_dir/MG5_aMC_v2_6_5/tthj_Dim6_Point0_V2/SubProcesses/P1_gg_ttxhg/G3/results.dat
    Command "generate_events run_01" interrupted with error:
    IOError : [Errno 2] No such file or directory: '/afs/crc.nd.edu/user/k/kmohrman/MadGraph_dir/MG5_aMC_v2_6_5/tthj_Dim6_Point0_V2/SubProcesses/P1_gg_ttxhg/G3/results.dat'

We tried to check if any other channel failed (besides P1_gg_ttxhg/G3) by looking for the results.dat file in each of the other directories, and the only other directories that were missing the file were P1_gg_ttxhg/G45 and P1_gg_ttxhg/G46. The log files in all 3 directories contained the following error:

    cluster.f: Error. Invalid combination.
    Error: Clustering failed in cluster.f.

We are not sure what this error means or how to fix it. We are also very confused as to why the DIM6^2=2 syntax seems to work fine while the DIM6=1 fails.

One other thing we are wondering about is how the integration channels correspond to diagrams and how the integration channels are combined; by following the information provided in a MG FAQ [1], we tried to check which channels (and corresponding diagrams) the 3 failed channels were being combined with. If we are understanding [1] correctly, it seems that for the 3 channels that failed, MG was combining diagrams with dim6 vertices of different types (e.g. combining a diagram with a dim6 vertex at the tth vertex with a diagram with the dim6 vertex at the ttg vertex). When we looked at the diagrams that corresponded to other combined channels (that did not fail), it seemed that the only difference between the diagrams that were being combined was the direction of the fermion line (i.e. the vertex was moved from the t leg to the t~ leg). We are not sure if this has anything to do with the error (and are not even sure that we completely understand the mapping between channels and diagrams or how channels/diagrams are combined), so we apologize if it is not relevant, we just wanted to bring it up just in case.

Thank you very much! - Kelci

[1] https://answers.launchpad.net/mg5amcnlo/+faq/2944

Question information

Language:
English Edit question
Status:
Answered
For:
MadGraph5_aMC@NLO Edit question
Assignee:
No assignee Edit question
Last query:
2019-06-17
Last reply:
2019-06-20

Thanks for reporting

The reason why dim6^2 works is that you have a naive dynamical scale by default for this syntax. And that the crash is within the calculation of the dynamical scale.

Cheers

Olivier

Get Outlook for iOS<https://aka.ms/o0ukef>
________________________________
From: <email address hidden> <email address hidden> on behalf of Kelci Mohrman <email address hidden>
Sent: Monday, June 17, 2019 5:37:31 PM
To: Olivier Mattelaer
Subject: [Question #681443]: Question about different behavior when using DIM6=1 and DIM6^2=2 syntaxes

New question #681443 on MadGraph5_aMC@NLO:
https://answers.launchpad.net/mg5amcnlo/+question/681443

Hello MG experts,

I have a question about an error that is produced when trying to run a pp to tth plus jet process. We are using the dim6top_LO_UFO model and MadGraph version is 2.6.5. When we use the following syntax:

    generate p p > t t~ h j DIM6^2=2

Everything works as expected, but the following syntax:

    generate p p > t t~ h j DIM6=1

Gives this error:

    Error when reading /afs/crc.nd.edu/user/k/kmohrman/MadGraph_dir/MG5_aMC_v2_6_5/tthj_Dim6_Point0_V2/SubProcesses/P1_gg_ttxhg/G3/results.dat
    Command "generate_events run_01" interrupted with error:
    IOError : [Errno 2] No such file or directory: '/afs/crc.nd.edu/user/k/kmohrman/MadGraph_dir/MG5_aMC_v2_6_5/tthj_Dim6_Point0_V2/SubProcesses/P1_gg_ttxhg/G3/results.dat'

We tried to check if any other channel failed (besides P1_gg_ttxhg/G3) by looking for the results.dat file in each of the other directories, and the only other directories that were missing the file were P1_gg_ttxhg/G45 and P1_gg_ttxhg/G46. The log files in all 3 directories contained the following error:

    cluster.f: Error. Invalid combination.
    Error: Clustering failed in cluster.f.

We are not sure what this error means or how to fix it. We are also very confused as to why the DIM6^2=2 syntax seems to work fine while the DIM6=1 fails.

One other thing we are wondering about is how the integration channels correspond to diagrams and how the integration channels are combined; by following the information provided in a MG FAQ [1], we tried to check which channels (and corresponding diagrams) the 3 failed channels were being combined with. If we are understanding [1] correctly, it seems that for the 3 channels that failed, MG was combining diagrams with dim6 vertices of different types (e.g. combining a diagram with a dim6 vertex at the tth vertex with a diagram with the dim6 vertex at the ttg vertex). When we looked at the diagrams that corresponded to other combined channels (that did not fail), it seemed that the only difference between the diagrams that were being combined was the direction of the fermion line (i.e. the vertex was moved from the t leg to the t~ leg). We are not sure if this has anything to do with the error (and are not even sure that we completely understand the mapping between channels and diagrams or how channels/diagrams are combined), so we apologize if it is not relevant, we just wanted to bring it up just in case.

Thank you very much! - Kelci

[1] https://answers.launchpad.net/mg5amcnlo/+faq/2944

--
You received this question notification because you are an answer
contact for MadGraph5_aMC@NLO.

Hi,

Actually, I realize that you are using a model which is weirdly define at the QCD level.
This creates a lot of issue for a lot of the QCD related feature.
I'm actually considering if I should not veto such type of model within MG5aMC.
I think that we need to put pressure on the author of such model such that their model is more carefull on the QCD level.
Can you contact them?

I will continue to check if they are something that I can do on my side to have proper for such weird implementation of the model.

Cheers,

Olivier

Hi,

You were actually right that this issue is actually linked to the diagram grouping.
The reason of such issue is that the code merge the phase-space integration of two diagram who does not have the same power of a_S. Leading to some error when trying to compute the default scale for the process.

I'm in contact with the author of the model to see what can be done, but for the moment,
one can not use this model with
1) MLM
2) default dynamical scale
3) FxFx (did not test here but I guess that it will not work)
4) NLO (at least for MG5aMC 2.x)
5) systematics computation

If you can use simple dynamical scale like Ht/2 then it should be ok to work at LO accuracy as far as i know.

Cheers,

Olivier

Hi,

I think that I should soften my statement, the model is correctly implemented but MG5aMC is not able to handle model where you can have non QCD emission of gluon. So the actual issue is rather within our code and not in the model.

Having full support for such type of model might not possible in a short time-scale.

Cheers,

Olivier

Kelci Mohrman (kmohrman) said : #5

Hi Olivier,

Thanks for getting this figured out.

I have a quick followup question. Under the conditions you outlined above, does this issue imply that we should not trust the output of MG even when it does not crash, or does this simply mean that we should not expect it to run for an arbitrary process?

Thanks again for all of the help! - Kelci

As far as I know if you do not use any of 5 features reported above, then you should be fine.
Not all of them will lead to a crash

So to be on the save side, I would therefore recommend for this model to always edit the run_card with those commands:
set use_syst F
set dynamical_scale_choice 3 # you can use another number but not -1
(and to not do MLM, NLO, FxFx)

This is obviously up to the point that we have modify our code to fully support such type of model

Cheers,

Olivier

Kelci Mohrman (kmohrman) said : #7

Hi Olivier,

Thanks again for the helpful response.

I think I am still a bit confused about what exactly is the difference between the dim6^2=2 and the dim6=1 syntaxes that causes dim6=1 to crash, but does not cause dim6^2=2 to crash. In your original response, you mentioned that the reason why dim6^2 does not crash is because this syntax has a "naive dynamical scale by default." I don't think that I understand what this means. As far as I can tell, both syntaxes have the dynamical scale set to -1 by default?

I'm also still a little confused about if/when we can trust the output of MG (when using the dim6top_LO_UFO model and the 5 features you listed above) when MG does not crash. When you said that using that model with those features will not always cause a crash, but you would still suggest not using the features, does this mean that we cannot assume that we can trust the predictions of MG when running in this way, even when it does not crash?

Thanks so much again! - Kelci

Hi,

> I don't think that I
> understand what this means. As far as I can tell, both syntaxes have the
> dynamical scale set to -1 by default?

I'm surprised here, I thought the second syntax would have dynamical scale choice to "3" for the dim6^2 case.

> I'm also still a little confused about if/when we can trust the output
> of MG (when using the dim6top_LO_UFO model and the 5 features you listed
> above) when MG does not crash.

I have tested the "dim6^2" with 2.6.6 where I put various restriction/crash associated to the feature that we do not support in this model.

In this new version, both syntax now crashes with this error:

>> Command "import /Users/omattelaer/Documents/workspace/2.6.6/cmd" interrupted in sub-command:
>> "output" with error:
>> Exception : identical diagram with different QCD powwer
>> Please report this bug on https://bugs.launchpad.net/mg5amcnlo
>> More information is found in 'MG5_debug'.
>> Please attach this file to your report.

Which is checking the source of the crash of the dim6= syntax (so yes you have the same issue with the dim6^2= syntax).

I'm not 100% sure if this will stay a crash (or not) when 2.6.6 will be released but I would certainly not trust
the default dynamical scale/MLM/scale uncertainty. (and those will certainly be impossible to run for such process/model in 2.6.6). For the scale, this is obviously not a big deal since they are a lot of freedom on how to pick such parameter.

> does this mean that we cannot assume
> that we can trust the predictions of MG when running in this way, even
> when it does not crash?

So you already shows two examples where MG5aMC produces cross-section/events with inconsistencies.
- the first case with MLM, but were the power of a_S was set incorrectly (which means that the matching was not performed correctly)
- the case of the dim6^2=, where also you should expect issue with the handling of a_S.

In both case, the matrix-element itself is evaluated correctly but tracking of power of a_S is not.
So clearly one should not trust blindly any result with this model/features. When I mean model, this is mainly the presence of the chromo-magnetic operator which creates issue here.

Now more in details:
1) if you only use the dynamical scale choice, one can argue that this is within scale uncertainty.
2) For MLM, I would not trust it. (The only argument to keep such generation is saying that the impact is small and that you do not see any weird effect in DJR, but this will make me uncomfortable)
3) For scale uncertainty, If you face the crash above in 2.6.6. then you can certainly not trust it and additionally you can not trust in presence of MLM. In the other situations, it is likely that the computation of the systematics provides meaningful result. For the moment in 2.6.6, I'm also forbidding it completely but I might allow it (but if I face the above situation)

For 2.6.6 (or 2.6.7), I might be able to fully prevent the "bad" merging of channel of integration (the point related to the crash in 2.6.6) and then I would need to re-evaluate if I can trust scale uncertainty or not.
Fixing MLM/dynamical scale is more complex and will require more work (and therefore a feature version not a bug fixing one)

Cheers,

Olivier

> On 19 Jun 2019, at 17:33, Kelci Mohrman <email address hidden> wrote:
>
> Question #681443 on MadGraph5_aMC@NLO changed:
> https://answers.launchpad.net/mg5amcnlo/+question/681443
>
> Kelci Mohrman posted a new comment:
> Hi Olivier,
>
> Thanks again for the helpful response.
>
> I think I am still a bit confused about what exactly is the difference
> between the dim6^2=2 and the dim6=1 syntaxes that causes dim6=1 to
> crash, but does not cause dim6^2=2 to crash. In your original response,
> you mentioned that the reason why dim6^2 does not crash is because this
> syntax has a "naive dynamical scale by default."
>
> I'm also still a little confused about if/when we can trust the output
> of MG (when using the dim6top_LO_UFO model and the 5 features you listed
> above) when MG does not crash. When you said that using that model with
> those features will not always cause a crash, but you would still
> suggest not using the features, does this mean that we cannot assume
> that we can trust the predictions of MG when running in this way, even
> when it does not crash?
>
> Thanks so much again! - Kelci
>
> --
> You received this question notification because you are an answer
> contact for MadGraph5_aMC@NLO.

Kelci Mohrman (kmohrman) said : #9

Hi Olivier,

Thank you very much for the clarifications.

I apologize if i'm missing something, but if I'm understanding correctly, you are saying that the fundamental cause of this issue is related to the improper merging of integration channels due to diagrams that contain non-QCD emission of a gluon/ chromo-magnetic operator; when this is the case, we should not necessarily trust the output of MG, even when it does not happen to crash.

I think I'm still confused about two points:

    - Is this only an issue when considering extra partons? In other words, will we have to worry about this issue anytime ctg is involved, or only when we have an extra jet and ctg is involved?

    - Does this issue only come up when a gluon is emitted (like as a final state particle), or will it also affect diagrams where the gluon is a propagator or an initial state particle?

Thanks again! - Kelci

Can you help with this problem?

Provide an answer of your own, or ask Kelci Mohrman for more information if necessary.

To post a message you must log in.