Set number of OpenMP threads to something reasonable in tests#740
Set number of OpenMP threads to something reasonable in tests#740mmuetzel wants to merge 2 commits intoElmerCSC:develfrom
Conversation
| I don't know why the test The failing Ubuntu runner has the following in its stderr: I don't know if that helps. |
| Fwiw, the number of physical processors of the GitHub-hosted Ubuntu runners is 2. I.e., |
Determine the number of physical processors of the build host and limit the number of OpenMP threads to that for each test. If a test is involving multiple MPI processes, divide the number of physical processors by the number of used MPI processes. Set the number of OpenMP threads to the integer floor of that result. If a user sets `OMP_NUM_THREADS` explicitly in the environment, that takes precedence over the automatic selection.
The tests are limiting the number of OpenMP threads by themselves.
| The number of failing tests when running with more than one OpenMP thread seems to have increased to 3 since the last time this was run in CI: |
| Yes, well, the last 2 are probably my fault, I did re-activate the MagnetoDynamics2D threading a while back, maybe I just downgrare it again, until someone has time to have a real look ... …________________________________ Lähettäjä: Markus Mützel ***@***.***> Lähetetty: keskiviikko 28. tammikuuta 2026 11.03 Vastaanottaja: ElmerCSC/elmerfem ***@***.***> Kopio: juharu ***@***.***>; Mention ***@***.***> Aihe: Re: [ElmerCSC/elmerfem] Set number of OpenMP threads to something reasonable in tests (PR #740) [https://avatars.githubusercontent.com/u/65065102?s=20&v=4]mmuetzel left a comment (ElmerCSC/elmerfem#740)<#740 (comment)> The number of failing tests when running with more than one OpenMP thread seems to have increased to 3 since the last time this was run in CI: The following tests FAILED: 612 - TopoOptHeat2DCompMin (Failed) quick serial 733 - mgdyn2D_bh_relfun (Failed) serial 742 - mgdyn2D_scan_homogenization_elementary_solutions (Failed) 2D harmonic mgdyn scanning serial — Reply to this email directly, view it on GitHub<#740 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ACTOMSS7OLBVIL3YTQWO3334JB3PLAVCNFSM6AAAAACQHGIGO6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTQMBZHE2DGNZRGY>. You are receiving this because you were mentioned.Message ID: ***@***.***> The information in this email may be confidential and is intended solely for the use of the individual or entity to whom it is intended. If you are not the intended recipient of this message, please delete the message and notify the sender immediately. For information on how we process personal data and our contact information, please see CSC's website: Privacy<https://csc.fi/en/privacy> Tämän sähköpostin tiedot voivat olla luottamuksellisia ja ne on tarkoitettu yksinomaan sen henkilön tai yhteisön käyttöön, jolle ne on osoitettu. Jos et ole viestissä tarkoitettu vastaanottaja, tuhoa viesti ja ilmoita asiasta välittömästi viestin lähettäjälle. Tietoja henkilötietojen ja yhteystietojen käsittelystä löydät CSC:n verkkosivuilta: Tietosuoja<https://csc.fi/tietosuoja> |
| I agree with what @juhanikataja wrote in #761 (comment). It would be useful to run the tests with more than one OpenMP threads. Otherwise, potential issues with OpenMP won't be noticed by the CI tests. |
| TopoOptHeat2DCompMin test fails because the solver "HeatSolverVec" activates threading if OMP_NUM_THREADS>1, but the code these keywords: Local Matrix Identical = Logical True leads to is not ready for that.... |
| I think threaded testing is successful if it revealed bugs in code. |
3 participants
Determine the number of physical processors of the build host and limit the number of OpenMP threads to that for each test.
If a test is involving multiple MPI processes, divide the number of physical processors by the number of used MPI processes. Set the number of OpenMP threads to the integer floor of that result.
If a user sets
OMP_NUM_THREADSexplicitly in the environment that takes precedence over the automatic selection.With that, remove explicitly setting
OMP_NUM_THREADSin the build rules for Windows MinGW.That is essentially what @juharu suggested in #725 (comment).