Negative cross-sections are LO

Hi,

This is very surprising since I never face that in our automation of the technique that you describe.
Could you indicate to us which model/process type of interferences. Such that we can try to look at this process/problem.

Cheers,

Olivier

On May 26, 2014, at 9:21 PM, Sébastien Brochet <email address hidden> wrote:

> New question #249294 on MadGraph5_aMC@NLO:
> https://answers.launchpad.net/mg5amcnlo/+question/249294
>
> Dear MadGraph experts,
>
> I have a rather unsual questions. I'm generating with Madgraph the production of heavy higgs boson decaying to ttbar with SM interference. Long story short, for efficiency purpose, we generate only the signal + interference production without the background, by editing the matrix element generated by MadGraph (matrix.f) in order to remove all the terms related to the background but not the the signal (you can have some background here: https://answers.launchpad.net/mg5amcnlo/+question/238699) . It works perfectly! We have events with both positive and negative weights, as expected.
>
> Now, we want to go even further, and generate the interference production alone, without the signal or background. The same method was used, ie, removing all the matrix element terms related to the background, but this time, we also remove the matrix element squared for the signal. After the generation, the cross-section is negative, and we do not obtain what we expect (ie, summing signal + interference does not give the same thing as generating signal + interference at the same time).
>
> The negative cross-section is expected, as the negative part of the interference is actually greater than the positive. But it seems to cause some trouble to MadGraph. In order to be sure, I multiplied the final matrix element by -1. This time, the cross-section is positive, and we obtain the expected shape for the interference, except that the positive and negative weight events are swapped.
>
> We so came to the conclusion that MadGraph, in LO mode, does not like negative cross-section. After some discussions with some colleagues, it seems like MadGraph in NLO mode handle this without issues. Do you think it's possible to adapt the LO mode to property handle negative cross-sections?
>
> Thank you very much,
>
> Cheers,
>
> --
> You received this question notification because you are an answer
> contact for MadGraph5_aMC@NLO.

Sure! You'll find below a step list for the generation of the process.

1) get the topBSM model: https://dl.dropboxusercontent.com/u/18239590/topBSM_v4.tar.bz2
It's a v4 model, but it works well with madgraph 5

2) Generate the process:
import model_v4 topBSM
generate g g > t t~ / o0 QED=2 QCD=2 QS0=2 Qs2=0 QS1=0
output gg_tt

3) Edit the run card to
  a) Use the CT10 PDF with LHAPDF (id 10800)
  b) Disable the fixed coupling options: 'F = fixed_couplings'
  c) Change the BW cut-off to 10000

4) Edit the file SubProcesses/P0_gg_ttx/matrix1.f
  a) Comment matrix element computation (lines 282 to 289)
  b) Add at the, after the ENDDO

      MATRIX1 = 0.D0
c Compute matrix element directly from formula.

c Squared matrix element for diagram 1
c MATRIX1 = MATRIX1 + 12*AMP(1)*DCONJG(AMP(1))

c Squared matrix element for diagram 2
c MATRIX1 = MATRIX1 + 24*AMP(2)*DCONJG(AMP(2))

c Squared matrix element for diagram 3
c MATRIX1 = MATRIX1 + 16D0/3D0*AMP(3)*DCONJG(AMP(3))

c Squared matrix element for diagram 4
c MATRIX1 = MATRIX1 + 16D0/3D0*AMP(4)*DCONJG(AMP(4))

c Interference between backgrounds
c MATRIX1 = MATRIX1 + 6*AMP(3)*DCONJG(AMP(1))
c MATRIX1 = MATRIX1 + 6*AMP(1)*DCONJG(AMP(3))
c MATRIX1 = MATRIX1 - 6*AMP(4)*DCONJG(AMP(1))
c MATRIX1 = MATRIX1 - 6*AMP(1)*DCONJG(AMP(4))
c MATRIX1 = MATRIX1 - 2D0/3D0*AMP(4)*DCONJG(AMP(3))
c MATRIX1 = MATRIX1 - 2D0/3D0*AMP(3)*DCONJG(AMP(4))

c Interference between signal and background
      MATRIX1 = MATRIX1 + 4*AMP(3)*DCONJG(AMP(2))
      MATRIX1 = MATRIX1 + 4*AMP(2)*DCONJG(AMP(3))

      MATRIX1 = MATRIX1 + 4*AMP(4)*DCONJG(AMP(2))
      MATRIX1 = MATRIX1 + 4*AMP(2)*DCONJG(AMP(4))

(This is what Madgraph computes, but with some terms commented, related to interference between background and squared elements)

5) Generate events

As you'll notice, the cross-section is negative, but the positive part of the signal is missing. If you add
MATRIX1 = -1 * MATRIX1
at the end of the matrix element computation, you'll obtain the correct shape, but with weights inverted.

I hope it's enough informations! Don't hesitate to ask if you need more.

Thanks a lot!

Hi Sebastien,

Thanks for your patience,
I finally found some time to investigate on this problem.

The computation of the cross-section was not correct but sometime the writting of the events was failing due to a wrong way to write the "positive" weight (they were written as --X)

The following fix seems to work:
=== modified file 'madgraph/various/combine_runs.py'
--- madgraph/various/combine_runs.py 2013-11-29 07:28:53 +0000
+++ madgraph/various/combine_runs.py 2014-06-18 13:34:20 +0000
@@ -143,6 +143,8 @@
                     sign = ''
                 else:
                     sign = '-'
+ if new_wgt.startswith('-'):
+ sign = ''
                 line= ' %s %s%s %s\n' % (' '.join(data[:2]), sign,
                                            new_wgt, ' '.join(data[3:]))
             fsock.write(line)

Thanks,

Olivier

Hi Olivier,

Thanks a lot, I'll try that as soon as possible, and I'll keep you updated!

Hi Sebastien,

I think that the previous was not enough. Which means that the distribution that you get with the forcing a change of sign in matrix.f is not correct either (I Think that the ratio of events between the various channel is wrongly set).

The correct fix would be to following:

+++ madgraph/various/combine_runs.py 2014-06-21 08:02:15 +0000
@@ -110,7 +110,7 @@
         #Now read in all of the events and write them
         #back out with the appropriate scaled weight
         fsock = open(pjoin(channel, 'events.lhe'), 'w')
- wgt = results.xsec / results.nunwgt
+ wgt = results.axsec / results.nunwgt
         tot_nevents=0
         for result in results:
             i = result.name
@@ -129,7 +129,7 @@
         def get_fortran_str(nb):
             data = '%E' % nb
             nb, power = data.split('E')
- nb = float(nb) /10
+ nb = abs(float(nb)) /10
             power = int(power) + 1
             return '%.7fE%+03i' %(nb,power)
         new_wgt = get_fortran_str(new_wgt)

 Cheers,

Olivier

Hi Olivier,

Thanks a lot! I've generated some events applying your two patches, and I have both positive and negative weight events! Looking at the mtt distribution, it's looking very very encouraging !

I need more time to check that it's really what we're expecting, but I'll mark this question as solved!

Thank you very much!

Dear experts,

I'm sorry to reopen this ticket, but I think there's still some issues.

First of all, I'm now able to generate interference alone with the patch in this thread, so thanks a lot for that!

In order to check the validity of the generation, I generated signal alone, interference alone and signal + interference. If I scale each distribution using the cross section predicted by MadGraph, and if I sum the signal generation with the interference generation, I'm supposed to get the signal + interference shape. Unfortunately, it's not the case if I use MadGraph cross-section.

With a little algorithm, I've been able to find the correct interference and signal+interference cross-sections in order to have a match between the distributions (here, I assume that the signal cross-section given by MadGraph is correct, since there're no negative weight events).

For information, here are the cross-sections predicted by MadGraph:
Signal = 0.968
Interference = -0.7317
Signal + interference = 0.5297

And the ones obtained to get the distributions to match:
Signal = 0.968
Interference = -0.55621
Signal + interference = 0.41179

You can see that values are close but not equal, and each time overestimated. Matched distributions (zoomed around the pic-dip structure) for the signal+interference are visible here : https://dl.dropboxusercontent.com/u/18239590/S_plus_i_vs_S_i.pdf (red is signal+interference generation, and blue is signal summed with interference ; really good agreement !)

Thanks a lot in advance for your time !

Hi Sebastien,

I have read your tread multiple times, and I'm sorry but I don't really understand your problem.
Do I understand you correctly that you claim that the shape provided for each piece is correct but not the global normalization?
If yes this is probably a problem linked to the model and the evaluation of the couplings (especially since you use this flag fixed_couplings, which might not really be supported in MG5).

What is the statistical error on the number that you quote. (In particular the error on the Interference term might be very critical since this should not have a constant sign and that the Phase-Space generation is not designed at all for such type of integrand.)
Do you put any cut for those number?

Cheers,

Olivier

Hi Oliver, sorry for the late answer.

> Do I understand you correctly that you claim that the shape provided for each piece is correct but not the global normalization?

That's exactly what I was trying to say, thanks for such a nice summary :)

Statistical errors are very small (10^-4 for interference and signal + interference, and 10^-5 for signal), and as far as I know, there's no cut on those numbers (that's the direct output of MadGraph, and I don't apply any cut during the generation).

If it's an issue with the model, do you have any advices on how to find what's wrong? It'd be very nice to have the correct cross-sections directly, but it seems we have a workaround which should work. What do you think?

Anyway, thanks a lot for your precious help, as usual :)

Cheers,

Sébastien

Dear Sébastien,

I'm not able to reproduce your numbers and your discrepancy. I get (from the MadGraph code, using the default set-up apart from CT10 PDF with LHAPDF (id 10800), 'F = fixed_couplings', BW cut-off to 10000 and hacking the matrix elements to include either only signal or interference or both.)

Signal = 4.058
Interference = -2.550
Signal + interference = 1.535

So, perfectly consistent within integration uncertainties (which are about 1%). What other special settings have you been using?

Best regards,
Rikkert

Dear Rikkert,

That's very interesting! I'll try to redo a generation from scratch to see what cross-sections I have. Do you know if the patches included in this thread are already included in latest revision?

Best regards,
Sébastien

I think so, but please check explicitly to be sure.

Best,
Rikkert

So, I redo the generation from scratch, and I still get the same cross-section than previously. What mass did you use for the generation?

Can you post somewhere your MadGraph folder so I can find any differences with mine?

Dear Sébastian,

Here is the process:

https://frederix.web.cern.ch/frederix/gg_tt.tar.gz

Best regards,
Rikkert

Thank you very much!

I've been able to reproduce your results @ 13 TeV. I also retried @ 8 TeV, and, this time, cross-sections are a little bit different and in agreement (the signal-alone cross-section is now ~1.2 pb). I'm still not sure what I've done to obtained such change, but for the moment, everything is fine!

Thanks a lot!!

I'm sorry to reopen this again, but the first patch of this thread is not applied in the latest revision, but the second is. Both are actually needed to have a proper generation.

I paste the patch below for convenience:

=== modified file 'madgraph/various/combine_runs.py'
--- madgraph/various/combine_runs.py 2013-11-29 07:28:53 +0000
+++ madgraph/various/combine_runs.py 2014-06-18 13:34:20 +0000
@@ -143,6 +143,8 @@
                     sign = ''
                 else:
                     sign = '-'
+ if new_wgt.startswith('-'):
+ sign = ''
                 line= ' %s %s%s %s\n' % (' '.join(data[:2]), sign,
                                            new_wgt, ' '.join(data[3:]))
             fsock.write(line)

Thanks a lot!

Hi everyone,

Just a little bump in order to be sure this patch is not forgotten.

Thanks!

Hi Sebastien,

Thanks for the reminder. Actually, I was pretty sure that the second patch would have been enough. Did you face a case where this is not the case? If yes this might indicate a deeper problem...

The reason why the second patch should be enough is that the weight use in the patch 1 should always be positive now.
since (line 113)
wgt = results.axsec / results.nunwgt

since the results.axsec is the integral of the absolute value of the function, wgt should always be positive and therefore the first patch should be useless.

Cheers and thanks again for your precious help on this matter.

Olivier