Running of alphas (QCD coupling)

@roiser

Hi @roiser @oliviermattelaer I dumo here a few questions/ideas that we just discussed with Stefan.

Olivier can you please correct me if I am wrong? :-)

First point, what is this about and what this implies in the calculations

(Note: focus on the default stream, reading from cards. I implemented an optional 'hardcoded' stream too, but it may be incomplete, or in any case its not the main point).

Currently

We currently have one aS value that is a constant 0.118 (read from card or hardcoded in Parameters.h).
There are some other parameters like G, sqrtaS etc which depend on aS (in Parameters again, either from card or hardcoded constexpr calculations)
There are then model couplings like GC10, GC11, which depends on all these parameters aS, G, sqrtaS etc
CPPProcess in an init phase propagates the model parameters GC10, GC11 to the constants cIPC (CUDA constant memory, or static c++ memory... not even sure if there is some hardcoding done here actually?)
CPPProcess in every event calculation passes the appropriate cIPC[i] constants to the FFV functions
The FFV functions assume that each coupling is a constant: even if FFV in vector C++ or in CUDA is able to handle several events at the same time, the same constant couplings are always used

What we need because of physics:

aS = aS0 * f(Q2)

In practice:

The valuse of aS to be used is different from one event to another: the aS0=0.118 constant needs to be multiplied by a factor f(Q2) which depends on the "scale" Q2.
The scale Q2 actually depends on the momenta of the external particles (and more? I will come back to this later)
This means that the values of G, sqrtaS etc should also depend event by event
This means that GC10, GC11 etc and the cIPC should also depend event by event
This means that the couplings that enter the FFV should also depend event by event

Knowing the running value of aS - i.e knowing the factor f(Q2), how can this be propagated to ME calculations?

2a) The part before FFV: keep the constants as they are to represent as0?

Changing the existing Parameters and cIPC infrastructure would be too complex, and would probably be a wrong idea. I think that I would keep the existing stuff up until the cIPC, which are still constants and can still in constant CUDA memory and static const c++ memory. Essentially the cIPC constants represent the values of the constants based on the reference value aS0.

One would then a function (in Parameters? something that can be easily code generated!) that describes how each of the parameters would change.

Luckily all of these are multiplicative factors with a given exponent?
Example, if aS must be multiplied by 1.10 i.e. a 10% change, sqrtaS must be multiplied by sqrt(1.10) ie a 5% change

Given these formulas, one can then inside CPPProcess, for each event, BEFORE calling the FFVs, determine a "running" or "variable" vIPC, i.e. vIPC[0]=cIPC[0]*formula_for_cIPC0(fQ2)

This vIPC then needs to be applied to the individual FFV functions

2b) The part inside/after FFV: apply the running as multiplicative factors?

How can then these be propagated to the FFV? There are two ways:

First way, change the interfaces of the FFVs to have a vector of values, one per event, instead of a constant which is the same for all events. This would significantly complicate the code: for instance in CUDA these vIPC themselves would need to be arrays in global memory. For vector C++ each coupling would be a cxtype_sv instead of a cxtype.
Second way: apply the appropriate factor in CPPProcess to the result of esach FFV, AFTER FFV has been called with a constant parameter. This assumes that the dependency of the result of an FFV on f(Q2) is itself a multiplicative factor, but that different FFV functions have different dependencies (example: you may have one diagrams where you have one gluon propagator, but interefering with a diagram where there is no gluon propagator, so the first diagrams and its FFVs scale by aphas, the second does not?)
Third way: if we may assume that the same scaling applies to all diagrams, then we can just calculate one multiplicative factor to the final sum of all diagrams... but I imagine this would be wrong for physics, and too much of an approximation?

Third part: how to get the factor f(Q2) for the scaling of alphas?

If I understand correctly, we need two formulas/algorithms:

one, the exact formula for the multiplicative factor f(Q2) in as=as0*f(q2) given the scale Q2
two, how do we compute the scale Q2 for one given event

For the Fortran-C++ interaction, I guess this can be done in three ways:

the fortran computes the scale q2 and computes the multiplicative factor f(q2) for each event: the fortran passes f(q2) to c++
the fortran computes the scale q2 for each event and passes it to the c++: the c++ then computes the formula f(q2)
the fortran does nothing and only passes momenta to c++: the c++ computes the scale q2 from the momenta in each event, and then computes f(q2) for each event

If this third option is possible, it would be my preferred one. Essentially, we would also need to implement in C++ the formula for computing Q2 from the momenta... but maybe this is too complex or impossible,Olivier?

Voila, long brain dump - comments more than welcome! Andrea

Voila, long brain dump - comments more than welcome! Andrea

In general the matrix-element can be written as

a_s^N |M_0|^2 + 2 a_s^(N-1) Re(M_0^*M_1)  + a_s^(N-2) |M_1|^2

In practise for most computation, only the first term is present.
and for the rest the second term is typically very small (and the last one as well)

Knowing the dependence in each coupling allows to do such computation exactly in a easy way.
But if you want to keep CIPC constant, then the best is likely to let fortran to handle the running
(even if they are restriction for the moment or if this is not perfect).

(even if they are restriction for the moment or if this is not perfect).

but if we can do better, why not do it? I mean the option 1 above for passing the data upfront into the FFV functions would mean to change one parameter type to become a vector instead of a scalar. We are still in R&D, moreover nobody outside will depend on those functions, we are free to modify in any direction we'd like.

Hi, Stefan I kind of agree with you that we could try something 'better' if possible, as we are in R&D. It is more complex than changing one parameter from scalar to vector however, sorry I was a bit simplistic. Changing cxtype to cxtype_sv would work for vector C++, but for CUDA we need something more complex. Essentially we need another MemoryBuffer for couplings, in global memory, with its own accessor, like for momenta, wabevfunctions and everything else that varies event by event. Before doing that I would still investigate if we can do something simpler, eg running FFV as-is with constant parameters, and changing the result of FFV a posteriori for each event. Anyway, up to you to try out options!

One important question however - for Olivier: what is done in the all-Fortran version now? From what you say, I seem to understand that there is now an approximation, of the type you mention? I think that we shoudl keep this in two steps: FIRST, try to reproduce exactly the Fortran-only results through our new Fortran-C++/CUDA chain, and for this we should use whatever approximation (if any) is done in Fortran now; SECOND, if we can do it 'better', this would actually changing physics results (to make them more "accurate" if anything), but then this becomes also a physics work, not just a software work,.. this would require a lot of physics studies too, maybe very interesting, but I would keep this as a second step. Am I misunderstanding, is there no approximation at all now?

@oliviermattelaer

Just to recap from our discussion yesterday in the Madgraph meeting. @oliviermattelaer thinks that if we go down the "complicated" route the computation of the scales would make sense only in Fortran (at least for now), then pass them on to the Cuda/C++ and do the rest there. This would also have the advantage that we can profit from eventual SIMD/T processing which may be better developed there as in Fortran.

Having said this, for a first approach for our goal of the full workflow it seems sensible to stay even stay as is and compute with a fixed value of alpahS. So the approach above can come later but I would start continue looking into it.

[v311] in ggtt.mad, use a fixed renormalization scale: now the 0-30% …

For the input from fortran, the list of coupling are currently store in a common block

      DOUBLE PRECISION G, ALL_G(nb_page)
      COMMON/STRONG/ G, ALL_G

that we can pass to the bridge now.

@oliviermattelaer

Thanks @oliviermattelaer , just to say the latest version of alphaS calculations is now available in #428 , this exposes the Gs on the bridge to be passed in. @valassi wanted to take care of merging that in.

[v311] in ggtt.mad, use a fixed renormalization scale: now the 0-30% …

[alphas] add a comment in mgOnGpuConfig.h: MGONGPU_HARDCODE_CIPC is n…

@oliviermattelaer

Thanks @oliviermattelaer and @roiser.

I am working on Stefan's #428. There were quite a few things missing (tests failing, and code generation to be done). That is now superseded by PR #434.

Many issues are fixed (all tests are passing), but the code generation is not there yet. One issue is that gc10/gc11 are process specific for ggtt, but for instance do not exist in eemumu. So I would leave only the gs as a high level interface, and move gc10 and gc11 to "internal implementation" not exposed in the bridge for instance, Technically, computing the dependent couplings becomes one instance of "splitting kernels" #310 and there are quite a few issues to solve there about the best APIs and responsibilities for the classes, eg CPPProcess and MEK #356. In practice: where should the orchestration of kernels be, in MEK or in CPPProcess? This is relevant to code generation because the prchestartion of kernels (how many kernels you have and in which order you run them) is process specific. Until now MEK was a process agnostic class. So I have a decision to make, departing from what was done so far

either MEK starts including process specific stuff, unlike what it did so far
or CPPProcess starts taking the role of launching kernels, which so far was exactly the role of MEK

I will have a look... I am copying bits of this comment to #356

To be concrete, I am typically playing with these 5 processes. They have a different number of dependent couplings (ie running couplings dependent on G which depends on the running coupling constant alphas QCD - "running" here is the important point as they change event by event):

eemumu: 0
ggtt: 2 (gc10, gc11)
ggttg, ggttgg, ggttggg: 3 (gc10, gc11, gc12 - I guess because there is a three-gluon vertex that is missing in ggtt)

I am inclined to add a new parameter ndcoup that must be auto generated, and then have some arrays dimensioned according to this. May not be the best or most elegant, but should be an effective way to handle code generation.

Note by the way that some cleanup is also neeed in parameters_sm: should remove code that is no longer used there with running parameters. This is where I got the 0,2,3 above:

madgraph4gpu/epochX/cudacpp/ee_mumu/src/Parameters_sm.cc

Line 100 in c0c2768

Parameters_sm::setDependentCouplings()

void
Parameters_sm::setDependentCouplings()
{
  // (none)
}

madgraph4gpu/epochX/cudacpp/gg_tt/src/Parameters_sm.cc

Line 98 in c0c2768

Parameters_sm::setDependentCouplings()

void
Parameters_sm::setDependentCouplings()
{
  GC_10 = -G;
  GC_11 = mdl_complexi * G;
}

https://github.com/madgraph5/madgraph4gpu/blob/master/epochX/cudacpp/gg_ttg/src/Parameters_sm.cc#L98

void
Parameters_sm::setDependentCouplings()
{
  GC_10 = -G;
  GC_11 = mdl_complexi * G;
  GC_12 = mdl_complexi * mdl_G__exp__2;
}

[alphas] FINALLY COMPLETE (the first draft of) alphas code generation m…

All issues specific to alphas discusseds above are solved in PR #434, extending Stefan's #428

There are a few related issues for which I opened specific tickets

Fix heft generation after alphas PR: more fundamentally, remove reading of param_card.dat? #439 fix heft generation (computation of couplings from Gs involves extra parameters from the run cards), low priority (SM for LHC is more urgent)
Fix uudd in generation after the alphas merge #440 fix uudd generation (hopefully something easy to fix), relatively urgent but hopefully easy
Fix eemumu.mad generation and build after the alphas merge (integrate alphas and madevent) #441 fix eemumu.mad (this is a big thing, the integration of alphas with madevent... so far AlphaS against latest master, including code generation and all processes generated #434 only does the cudacpp internals), this is on the critical path to giving something to the experiments, anyway
Further analysis of possible performance regressions after the alphas merge #442 further analysis of possible performance regression from access to Gs in global memory (if required...), low priority

I keep this open, until #441 (and maybe #440) is fixed

[alphas] fix build error in eemumu.mad - simply add ALL_G from COUPL.…

The main issues #439 #440 #441 are now fixed.

In particular, PR #452 which fixed #441 has made the connections between Olivier's common block in Fortran that includes "ALL_G" for different events, and their passing to the cudacpp ME calculation.

This is now visible in my basic test that prints the ME ration of Fortran to cudacpp (as Stefan was doing long ago), and the ratios are 1 within 1E-5 approximately. Using the code as of f47d792 :

[avalassi@itscrd70 gcc10.2/cvmfs] /data/avalassi/GPU2020/madgraph4gpuX/epochX/cudacpp/gg_tt.mad/SubProcesses/P1_gg_ttx> ./cmadevent_cudacpp < ../../../tmad/input_app_32_NOMULTICHANNEL.txt 
...
 RESET CUMULATIVE VARIABLE
           1   4.6182608990112390        4.6181273891615433       0.99997109088191094     
           2  0.60252293500494236       0.60252183592588349       0.99999817587182993     
           3   1.2697813614637803        1.2697513424598017       0.99997635891903158     
           4  0.54484902779458555       0.54484824660223097       0.99999856622235750     
           5  0.76323157167443523       0.76321402714356967       0.99997701283395934     
           6  0.66658145068521324       0.66656886764286083       0.99998112302354125     
           7  0.69265224314349227       0.69265203077847282       0.99999969340311601     
           8   1.3070873420157496        1.3070823390707818       0.99999617244784866     
           9  0.57494117895574948       0.57493376239149818       0.99998710030778315     
          10   1.3737455291731311        1.3736890122704315       0.99995885926359762     
          11   2.5512621477068183        2.5511256968840423       0.99994651634568466     
          12   3.0444961031701920        3.0444224487081741       0.99997580733904001     
          13   1.1989126430170438        1.1988757636830032       0.99996923934845849     
          14  0.62986569391736302       0.62986436593363027       0.99999789163984387     
          15   3.6851822927868878        3.6849721923561218       0.99994298777805990     
          16  0.39131939347151284       0.39132140461748860        1.0000051393976617     
           1  0.65071856364074121       0.65071648593614995       0.99999680706113614     
           2   1.5303170018862482        1.5302579024461138       0.99996138091646269     
           3  0.39977968375900230       0.39978126769444428        1.0000039620208487     
           4  0.60049579415833465       0.60048977557962091       0.99998997731745620     
           5   1.3767882290236673        1.3767310485696183       0.99995846822856005     
           6  0.97505269937164596       0.97502195861510155       0.99996847272299827     
           7   1.4775366417437557        1.4774845126132687       0.99996471889155625     
           8   1.8649258991436954        1.8648361339852217       0.99995186663528302     
           9   25.550816733318090        25.549341521565346       0.99994226361653560     
          10   2.0063985699944311        2.0062990469149713       0.99995039715391143     
          11  0.45725262005879863       0.45725233927902253       0.99999938594167914     
          12  0.69970932144807696       0.69969645659449897       0.99998161400286711     
          13   1.9571485539330018        1.9570566621036405       0.99995304810706542     
          14   3.9021397781346892        3.9019140788720001       0.99994216012866743     
          15  0.64597046901043231       0.64596846146865661       0.99999689220812404     
          16  0.39115843944747675       0.39116041348730574        1.0000050466502315     
 Iteration  1   Mean: 0.8324E+03 Abs mean: 0.8324E+03   Fluctuation:  0.345E+03   0.800E+04   100.0%
...

For comparison, in c0c2768 before PR #434 the same was giving

[avalassi@itscrd70 gcc10.2/cvmfs] /data/avalassi/GPU2020/madgraph4gpuX/epochX/cudacpp/gg_tt.mad/SubProcesses/P1_gg_ttx> ./cmadevent_cudacpp < ../../../tmad/input_app_32_NOMULTICHANNEL.txt 
...
 RESET CUMULATIVE VARIABLE
           1   4.6182608990112390        3.8048997495080039       0.82388150706743868     
           2  0.60252293500494236       0.49642094931550251       0.82390382253487249     
           3   1.2697813614637803        1.0461548930420270       0.82388584743127680     
           4  0.54484902779458555       0.44890337193428720       0.82390414414675073     
           5  0.76323157167443523       0.62881610141698518       0.82388638619526811     
           6  0.66658145068521324       0.54918963982598723       0.82388977260235352     
           7  0.69265224314349227       0.57067969683783715       0.82390507283698078     
           8   1.3070873420157496        1.0769120999539372       0.82390217190318493     
           9  0.57494117895574948       0.47369098861178799       0.82389469731867260     
          10   1.3737455291731311        1.1317896927132225       0.82387142937197122     
          11   2.5512621477068183        2.1018860475392533       0.82386125997617177     
          12   3.0444961031701920        2.5083158683912758       0.82388539298158436     
          13   1.1989126430170438       0.98776012624391241       0.82387998157916698     
          14  0.62986569391736302       0.51894860539999155       0.82390358835462540     
          15   3.6851822927868878        3.0360682133944707       0.82385835277051378     
          16  0.39131939347151284       0.32241178922449132       0.82390955982088876     
           1  0.65071856364074121       0.53612877811686066       0.82390269476445266     
           2   1.5303170018862482        1.2607876351277905       0.82387350697519568     
           3  0.39977968375900230       0.32938191546612056       0.82390858977386316     
           4  0.60049579415833465       0.49474672397459363       0.82389706770226301     
           5   1.3767882290236673        1.1342960426203157       0.82387110719612122     
           6  0.97505269937164596       0.80332578412761235       0.82387934995236700     
           7   1.4775366417437557        1.2173073582027885       0.82387625715065149     
           8   1.8649258991436954        1.5364484218704257       0.82386566810826412     
           9   25.550816733318090        21.050238541199739       0.82385775612997814     
          10   2.0063985699944311        1.6530004691860378       0.82386445739473679     
          11  0.45725262005879863       0.37673263740361568       0.82390481951786565     
          12  0.69970932144807696       0.57648363678235448       0.82389017712283452     
          13   1.9571485539330018        1.6124294061024296       0.82386664152915756     
          14   3.9021397781346892        3.2148077890067244       0.82385767086577177     
          15  0.64597046901043231       0.53221685547275532       0.82390276491750913     
          16  0.39115843944747675       0.32227914777498462       0.82390948340578762     
 Iteration  1   Mean: 0.8324E+03 Abs mean: 0.8324E+03   Fluctuation:  0.345E+03   0.800E+04   100.0%
...

Here the ratio was constant (thanks to the fact that I disabled multichannel), but not 1, because a hardcoded value of alphas (without any running) was used.

Note however that in both cases I was using running of alphas disabled in some cards? I need to cross check this

Note however that in both cases I was using running of alphas disabled in some cards? I need to cross check this

Yes indeed in commit 6dd0db2 I changed

diff --git a/epochX/cudacpp/gg_tt.mad/Cards/run_card.dat b/epochX/cudacpp/gg_tt.mad/Cards/run_card.dat
index f1b9e8f8..5ca0f52a 100644
--- a/epochX/cudacpp/gg_tt.mad/Cards/run_card.dat
+++ b/epochX/cudacpp/gg_tt.mad/Cards/run_card.dat
@@ -50,8 +50,8 @@
 #*********************************************************************
 # Renormalization and factorization scales                           *
 #*********************************************************************
- False = fixed_ren_scale  ! if .true. use fixed ren scale
-     False = fixed_fac_scale  ! if .true. use fixed fac scale
+ True = fixed_ren_scale  ! if .true. use fixed ren scale
+ False = fixed_fac_scale  ! if .true. use fixed fac scale
  91.188  = scale            ! fixed ren scale
  91.188  = dsqrt_q2fact1    ! fixed fact scale for pdf1
  91.188  = dsqrt_q2fact2    ! fixed fact scale for pdf2
diff --git a/epochX/cudacpp/gg_tt.mad/Source/run_card.inc b/epochX/cudacpp/gg_tt.mad/Source/run_card.inc
index 44635429..48074308 100644
--- a/epochX/cudacpp/gg_tt.mad/Source/run_card.inc
+++ b/epochX/cudacpp/gg_tt.mad/Source/run_card.inc
@@ -36,7 +36,7 @@
 
       LHAID = 230000
 
-      FIXED_REN_SCALE = .FALSE.
+      FIXED_REN_SCALE = .TRUE.
 
       FIXED_FAC_SCALE1 = .FALSE.

If I now check with event-by-event running of alphas:

\cp  ../../Cards/run_card_default.dat ../../Cards/run_card.dat

I also need to rebuild. This creates a new .inc that gets linked.

Using the old c0c2768 before PR #434 I was getting

[avalassi@itscrd70 gcc10.2/cvmfs] /data/avalassi/GPU2020/madgraph4gpuX/epochX/cudacpp/gg_tt.mad/SubProcesses/P1_gg_ttx> ./cmadevent_cudacpp < ../../../tmad/input_app_32_NOMULTICHANNEL.txt 
...
 RESET CUMULATIVE VARIABLE
           1   3.5665107131744436        3.8048997495080039        1.0668409702101742     
           2  0.45750753393963106       0.49642094931550251        1.0850552449722197     
           3   1.0034869585255990        1.0461548930420270        1.0425196701899535     
           4  0.42736056050249699       0.44890337193428720        1.0504089834739543     
           5  0.62208668391557365       0.62881610141698518        1.0108174916380701     
           6  0.54427805795509532       0.54918963982598723        1.0090240306385769     
           7  0.42777117870194153       0.57067969683783715        1.3340770141867602     
           8  0.90719516691836111        1.0769120999539372        1.1870787447116646     
           9  0.46940856376493523       0.47369098861178799        1.0091230224103820     
          10   1.1211030838709168        1.1317896927132225        1.0095322267827569     
          11   2.0814056569772625        2.1018860475392533        1.0098396919857198     
          12   2.3377317419203960        2.5083158683912758        1.0729699320978328     
          13  0.96639301107661646       0.98776012624391241        1.0221101714544600     
          14  0.47219747839080861       0.51894860539999155        1.0990075744760541     
          15   2.9999390801816128        3.0360682133944707        1.0120432889626114     
          16  0.31943068952450482       0.32241178922449132        1.0093325400399820     
           1  0.49352008663987490       0.53612877811686066        1.0863362862636179     
           2   1.2387754214196172        1.2607876351277905        1.0177693335915139     
           3  0.32641446184474765       0.32938191546612056        1.0090910605020444     
           4  0.48419754170306206       0.49474672397459363        1.0217869389308072     
           5   1.1241654439875644        1.1342960426203157        1.0090116616614870     
           6  0.79551174010509906       0.80332578412761235        1.0098226633606702     
           7   1.1905375807398626        1.2173073582027885        1.0224854535430035     
           8   1.5222331121596433        1.5364484218704257        1.0093384578204416     
           9   20.527314687202445        21.050238541199739        1.0254745378031986     
          10   1.6377557144388479        1.6530004691860378        1.0093083202902535     
          11  0.37093260175527626       0.37673263740361568        1.0156363598694029     
          12  0.56844879445413321       0.57648363678235448        1.0141346809186866     
          13   1.5926397221564033        1.6124294061024296        1.0124257129033749     
          14   3.1771304607040958        3.2148077890067244        1.0118589175888857     
          15  0.49032034992343876       0.53221685547275532        1.0854472092701404     
          16  0.31941863974661144       0.32227914777498462        1.0089553572410250     
 Iteration  1   Mean: 0.6464E+03 Abs mean: 0.6464E+03   Fluctuation:  0.271E+03   0.645E+04   100.0%
...

With the latest code this is now ok! This is commit 4f900d9 in PR #453

[avalassi@itscrd70 gcc10.2/cvmfs] /data/avalassi/GPU2020/madgraph4gpuX/epochX/cudacpp/gg_tt.mad/SubProcesses/P1_gg_ttx> ./cmadevent_cudacpp < ../../../tmad/input_app_32_NOMULTICHANNEL.txt 
...
 RESET CUMULATIVE VARIABLE
           1   3.5665107131744436        3.5664076084950689       0.99997109088191050     
           2  0.45750753393963106       0.45750669938725042       0.99999817587183004     
           3   1.0034869585255990        1.0034632350091610       0.99997635891903081     
           4  0.42736056050249699       0.42735994776248010       0.99999856622235761     
           5  0.62208668391557365       0.62207238390567887       0.99997701283395946     
           6  0.54427805795509532       0.54426778363100825       0.99998112302354114     
           7  0.42777117870194153       0.42777104754863132       0.99999969340311656     
           8  0.90719516691836111       0.90719169458154836       0.99999617244784877     
           9  0.46940856376493523       0.46940250853893922       0.99998710030778426     
          10   1.1211030838709168        1.1210569608644638       0.99995885926359795     
          11   2.0814056569772625        2.0812943357966138       0.99994651634568421     
          12   2.3377317419203960        2.3376751859689477       0.99997580733903979     
          13  0.96639301107661646       0.96636328419795126       0.99996923934845916     
          14  0.47219747839080861       0.47219648282845950       0.99999789163984421     
          15   2.9999390801816128        2.9997680469889678       0.99994298777806023     
          16  0.31943068952450482       0.31943233120584363        1.0000051393976617     
           1  0.49352008663987490       0.49351851086041021       0.99999680706113625     
           2   1.2387754214196172        1.2387275810481315       0.99996138091646114     
           3  0.32641446184474765       0.32641575510565102        1.0000039620208494     
           4  0.48419754170306206       0.48419268874481292       0.99998997731745587     
           5   1.1241654439875644        1.1241187554052836       0.99995846822855972     
           6  0.79551174010509906       0.79548665978611088       0.99996847272299860     
           7   1.1905375807398626        1.1904955772543695       0.99996471889155569     
           8   1.5222331121596433        1.5221598419580713       0.99995186663528290     
           9   20.527314687202445        20.526129514290172       0.99994226361653571     
          10   1.6377557144388479        1.6376744770942142       0.99995039715391154     
          11  0.37093260175527626       0.37093237398102596       0.99999938594167992     
          12  0.56844879445413321       0.56843834295622875       0.99998161400286811     
          13   1.5926397221564033        1.5925649447066856       0.99995304810706565     
          14   3.1771304607040958        3.1769466958870427       0.99994216012866766     
          15  0.49032034992343876       0.49031882610983851       0.99999689220812371     
          16  0.31941863974661144       0.31942025174076361        1.0000050466502313     
 Iteration  1   Mean: 0.6464E+03 Abs mean: 0.6464E+03   Fluctuation:  0.271E+03   0.645E+04   100.0%
...

[alphas2] go back to variable renormalization scales! proper test of …

NB THE TICKET WHERE I WAS DISCUSSING THIS IS #417

[alphas2] go back to variable renormalization scales! proper test of …

[alphas2] in ggtt.mad, go back to variable renormalization scales! pr…

[alphas2] in codegen, keep the default run_card_default for madgraph5…

I am about to merge PR #453 where I move back to variable renormalization scales (ie truly running alphas event by event) and all results are the same in Fortran and Cudacpp. I will close this #373 about running alphas.

I will keep the other #417 open for the moment as I want to implement some more automatic tests that frtran and cudacpp are the same, in a less verbse way - and possibly add performance comparisons. The same infrastructure will then be used also when I integrate multichannel too.

[alphas] FINALLY COMPLETE (the first draft of) alphas code generation m…

Navigation Menu

Repository navigation

Running of alphas (QCD coupling) #373

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Running of alphas (QCD coupling) #373

Description

Activity

oliviermattelaer commented on Feb 4, 2022

roiser commented on Feb 4, 2022

valassi commented on Feb 4, 2022

roiser commented on Feb 8, 2022

oliviermattelaer commented on Apr 13, 2022

roiser commented on Apr 14, 2022

valassi commented on Apr 22, 2022

valassi commented on Apr 22, 2022

valassi commented on Apr 28, 2022

valassi commented on May 11, 2022

valassi commented on May 11, 2022

valassi commented on May 11, 2022

valassi commented on May 11, 2022

valassi commented on May 11, 2022

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions