Open Krande opened 1 month ago
This week I finally managed to properly run debugging on the fortran code. Primarily my attempts at making it work with CLION and the LLDB debugger was in vain. When using Visual Studio it worked straight away.
And in my first attempt I found a simple NULL_POINTER bug in the fortran code that for some reason works fine on GCC. By applying the following fix in bibfor/nonlinear/nmdoch.F90
at line 162 (in this commit) the number of passing tests jumped from 45% to 79%.
With a good debugging tool in place I am confident that I'll be able to fix the remaining issues related to source code in Code Aster.
Then it is a matter of figuring out
fyi @ldallolio
Hi @Krande,
Great job! Sometimes compilers behave differently with variable initialization if the standard is unclear about the expected behaviour : some compilers will let you use a pointer after it has been freed (something like a "tolerated user bug") while others will put a binary zero over the variable so that it is not used anymore. Recompiling using stricter options (enabling warnings etc) could make gcc behave like it. Debugging has also this effect : the debugger will initialize/finalize variable differently with respect to the optimized compiler version so it could explain what you are seeing (I am taking examples from the C/C++ world but I believe it applies to fortran too) I think you are right, a good debugger is the way to go
Il giorno gio 13 giu 2024 alle ore 10:57 Kristoffer Andersen < @.***> ha scritto:
This week I finally managed to properly run debugging on the fortran code. Primarily my attempts at making it work with CLION and the LLDB debugger was in vain. When using Visual Studio it worked straight away.
And in my first attempt I found a simple NULL_POINTER bug in the fortran code that for some reason works fine on GCC. By applying the following fix in bibfor/nonlinear/nmdoch.F90 at line 162 the number of passing tests jumped from 45% to 79%.
image.png (view on web) https://github.com/conda-forge/code-aster-feedstock/assets/9642232/030185b1-8e5f-468e-9a72-af2ca12b8470
With a good debugging tool in place I am confident that I'll be able to fix the remaining issues related to source code in Code Aster.
Then it is a matter of figuring out
- how we can resolve the intel-openmp/llvm-openmp conflict (which hopefully will be resolved once we can compile using LLVM flang on the fortran code and we can use LLVM openmp on all packages).
- Skip symlinking. With a good debugging suite up and running I believe it will be easier to track down the issue in #66 https://github.com/conda-forge/code-aster-feedstock/issues/66
— Reply to this email directly, view it on GitHub https://github.com/conda-forge/code-aster-feedstock/issues/65#issuecomment-2165047531, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAPAUDJHZGN7LTLO6BPGZ3DZHFNGJAVCNFSM6AAAAABIUGK452VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNRVGA2DONJTGE . You are receiving this because you are subscribed to this thread.Message ID: @.***>
Comment:
Here is a "live" summary of the ongoing/remaining tasks for successfully compiling and distributing Code Aster for windows MSVC.
As of today
(04.06.2024) I am up to 45%(16.06.2024) I am up to 79% of tests passing for the sequential tests for MSVC Code Aster using LLVM Intel Fortran (IFX) to compile Code Aster and LLVM Flang/IFX to compile the various dependenciesCode Aster
libiomp5md.dll
from intel-openmp.intel-fortran-rt
against intel-openmp instead of llvm-openmp. No longer conflictsDependencies
metis=5.1.0=*aster*
scotch=7.0.4=*aster*
mumps=5.6.2=*aster*