Support for non-SM UFO models: HRDCOD=1 build fails in model SMEFTsim_topU3l_MwScheme_UFO

Generic issue: processes in non-SM models are not always supported (see also #615 )

Speceific issue: Processes in eg model SMEFTsim_topU3l_MwScheme_UFO can be exported through the plugin, but fail at compile time both due to failed assertions and to non-fitting parameter names, see code snippet for full error message.

[zwetters@itscrd80 P1_Sigma_SMEFTsim_topU3l_MwScheme_UFO_gg_ttx]$ make HRDCOD=1
makefile:77: CUDA_HOME was not set: using "/usr/local/cuda-11.8/"
OMPFLAGS=-fopenmp
AVX=512y
FPTYPE=d
HELINL=0
HRDCOD=1
RNDGEN=hasCurand
Building in BUILDDIR=. for tag=512y_d_inl0_hrd1_hasCurand (USEBUILDDIR is not set)
make -C ../../src  -f cudacpp_src.mk
make[1]: Entering directory '/data/zwetters/modded5amc/PROC_PLUGIN_SMEFTsim_topU3l_MwScheme_UFO_3/src'
AVX=512y
g++  -O3  -std=c++17 -I.  -fPIC -Wall -Wshadow -Wextra -ffast-math  -fopenmp -march=skylake-avx512 -mprefer-vector-width=256  -DMGONGPU_FPTYPE_DOUBLE -DMGONGPU_FPTYPE2_DOUBLE -DMGONGPU_HARDCODE_PARAM -c Parameters_SMEFTsim_topU3l_MwScheme_UFO.cc -o Parameters_SMEFTsim_topU3l_MwScheme_UFO.o
In file included from /opt/rh/gcc-toolset-11/root/usr/include/c++/11/cassert:44,
                 from Parameters_SMEFTsim_topU3l_MwScheme_UFO.h:78,
                 from Parameters_SMEFTsim_topU3l_MwScheme_UFO.cc:8:
Parameters_SMEFTsim_topU3l_MwScheme_UFO.h:381:56:   in ‘constexpr’ expansion of ‘Parameters_SMEFTsim_topU3l_MwScheme_UFO::constexpr_pow(2.0e+0, 2.5e-1)’
Parameters_SMEFTsim_topU3l_MwScheme_UFO.h:110:5: error: call to non-‘constexpr’ function ‘void __assert_fail(const char*, const char*, unsigned int, const char*)’
  110 |     assert( static_cast<double>( iexp ) == exp ); // NB would fail at compile time with "error: call to non-‘constexpr’ function ‘void __assert_fail'"
      |     ^~~~~~
/usr/include/assert.h:67:13: note: ‘void __assert_fail(const char*, const char*, unsigned int, const char*)’ declared here
   67 | extern void __assert_fail (const char *__assertion, const char *__file,
      |             ^~~~~~~~~~~~~
Parameters_SMEFTsim_topU3l_MwScheme_UFO.h:384:58:   in ‘constexpr’ expansion of ‘Parameters_SMEFTsim_topU3l_MwScheme_UFO::constexpr_pow(1.0e+1, -4.0e+1)’
Parameters_SMEFTsim_topU3l_MwScheme_UFO.h:107:5: error: call to non-‘constexpr’ function ‘void __assert_fail(const char*, const char*, unsigned int, const char*)’
  107 |     assert( exp >= 0 ); // NB would fail at compile time with "error: call to non-‘constexpr’ function ‘void __assert_fail'"
      |     ^~~~~~
/usr/include/assert.h:67:13: note: ‘void __assert_fail(const char*, const char*, unsigned int, const char*)’ declared here
   67 | extern void __assert_fail (const char *__assertion, const char *__file,
      |             ^~~~~~~~~~~~~
In file included from Parameters_SMEFTsim_topU3l_MwScheme_UFO.cc:8:
Parameters_SMEFTsim_topU3l_MwScheme_UFO.h:385:35: error: ‘ABS’ was not declared in this scope
  385 |   constexpr double mdl_propCorr = ABS( mdl_linearPropCorrections ) / ( ABS( mdl_linearPropCorrections ) + mdl_nb__10__exp___m_40 );
      |                                   ^~~
Parameters_SMEFTsim_topU3l_MwScheme_UFO.h:385:72: error: ‘ABS’ was not declared in this scope
  385 |   constexpr double mdl_propCorr = ABS( mdl_linearPropCorrections ) / ( ABS( mdl_linearPropCorrections ) + mdl_nb__10__exp___m_40 );
      |                                                                        ^~~
Parameters_SMEFTsim_topU3l_MwScheme_UFO.h:398:49: error: call to non-‘constexpr’ function ‘mgOnGpu::cxsmpl<FP> mgOnGpu::conj(const mgOnGpu::cxsmpl<FP>&) [with FP = double]’
  398 |   constexpr cxsmpl<double> mdl_conjg__cbH = conj( mdl_cbH );
      |                                             ~~~~^~~~~~~~~~~
In file included from Parameters_SMEFTsim_topU3l_MwScheme_UFO.h:13,
                 from Parameters_SMEFTsim_topU3l_MwScheme_UFO.cc:8:
mgOnGpuCxtypes.h:66:3: note: ‘mgOnGpu::cxsmpl<FP> mgOnGpu::conj(const mgOnGpu::cxsmpl<FP>&) [with FP = double]’ declared here
   66 |   conj( const cxsmpl<FP>& c )
      |   ^~~~
In file included from Parameters_SMEFTsim_topU3l_MwScheme_UFO.cc:8:
Parameters_SMEFTsim_topU3l_MwScheme_UFO.h:399:50: error: call to non-‘constexpr’ function ‘mgOnGpu::cxsmpl<FP> mgOnGpu::conj(const mgOnGpu::cxsmpl<FP>&) [with FP = double]’
  399 |   constexpr cxsmpl<double> mdl_conjg__ctHH = conj( mdl_ctHH );
      |                                              ~~~~^~~~~~~~~~~~
In file included from Parameters_SMEFTsim_topU3l_MwScheme_UFO.h:13,
                 from Parameters_SMEFTsim_topU3l_MwScheme_UFO.cc:8:
mgOnGpuCxtypes.h:66:3: note: ‘mgOnGpu::cxsmpl<FP> mgOnGpu::conj(const mgOnGpu::cxsmpl<FP>&) [with FP = double]’ declared here
   66 |   conj( const cxsmpl<FP>& c )
      |   ^~~~
In file included from Parameters_SMEFTsim_topU3l_MwScheme_UFO.cc:8:
Parameters_SMEFTsim_topU3l_MwScheme_UFO.h: In function ‘const Parameters_SMEFTsim_topU3l_MwScheme_UFO_dependentCouplings::DependentCouplings_sv Parameters_SMEFTsim_topU3l_MwScheme_UFO_dependentCouplings::computeDependentCouplings_fromG(const fptype_sv&)’:
Parameters_SMEFTsim_topU3l_MwScheme_UFO.h:532:45: error: ‘aS’ was not declared in this scope
  532 |       const fptype_sv mdl_gHgg2 = (  - 7. * aS ) / ( 720. * M_PI );
      |                                             ^~
Parameters_SMEFTsim_topU3l_MwScheme_UFO.h:538:64: error: conversion from ‘fptype_sv’ {aka ‘__vector(4) double’} to non-scalar type ‘const mgOnGpu::cxsmpl<double>’ requested
  538 |       constexpr cxsmpl<double> mdl_G__exp__3 = ( ( G ) * ( G ) * ( G ) );
      |                                                ~~~~~~~~~~~~~~~~^~~~~~~~~
make[1]: *** [cudacpp_src.mk:236: Parameters_SMEFTsim_topU3l_MwScheme_UFO.o] Error 1
make[1]: Leaving directory '/data/zwetters/modded5amc/PROC_PLUGIN_SMEFTsim_topU3l_MwScheme_UFO_3/src'
make: *** [makefile:471: ../../lib/libmg5amc_common.so] Error 2

@zeniheisser

Hi @zeniheisser thanks a lot. Again, we clearly have a lot of work to do...

Now, about this specific one. I am confused, because I cannot recall the status of non-SM models, especially with respect to HRDCOD=1.

Maybe one or two questions to start with: does the build succeed if you go with the default HRDCOD=0? And why did you try HRDCOD=1, is it a functional requirement, an attempt to improve computational performance, or was this just a "random" test? (Good that you reported the issue anyway!).

Let me expand:

I had introduced the HRDCOD=1 option initially as an attempt to improve on computational performance (fewer parameters to read from memory, more stuff that ideally might be hardcoded in the code, smaller register pressure on GPU etc)... see Compile-time const (and constexpr) vs constant-memory constants (layouts; physics parameters?) #23 and Masses/couplings as compile time constants instead of constant memory #39 for the initial ideas three years ago, and then for instance MR Option to hardcode physics parameters (with hacks to remove) #306 for something a bit more recent
The implementation of HRDCOD=1 did imply a lot of changes and additions, in partciular making a lot of parameters and functions constexpr, and the addition of a full "simple complex class" with constexpr arithmetics (see Improved handling of hardcoded parameters using the cxsmpl class #359)
However, I am not sure I ever demonstrated a performance advantage in HRDCOD=1
In addition, I vaguely recalled that there was some issues specifically for non-SM models like EFT, related to HRDCOD. One hour ago I thought that it was impossible to use HRDCOD=1 with EFT and that my code only supports HRDCOD=0 for EFT.... but I checked and it seems that the issue was the opposite, see partial fix for EFT processes after merging alphas (only workd with HRDCOD=1 for now) #446: at some point I was able to run non-SM EFT only with HRDCOD=1 and not with HRDCOD=0. But that particular issue is fixed, so maybe there should not be any issue specific to one HRDCOD type for EFT. But maybe I am still forgetting things.
Even more recently, I think that I oscillated between the idea of dropping HRDCOD=0 and the idea of dropping HRDCOD=1. For the moment both are kind of supported, at least for our "standard" processes, but the situation is still evolving. See for instance Fix heft generation after alphas PR: more fundamentally, remove reading of param_card.dat? #439 and Improve handling of model parameters #448.

Anyway, @zeniheisser : specifically for reweighting, I think we had discussed that it would be better to leave freely-floating parameter variables in the code to allow several reweightings with different parameters sets using the same source code and the same build... right? In this case, my impression is that you should mainly focus on HRDCOD=0, and fixing this issue with HRDCOD=1 becomes lower priority. Do you agree?

@valassi

Hi @valassi , I've added issue #616 regarding the compilation issues for non-hardcoded parameter sets.

For the reweighting project, we do indeed want HRDCOD=0, since we want online reading of tho param_card.

@zeniheisser

Thanks @zeniheisser!

Ok as mentioned in #616 this says it all

In file included from Parameters_SMEFTsim_topU3l_MwScheme_UFO.cc:8:
Parameters_SMEFTsim_topU3l_MwScheme_UFO.h:19:2: error: #error This non-SM physics process only supports MGONGPU_HARDCODE_PARAM builds (#439): please run "make HRDCOD=1"
   19 | #error This non-SM physics process only supports MGONGPU_HARDCODE_PARAM builds (#439): please run "make HRDCOD=1"
      |  ^~~~~

In other words, about my long and confused post above:

indeed I was remembering vaguely correct that there IS a problem with one HRDCOD mode for non-SM EFT
however I was remembering wrong, the problem indeed is in HRDCOD=0, not in HRDCOD=1 (and apparently this is Port code generation to revision 1000 (from 996) in the 311 branch #432

Let's follow up HRDCOD=0 (high priority!) in #616 (and later #439), and HRDCOD=1 (low priority!) here in #614

Cleaning up issues. I opened #634 but I believe it is a duplicate of this #614 (for HRDCOD=1, while #616 is for HRDCOD=0).

I believe Zenny means this process
9788926

cmd="import model SMEFTsim_topU3l_MwScheme_UFO -massless_4t; generate g g > t t~ t t~"

I opened a WIP PR #632 to investigate that. For details of the build errors, see also 44a78a8

(Note this is related to #39 - also to #23, but I have now closed the latter)

I have retried the smeft_gg_tttt builds in PR #632 after merging in also the latest 'susy2' fixes from PR #625. There are still many failures for both HRDCOD=0 (#616) and HRDCOD=1 (#614).

Concerning HRDCOD=1, this is a (non-exhaustive?) list:

In file included from CPPProcess.h:22,
                 from Bridge.h:11,
                 from fsampler.cc:8:
../../src/Parameters_SMEFTsim_topU3l_MwScheme_UFO.h:121:31: error: exponent has no digits
  121 |     constexpr double mdl_WH = 4.070000e - 03;
      |                               ^~~~~~~~~

In file included from /usr/include/c++/11/cassert:44,
                 from ../../src/constexpr_math.h:11,
                 from ../../src/Parameters_SMEFTsim_topU3l_MwScheme_UFO.h:23,
                 from CPPProcess.h:22,
                 from Bridge.h:11,
                 from fsampler.cc:8:
../../src/Parameters_SMEFTsim_topU3l_MwScheme_UFO.h:384:58:   in ‘constexpr’ expansion of ‘mg5amcCpu::constexpr_pow(((long double)2.0e+0), ((long double)2.5e-1))’
../../src/constexpr_math.h:55:5: error: call to non-‘constexpr’ function ‘void __assert_fail(const char*, const char*, unsigned int, const char*)’
   55 |     assert( static_cast<long double>( iexp ) == exp ); // NB would fail at compile time with "error: call to non-‘constexpr’ function ‘void __assert_fail'"
      |     ^~~~~~

In file included from CPPProcess.h:22,
                 from Bridge.h:11,
                 from fsampler.cc:8:
../../src/Parameters_SMEFTsim_topU3l_MwScheme_UFO.h:388:37: error: ‘ABS’ was not declared in this scope
  388 |     constexpr double mdl_propCorr = ABS( mdl_linearPropCorrections ) / ( ABS( mdl_linearPropCorrections ) + mdl_nb__10__exp___m_40 );
      |                                     ^~~

In file included from CPPProcess.h:22,
                 from Bridge.h:11,
                 from fsampler.cc:8:
../../src/Parameters_SMEFTsim_topU3l_MwScheme_UFO.h: In function ‘const mg5amcCpu::Parameters_SMEFTsim_topU3l_MwScheme_UFO_dependentCouplings::DependentCouplings_sv mg5amcCpu::Parameters_SMEFTsim_topU3l_MwScheme_UFO_dependentCouplings::computeDependentCouplings_fromG(const fptype_sv&, const fptype*)’:
../../src/Parameters_SMEFTsim_topU3l_MwScheme_UFO.h:554:45: error: ‘aS’ was not declared in this scope
  554 |         const fptype_sv mdl_gHgg2 = ( -7. * aS ) / ( 720. * M_PI );
      |                                             ^~
../../src/Parameters_SMEFTsim_topU3l_MwScheme_UFO.h:560:66: error: conversion from ‘mg5amcCpu::fptype_sv’ {aka ‘__vector(4) double’} to non-scalar type ‘const mgOnGpu::cxsmpl<double>’ requested
  560 |         constexpr cxsmpl<double> mdl_G__exp__3 = ( ( G ) * ( G ) * ( G ) );
      |                                                  ~~~~~~~~~~~~~~~~^~~~~~~~~

../../src/Parameters_SMEFTsim_topU3l_MwScheme_UFO.h(121): warning #2506-D: a user-provided literal suffix must begin with "_"

Remark: The warnings can be suppressed with "-diag-suppress <warning-number>"

../../src/Parameters_SMEFTsim_topU3l_MwScheme_UFO.h(121): error: user-defined literal operator not found

[smeft] regenerate smeft_gg_tttt.sa after merging susy2 - generation …

[smeft2] regenerate smeft_gg_tttt after merging susy - codegen is ok …

In file included from CPPProcess.h:22,
from Bridge.h:11,
from fsampler.cc:8:
../../src/Parameters_SMEFTsim_topU3l_MwScheme_UFO.h:121:31: error: exponent has no digits
121 | constexpr double mdl_WH = 4.070000e - 03;
| ^~~~~~~~~

This might be related to clang formatting issue #633?

[smeft2] regenerate smeft_gg_tttt.sa - now exponent literals are fixed …

[smeft2] in smeft_gg_tttt.sa, manually fix mdl_G__exp__3 (need backport)

[smeft2] in smeft_gg_tttt, handle negative exponents in constexpr_pow

[smeft2] in smeft_gg_tttt, complete the fix for HRDCOD=1 builds madgr…

[smeft2] in smeft_gg_tttt.sa, add some tests for constexpr_pow with n…

[smeft2] in CODEGEN, backport from smeft_gg_tttt the final HRDCOD=1 f…

@zeniheisser

Hi @zeniheisser this is in principle also fixed in PR #632. Thanks for reporting also this one!

In summary, the folowing issues had to be fixed (I may be forgetting some)

ABD becomes std::abs
literals with exponents were treated wrongly in clang formatting postfixes fix formatting in SMEFT generation #633
the handling of aS, G, sqrt(aS), G^2, G^3 had to be adapted to computing couplings from G and not from aS (this is the same as in Support for non-SM UFO models: standard build, HRDCOD=0 build fails in model SMEFTsim_topU3l_MwScheme_UFO #616 for HRDCOD=0)
specifically in HRDCOD=1, constexpr_pow had to be ported to negative exponents
specifically in HRDCOD=1, constrexpr_pow had to be ported to selected non integer exponents like 0.5 and 0.25

I am following up in PR #632, where there are still a few CI issues (fixing one process breaks another, as usual)

I will close this for the time being

cc @oliviermattelaer @roiser

Navigation Menu

Repository navigation

Support for non-SM UFO models: HRDCOD=1 build fails in model SMEFTsim_topU3l_MwScheme_UFO #614

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Support for non-SM UFO models: HRDCOD=1 build fails in model SMEFTsim_topU3l_MwScheme_UFO #614

Description

Activity

valassi commented on Mar 29, 2023

zeniheisser commented on Mar 30, 2023

valassi commented on Mar 30, 2023

valassi commented on Apr 7, 2023

valassi commented on May 22, 2023

valassi commented on Feb 29, 2024

valassi commented on Mar 19, 2024

valassi commented on Mar 20, 2024

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions