Syscalc problem

Dear Benedikt,

Thanks for your report.

I’ve look recently at the tot fact with Valentin, and we fix the problem (if they were one, I’m not even sure anymore)
Will discuss that with him to check if he remembers.

For the rscale part this is actually fixed in MG5 2.3

Cheers,

Olivier

On 20 May 2015, at 13:21, Benedikt Maier <email address hidden> wrote:

> New question #267185 on MadGraph5_aMC@NLO:
> https://answers.launchpad.net/mg5amcnlo/+question/267185
>
> Dear experts,
>
>
> once more I am stumbling across problems (?) with SysCalc, using MG_2_2_3 and a minimal example this time.
>
>
> I am generating:
>
> generate p p > t t~
>
>
> and then leave everything as the default in the run_card, except for that I enable systematic studies (T = use_syst).
> I then get an LHE file whose events' rwgt sections look as follows:
>
> <mgrwt>
> <rscale> 2 0.21976783E+03</rscale>
> <asrwt>0</asrwt>
> <pdfrwt beam="1"> 1 21 0.13479162E+00 0.21976783E+03</pdfrwt>
> <pdfrwt beam="2"> 1 21 0.11353517E-01 0.21976783E+03</pdfrwt>
> <totfact> 0.00000000E+00</totfact>
>
>
> The totfact is always 0!
>
> When I do another run with FIXED ren/fact scales in the run_card, the section looks like:
>
>
> <mgrwt>
> <rscale> 0 0.00000000E+00</rscale>
> <asrwt>0</asrwt>
> <pdfrwt beam="1"> 1 21 0.85294195E-01 0.91188000E+02</pdfrwt>
> <pdfrwt beam="2"> 1 21 0.12744558E-01 0.91188000E+02</pdfrwt>
> <totfact> 0.66042564E+04</totfact>
>
>
> Now the rscale is always 0!
>
>
>
>
> Now when I apply SysCalc to both cases, I make the following observation:
>
>
> For events that have been generated with a fixed scale, the cross section dependence on the renormalization scale is gone. I guess this has to do with the rscale=0??
>
> For the case of the default dynamical scale, all 9 scale variation scenarios have different weights!
>
>
> This is how I would expect it. Why is it not the case for the fixed scale?
>
>
> Thanks in advance,
> Benedikt
>
> --
> You received this question notification because you are an answer
> contact for MadGraph5_aMC@NLO.

Hi Olivier,

thanks for the tip. Indeed, I just checked with 2.3, and at least the rscale is not zero anymore when using fixed scales and the scale dependence is there when applying SysCalc! That will help me a lot.

However, I observe the following now:

When I use the default dynamical scale, the rscale of e.g. the first event is:

0.41079836E+02

while the starting scale of the shower is 0.5659530E+02.

On the other side, when I use a fixed value OR a modified setscales.f with a special dynamical scale, the values for the rscale and the shower starting scale are always identical.

Do you have an explanation why for fixed scales /modified setscales.f they are the same, but not for the default dynamical choice?

Thanks a lot!
Benedikt

Hi,

Do you run with matching/merging?
The default renormalisation scale correspond to the clustering algorithm which provides a shower history for the alpha_s and pdf re-weighting.
So that’s why they are equal in the context of the default scale.

Cheers,

Olivier

On 20 May 2015, at 16:51, Benedikt Maier <email address hidden> wrote:

> Question #267185 on MadGraph5_aMC@NLO changed:
> https://answers.launchpad.net/mg5amcnlo/+question/267185
>
> Status: Answered => Open
>
> Benedikt Maier is still having a problem:
> Hi Olivier,
>
>
> thanks for the tip. Indeed, I just checked with 2.3, and at least the rscale is not zero anymore when using fixed scales and the scale dependence is there when applying SysCalc! That will help me a lot.
>
>
> However, I observe the following now:
>
> When I use the default dynamical scale, the rscale of e.g. the first
> event is:
>
> 0.41079836E+02
>
> while the starting scale of the shower is 0.5659530E+02.
>
>
> On the other side, when I use a fixed value OR a modified setscales.f with a special dynamical scale, the values for the rscale and the shower starting scale are always identical.
>
> Do you have an explanation why for fixed scales /modified setscales.f
> they are the same, but not for the default dynamical choice?
>
>
> Thanks a lot!
> Benedikt
>
> --
> You received this question notification because you are an answer
> contact for MadGraph5_aMC@NLO.

Hi Olivier,

thanks for the answer! I think I understood it!

I don't apply merging/matching...

Thanks,
Benedikt

Thanks Olivier Mattelaer, that solved my question.

Hi Olivier,

I don't know if this is the right place to report it, but we have found a bug in SysCalc which leads to incorrectly calculated weights when it is receiving LHE input generated with the leading order MadGraph code, but only in some cases:

The situation simply explained is:

If in an LHE event file there are >=10 particles (I think you call this "nexternals"), then the LO MadGraph code doesn't add a blank in front of the "10" in the first row of the event. This causes SysCalc to parse the event incorrectly, and it then doesn't pick the event_weight from the first line, but the starting scale of the shower which is standing next to it, to calculate the systematic weight variations. Since this scale might vary from event to event, the histograms wouldn't be filled correctly.

>=10 particles can occur for instance if you use complicated decay chains.
I've put example LHEs into

https://www.dropbox.com/sh/v8jyouitswd05vs/AACH4TbdbjZnljdHL01s7qVya?dl=0

In the long_decay_chain.lhe you see there is a blank missing. If I manually add a blank in front of it (long_decay_chain_added_blank.lhe), Syscalc works perfectly.

The funny thing is that when you do the decays with MadSpin, MadSpin DOES add a blank in front of the number, so here you won't run into problems. Also for NLO you don't have problems.

A possible fix for SysCalc v1.1.2 could look like (checks whether the line starts with a number, if so, adds a blank in front):

--- ../SysCalc_orig/SysCalc/src/SysCalc.cc 2015-03-27 04:17:24.000000000 +0100
+++ src/SysCalc.cc 2015-07-31 19:10:30.445082723 +0200
@@ -432,9 +432,24 @@
     string linestr = line;
     bool start = false;
     bool done = false;
+ // MadGraph LO mode adds no blank in front of nexternals if nexternals >=10.
+ // Adding a blank in front, otherwise tokens[3] wont be the event weight, but the shower starting scale
+ string ciphers = "123456789";
+ bool found = false;
+
     while (!done){
       _sysfile->getline(line, 1000);
       linestr = line;
+
+ if (!found && !linestr.empty())
+ {
+ if (ciphers.find(linestr.at(0))!= string::npos)
+ {
+ linestr.insert(0, " ");
+ found = true;
+ }
+ }
+
       if (!start){
     start = linestr.find("<event") != string::npos;
     if(_sysfile->eof()) done = true;

Cheers,
Benedikt

Hi Benedikt,

That's a good place to report (you could have open a new thread as well but this is perfect).

Thanks a lot for the patch. I will apply it to the code.

Cheers,

Olivier