-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
change of signature for cudacpp #18
Comments
Hi Olivier, thanks, useful questions
Ok this is something I must have added these days for multichannel in madgraph5/madgraph4gpu#465 I was also a bit surprised that I had to do this, but I found this to be the most consistent to the rest of the code
This is consistent to what is done for other memory buffers, namely for couplings that are calculated from Gs
I am not saying this is the optimal solution. We can certainly reconsider this. But for the moment I would keep it like that... (Incidentally, this is very vaguely related to madgraph5/madgraph4gpu#356).
Not a problem! Just let me know when you do it, so I need to synchronise the code generation of cudacpp. I think I actually like it better in the new way you propose!
Two points
In both cases I would add after channelId (and before nevt when present) the extra arguments you suggest,
For calculate_wavefunctions, I am rather confused about the algorithm here (and the physics). I need to think about it more. For the moment, in practice I would say I just have this vague thought:
So, summary is, I think you have a much better idea what to do with calculate_wavefunction! Just go ahead, write the algorithm, thehn I will vectorize it when porting it to cudacpp... [ As mentioned, I realise I need to study a bit more the color algebra. A couple of references fr myself
|
ok thanks i will move in that direction then. Concerning the color, the madevent algorithms pick the color and helicity independently. so therefore the helicity "h" is picked with probability
and the color "c" is picked according to
where
So Jamp2 is at the exact same level as the multichannel numerator/denominator since this is a running sum over helicity. |
Now another method (also supported in madevent with nhel=1 in the run_card but not compatible with helicity recycling) Interestingly:
|
Hi Olivier, thanks. What confuses me here is the fact that jamp2(c) is the sum over helicity of jamp2(h,c). I assume here by the way that jamp2 means this is the square of jamp - or rather, the real square of the norm of the complex number jamp, ie jamp2(h,c)=conj(jamp(h,c))*jamp(h,c) for a given helicity h and color c. Maybe I am wrong here? Let me try to vaguely clarify. What we do is
What confuses me is that
It is not just "missing the correlation between the color and the helicity picked", it is really that I have the impression that the color picking by itself is based on some approximation? But again, probably I misunderstand... There is the following discussion in one paper which is maybe related, but probably I do not fully understand that either... |
Or maybe actually that paragraph actually is exactly what I am saying above? I mean, the color matrix(c1,c2) is NOT delta(c1,c2), but the color picking algorithm treats it as if it was delta(c1,c2) and neglects the off-diagonal terms, which are suppressed by a power of 1/9 (I guess N=3 here)?
In a way, the algorithm proceeds as if the matrix above only had the 512's on the diagonal, and neglects all other terms (which indeed are one order of magnitude smaller)? |
yes that's the point. Interference between color is actually something that can not be written on the lhef (due to format limitation) |
ok very good if that's the algorithm then I agree also with your calculate_wavefunction API... essentially you need to add a jamp2 to the signature, which is a pointer to an array with ncolors real numbers per event, and calling it just adds the contribution for the given helicity.
In practice you need to add one variable, something like
Then internally I would yet another memory buffer and memory access functions for this new type of data structure... |
Hi @valassi, I'm a bit confused about all the assignment in the cudacpp part. I will now concentrate on the change on the madgraph side (including fortran) for the channelID) where I will likely be more usefull than in the cpp part. |
Hi @oliviermattelaer that's fine for me! I think I understood what I need to do on the cudacpp part. I am a bit behind with a few minor issues though (the move to github, and later the makefile cleanup - maybe I can postpone the latter, but I want to move to github and I need to test other bits of my scripts first). Go ahead and I will try to catch up |
current signature is
I do have a couple of question for you @valassi, @roiser:
sigmakin(momenta, coupling, answer, channelid,random_for_helicity [in],selected_hel[out], random_for_color [in], selected_color [out], IEVT)
calculate_wavefunctions(ihel, momenta, coupling, answer, multi_channel_num, multi_channel_denom, channelid, jamp2, iEVT)
The text was updated successfully, but these errors were encountered: