spinmode onshell problem (continued)

Asked by Sihyun Jeon

https://answers.launchpad.net/mg5amcnlo/+question/661535

Hi Olivier, the problem never ends sadly.

We expected the ratio of SS and OS to be 1 since we use following commands (with spinmode onshell)

define mu = mu+ mu-
generate p p > mu n1 [QCD]
decay n1 > mu j j

which would generate mu+mu+, mu-mu-, mu+mu-, mu-mu+ combinations.

However we found that (mu+mu+)&(mu-mu-) / (mu+mu-)&(mu-mu+) ratio is not 1, about 0.7.

Is there a possible fix for this?

Or should we have to generate the hard way?
(divide the samples into 4 categories mu+mu+, mu-mu-, mu+mu- and mu-mu+ separately)

Thanks, Sihyun Jeon.

Question information

Language:
English Edit question
Status:
Solved
For:
MadGraph5_aMC@NLO Edit question
Assignee:
No assignee Edit question
Solved by:
Sihyun Jeon
Solved:
Last query:
Last reply:
Revision history for this message
Olivier Mattelaer (olivier-mattelaer) said :
#1

Hi,

I guess that this is actually the continuation of the same problem that you break quantum mechanics.

When receiving an events with not same sign muon.
you have two possibility to assign the muon (i.e. which one in production and which one in decay)
But according to this choice, the result that you expect is different.
The code allows only one matrix-element per set of pdg in the final state.
Therefore the code always assigns the positive one in the production (or the opposite).

Consequently, you are indeed force to split your production in (at least) two. (At least with this strategy)
Only two production should be enough to my understanding since you can do this:

> define mu = mu+ mu-
> generate p p > mu+ n1 [QCD]
> decay n1 > mu j j

and

> define mu = mu+ mu-
> generate p p > mu- n1 [QCD]
> decay n1 > mu j j

Cheers,

Olivier

> On 8 Jan 2018, at 16:32, Sihyun Jeon <email address hidden> wrote:
>
> New question #662694 on MadGraph5_aMC@NLO:
> https://answers.launchpad.net/mg5amcnlo/+question/662694
>
> https://answers.launchpad.net/mg5amcnlo/+question/661535
>
> Hi Olivier, the problem never ends sadly.
>
> We expected the ratio of SS and OS to be 1 since we use following commands (with spinmode onshell)
>
> define mu = mu+ mu-
> generate p p > mu n1 [QCD]
> decay n1 > mu j j
>
> which would generate mu+mu+, mu-mu-, mu+mu-, mu-mu+ combinations.
>
> However we found that (mu+mu+)&(mu-mu-) / (mu+mu-)&(mu-mu+) ratio is not 1, about 0.7.
>
> Is there a possible fix for this?
>
> Or should we have to generate the hard way?
> (divide the samples into 4 categories mu+mu+, mu-mu-, mu+mu- and mu-mu+ separately)
>
> Thanks, Sihyun Jeon.
>
> --
> You received this question notification because you are an answer
> contact for MadGraph5_aMC@NLO.

Revision history for this message
Sihyun Jeon (shjeon) said :
#2

Hi Olivier,

we have one more question regarding this charge ratio.

It seems that for mass of n1 bigger than 80GeV, (here we use default spinmode) we see the ratio was normal (SS:OS = 1:1).

One of the questions that were asked to us was "Why is charge ratio 1:1 for m(n1) > 80 and not 1:1 for m(n1) < 80".

Can you tell us why it is different?

Is it purely due to madspin spinmode or something else?

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

Hi,

Did you check with the spinmode=None for n1 bigger than 80GeV?

Cheers,

Olivier
> On 12 Jan 2018, at 19:57, Sihyun Jeon <email address hidden> wrote:
>
> Question #662694 on MadGraph5_aMC@NLO changed:
> https://answers.launchpad.net/mg5amcnlo/+question/662694
>
> Status: Answered => Open
>
> Sihyun Jeon is still having a problem:
> Hi Olivier,
>
> we have one more question regarding this charge ratio.
>
> It seems that for mass of n1 bigger than 80GeV, (here we use default
> spinmode) we see the ratio was normal (SS:OS = 1:1).
>
> One of the questions that were asked to us was "Why is charge ratio 1:1
> for m(n1) > 80 and not 1:1 for m(n1) < 80".
>
> Can you tell us why it is different?
>
> Is it purely due to madspin spinmode or something else?
>
> --
> You received this question notification because you are an answer
> contact for MadGraph5_aMC@NLO.

Revision history for this message
Sihyun Jeon (shjeon) said :
#4

Yes, they are 1:1 within stat errors.

With this result, then we can assume that this is due to onshell spinmode?

Aside from this I have one more question to ask

1) I found that in madspin
decay n1 > mu+ w-, w- > j j
AND
decay n1 > mu+ w-
decay w- > j j

these two command lines give a bit big difference in cross sections.

This would be due to nwa? Anyways, could you tell me which cross section would be more accurate or recommended to trust?

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

Sorry I did not ask the correct question.
Did you test madspin=onshell for the case where the normal madspin can be used?
If those are in 1:1 then something weird happens.

Did you test by splitting in two sample like i was suggesting?

> 1) I found that in madspin
> decay n1 > mu+ w-, w- > j j
> AND
> decay n1 > mu+ w-
> decay w- > j j

In the second case, you do not ask the W- coming from the n1 decay to decay.
Therefore the two cross-section will differ by BR(w- > j j )
In the second case, the last line is irrelevant if you do not have any W in the production matrix-element.

Cheers,

Olivier

> On 14 Jan 2018, at 15:27, Sihyun Jeon <email address hidden> wrote:
>
> Question #662694 on MadGraph5_aMC@NLO changed:
> https://answers.launchpad.net/mg5amcnlo/+question/662694
>
> Status: Answered => Open
>
> Sihyun Jeon is still having a problem:
> Yes, they are 1:1 within stat errors.
>
> With this result, then we can assume that this is due to onshell
> spinmode?
>
>
> Aside from this I have one more question to ask
>
> 1) I found that in madspin
> decay n1 > mu+ w-, w- > j j
> AND
> decay n1 > mu+ w-
> decay w- > j j
>
> these two command lines give a bit big difference in cross sections.
>
> This would be due to nwa? Anyways, could you tell me which cross section
> would be more accurate or recommended to trust?
>
> --
> You received this question notification because you are an answer
> contact for MadGraph5_aMC@NLO.

Revision history for this message
Sihyun Jeon (shjeon) said :
#6

I tested two cases with m(n1) = 500 GeV (where default madspin mode should be used)

[A]
generate p p > mu+ n1 [QCD]
set spinmode onshell
define mu = mu+ mu-
decay n1 > mu j j

[B]
define mu = mu+ mu-
generate p p > mu n1 [QCD]
set spinmode onshell
decay n1 > mu+ j j

For case[A] the ratio is 1:1 and [B] is 0.33:0.67

Revision history for this message
Sihyun Jeon (shjeon) said :
#7

Ah actually the [B] didn't have to be tested since it's w+/w- ...

Revision history for this message
Sihyun Jeon (shjeon) said :
#8

[A]
generate p p > mu+ n1 [QCD]
set spinmode onshell
define mu = mu+ mu-
decay n1 > mu j j

Sorry it's not 1:1.
I could only check this with high stats.

For case[A] with "spinmode none" it's 50:50 with #events 49.95 : 50.05 with #events 80000
However, with "spinmode onshell" it's 49.32 : 50.68 even with #events 160000

I think this does make some difference when using onshell, no?

Revision history for this message
Sihyun Jeon (shjeon) said :
#9

Sorry for multiple notes.

I am testing with more stats and there was some error in the previous comment.

[A]
generate p p > mu+ n1 [QCD]
define mu = mu+ mu-
decay n1 > mu j j

For case[A] with "spinmode none" it's just 50.01:49.99 with #events 160000
However, with "spinmode onshell" it's 49.30 : 50.70 even with #events 240000

I think this does make some difference when using onshell, no?

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

Hi,

So clearly this indicates a deeper problem to the onshell mode. I need to take the time to make a full investigation on that mode since this indicates a tricky bug which might occur also for other types of processes.

I will keep you in touch.

Cheers,

Olivier

Revision history for this message
Sihyun Jeon (shjeon) said :
#11

Hi Olivier,
this is from my email thread.

I guess spinmode onshell does give somewhat unexpected charge ratios when compared to the other spinmodes.

Aside from this, there was some more questions regarding rest of the mass points so I thought it would be better to talk through email if you don’t mind.
The concern is that, the explanation you gave about OS/SS not equal to 1 seems to be the same for high mass samples (where spinmode onshell is not used) as well since they break quantum mechanics too. But we have OS/SS = 1 for high mass samples and this seems a bit odd based on your explanation. So they wonder IF the charge ratio is fine, are the other stuffs (kinematics, etc.) fine as well. Because OS/SS != 1 could be just one minor symptom (which only shows for low mass but not for high mass samples) when you try to break quantum mechanics and there could be more underlying problems.

Could you explain about this in more detail if possible?

I hope I am clear what I am trying to say here, but since I am not sure whether I am, I send some chats we had.

Hi Sihyun, your test seems to indicate that "spinmode onshell" is the culprit. However, I wonder if we can really conclude that everything is good from the fact that SS:OS is 1:1 with regular madspin at high mass. It's entirely possible that the charge ratio is only one of multiple symptons of an underlying problem with madspin. Since the explanation brought by Olivier seems to apply generally, independent of the spinmode setting, I would propose to resolve this first. Long story short: try to get an answer from Olivier to the question: "If the charge ratio is fine, does that mean everything is ok?"

Okay, just to clarify, your concern is that something else (maybe some kinematics for instance) even for the default spinmode might have problems since Olivier's explanation was that "it has problems because the quantum mechanics is broken" and this goes same for the high mass

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

Hi,

My concern about quantum mechanics is that identical particles should have symmetric matrix-element.
Clearly your process definition does not match that requirement ( due to your use of the narrow-width approximation [NWA]).
The question that I raise here is that NWA is really valid for such type of process.
I do not know the answer to such question, but if it is that NWA is not valid then the MadSpin approach has to be banned.

Now let me explain quickly the difference between each mode
1) spinmode=None
This mode generates decay events via a separate instance a madevent and then merge them to the production events via a simple boost.
This is a stupid mode actually.

2) spinmode=onshell
This mode generates decay events via a separate instance a madevent and then merge them to the production events via a simple boost.
then the generated events is accepted or rejected according to the matrix-element [squared] of the full-event divided by the matrix-element [squared]
of the production times the one of the decay. Rejected events, will be associated to another decay events and the procedure of selection restarts.
Note 1) the actual implementation is to try to add a decay to the event as long as needed but this is a technical detail.
2) the particle is kept exactly onshell but the spin-correlation is restored by the acception/rejection method.

3) spinmode=default
- The event is associated to one channel of integration of the production event and like that we re-computed the random-number associated to the generation of that event
- random number are added for the invariant mass of the decaying particle and for the angle of the decay of that particle (in the rest-frame of that particle)
- from those random number the event is re-generated
  therefore this include off-shell effects and re-shuffling, from the re-shuffling method, the bjorken x are preserved which can be problematic for some below threshold effect.
- that decayed events is accepted/rejected according to the ratio of full matrix-element divided by the one of the production.

Finally one should note the big difference between mode 2 and 3 is that mode 2 is 100% python (but the evaluation of the matrix-element which is done in f77 via a f2py module)
while the mode 3 is basically 100% fortran.
So it is actually kind of two different code and is it kind of unlikely that a non physical bug in one of those two mode affects one of the other.
(even the method to read/write event is actually different between those two mode)

> Long story short: try to get an answer from Olivier to the question: "If the charge ratio is fine, does that mean everything is ok?"

clearly, I would not trust the onshell mode for your process. But the other one might be fully fine (if you can indeed trust NWA)

Cheers,

Olivier

> On 17 Jan 2018, at 14:52, Sihyun Jeon <email address hidden> wrote:
>
> Question #662694 on MadGraph5_aMC@NLO changed:
> https://answers.launchpad.net/mg5amcnlo/+question/662694
>
> Status: Answered => Open
>
> Sihyun Jeon is still having a problem:
> Hi Olivier,
> this is from my email thread.
>
>
>
> I guess spinmode onshell does give somewhat unexpected charge ratios when compared to the other spinmodes.
>
> Aside from this, there was some more questions regarding rest of the mass points so I thought it would be better to talk through email if you don’t mind.
> The concern is that, the explanation you gave about OS/SS not equal to 1 seems to be the same for high mass samples (where spinmode onshell is not used) as well since they break quantum mechanics too. But we have OS/SS = 1 for high mass samples and this seems a bit odd based on your explanation. So they wonder IF the charge ratio is fine, are the other stuffs (kinematics, etc.) fine as well. Because OS/SS != 1 could be just one minor symptom (which only shows for low mass but not for high mass samples) when you try to break quantum mechanics and there could be more underlying problems.
>
> Could you explain about this in more detail if possible?
>
> I hope I am clear what I am trying to say here, but since I am not sure whether I am, I send some chats we had.
>
> Hi Sihyun, your test seems to indicate that "spinmode onshell" is the culprit. However, I wonder if we can really conclude that everything is good from the fact that SS:OS is 1:1 with regular madspin at high mass. It's entirely possible that the charge ratio is only one of multiple symptons of an underlying problem with madspin. Since the explanation brought by Olivier seems to apply generally, independent of the spinmode setting, I would propose to resolve this first. Long story short: try to get an answer from Olivier to the question: "If the charge ratio is fine, does that mean everything is ok?"
>
> Okay, just to clarify, your concern is that something else (maybe some kinematics for instance) even for the default spinmode might have problems since Olivier's explanation was that "it has problems because the quantum mechanics is broken" and this goes same for the high mass
>
> --
> You received this question notification because you are an answer
> contact for MadGraph5_aMC@NLO.

Revision history for this message
Sihyun Jeon (shjeon) said :
#13

Hi Olivier
thanks for the kind description