Skip to content

Adding vectorization causes runtime crashes #72

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

Closed
phbasler opened this issue Apr 25, 2022 · 7 comments · Fixed by #81
Closed

Adding vectorization causes runtime crashes #72

phbasler opened this issue Apr 25, 2022 · 7 comments · Fixed by #81
Labels
bug Something isn't working Closed in dev Already closed on dev branch

Comments

@phbasler
Copy link
Owner

Enabling vectorization causes runtime crashes for the following cases :

  • ./bin/NLOVEV --model=c2hdm --input=../example/C2HDM_Input.dat --output=test.tsv --firstline=2 --lastline=2 --logginglevel::minimizerdetailed=true --usenlopt=false --usecmaes=true --usegsl=false

The output is

scale = 246.21965079413735

The parameters are :
Model = c2hdm
v1 = 51.821572673754901
v2 = 240.70446826514393
Type = 1
beta = 1.3587417745617172
tan(beta) = 4.6448700000000001
Lambda1 = 3.2977099999999999
Lambda2 = 0.27436500000000003
Lambda3 = 4.7101899999999999
Lambda4 = -2.2305600000000001
Re(Lambda5) = -2.4348700000000001
Im(Lambda5) = 0.124948
Re(m_12^2) = 2706.8600000000001
m_{11}^2 = 6848.3864902595169
m_{22}^2 = -7425.5052145070022
Im(m_{12}^2) = 779.28094015725787
The counterterms are :
DL1 := -0.81649281983764077;
DL2 := -0.23179166172254051;
DL3 := -0.31592013889976567;
DL4 := 0;
DRL5 := 0.0059778481940300221;
DIL5 := 0.00075049929039023157;
Du1 := 13650.294507496787;
Du2 := 5790.985213930122;
DRu3 := 324.25021058456684;
DIu3 := 15.518870824317741;
DT1 := 3.4924596548080444e-10;
DT2 := -4.0745362639427185e-10;
DT3:= -1.8076207197736949e-11;
DIL6:= -0.0010738943964985043;
The mass spectrum is given by :
m_{H^+} = 393.15971555164003 GeV
m_{H_SM} = 125.09018041136909 GeV
m_{H_l} = 148.85686877185759 GeV
m_{H_h} = 401.08568710658915 GeV
The neutral mixing Matrix is given by :
H_{SM} = 0.356308469806426 zeta_1 +0.93426012933457603 zeta_2 +0.014222695945029097 zeta_3
H_{l} = -0.93399352344040287 zeta_1 +0.35655539009132092 zeta_2 -0.022898732895235179 zeta_3
H_{h} = 0.026464552057130369 zeta_1 +0.0051248934201121718 zeta_2 -0.99963661545175864 zeta_3

Waiting for CMAes Thread
double free or corruption (out)
[2] 15581 abort (core dumped) ./bin/NLOVEV --model=c2hdm --input=../example/C2HDM_Input.dat --firstline=2

@phbasler phbasler added the bug Something isn't working label Apr 25, 2022
@lisabiermann
Copy link
Collaborator

CMAES seems to find one minimum candidate for this parameter point...

Waiting for CMAes Thread
CMAES candidate at T = 0 : 1.31355e-06	51.8216	240.704	1.23891e-06 with potential value = -7.99882e+07

omega_CB = 0.000001 GeV
omega_1 = 51.821573 GeV
omega_2 = 240.704469 GeV
omega_CP = 0.000001 GeV

@phbasler
Copy link
Owner Author

@lisabiermann on the branch for this?

@cborschensky
Copy link

Adding -march=native also to the compiler flags of CMAES seems to make this particular issue go away. Maybe there is some interference with optimization going on when -march=native is enabled for the main code, but not for CMAES?

@phbasler
Copy link
Owner Author

@cborschensky Thanks for the info! Did you install cmaes by hand and added it there?
When I recreated it, I got cmaes through fetch_content so I assumed that everything has the same compile flags.

But I also get the issue if I use gsl or nlopt instead of cmaes.
But this is definitly a point we should keep in mind for the scenario that bsmpt and the minimizers are not compiled with the same flags

@cborschensky
Copy link

cborschensky commented May 24, 2022

@cborschensky Thanks for the info! Did you install cmaes by hand and added it there? When I recreated it, I got cmaes through fetch_content so I assumed that everything has the same compile flags.

But I also get the issue if I use gsl or nlopt instead of cmaes. But this is definitly a point we should keep in mind for the scenario that bsmpt and the minimizers are not compiled with the same flags

I got cmaes through cmake, so I didn't install anything manually. After running cmake .. once, I modified the flags for cmaes in the _deps folder manually (I am not a good enough cmake wizard to do that in the cmake files...). I checked explicitly before doing that that it did not have the same flags as the BSMPT code already.

Interesting, because for me the issue did not occur for nlopt or gsl! Maybe related to the gcc version? I haven't tried it on my personal computer (just on the office desktop, where I believe gcc 7.5.0 is installed).

@phbasler
Copy link
Owner Author

@cborschensky Which compiler do you have on the PC on which it worked?

@phbasler
Copy link
Owner Author

@cborschensky I just checked again, you are right. It does not occur if I only use gsl, nlopt or both of them. It only occurs with cmaes.

I just checked again with manually adjusting the flags in CMAES and I think I found the difference, thanks to your input!

If you have a look at the cmaes cmakelist.txt https://github.com/CMA-ES/libcmaes/blob/master/CMakeLists.txt in line 12-14 you have there

set(CMAKE_CXX_FLAGS "-Wall -Wextra") set(CMAKE_CXX_FLAGS_DEBUG "-g") set(CMAKE_CXX_FLAGS_RELEASE "-O3")

If i replace this with
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Wall -Wextra") set(CMAKE_CXX_FLAGS_DEBUG "${CMAKE_CXX_FLAGS} -g") set(CMAKE_CXX_FLAGS_RELEASE "${CMAKE_CXX_FLAGS} -O3")

then everything works.

The command with CMAes overrides the BSMPT compiler flags. You then have the components of BSMPT compiled with different flags.
I will open a PR with the guys in CMAEs and this should do it!

Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working Closed in dev Already closed on dev branch
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants