Tracker for Code Aster MSVC support

[Krande]

Comment:

Here is a "live" summary of the ongoing/remaining tasks for successfully compiling and distributing Code Aster for windows MSVC.

As of today the number of passing tests for the sequential tests for MSVC Code Aster is

• (04.06.2024) 45% passing
• (16.06.2024) 79% passing
• (02.08.2024) 85% passing

The MSVC version is currently using LLVM Intel Fortran (IFX) to compile Code Aster and LLVM Flang/IFX to compile the various dependencies

Code Aster

• Need to find an alternative to symlinking dlls. Symlinking requires administator privileges on windows and will not work on cf.
  • I have asked Mathieu about it on the official Code Aster issue https://gitlab.com/codeaster/src/-/issues/1#note_1929414100
  • To me it seems like we either make a patch with a rewrite of the pybind11 module definitions into separate pyd's or we try to see if static linking and making copies fixes things. I dont have much experience with static linking, so this might take me some time to figure out.
  • Alternatives to symlinking Code Aster pyd files #66
  • I managed to solve this by simply replacing the symlinks with code that loads the dll and returns the pybind11 module definition.
• Ensure changes to source files are safe wrt. memory. Some tests are currently running into memory issues.
  • Solved by enabling openmp in Mumps and use MKL64 (not MKL) as recommended by mkl link advisor AND ensured that the Intel compiler bin path is not added to PATH (did cause conflicts). Memory increase was due to the integer represnting number of available openmp threads was huge (should be only 1).
• Make sure we're using the appropriate lapack, liblapack package variants together with mkl.
  • We are currently using MKL together with blas/lapack/liblapack compiled against MKL. So far it's looking good.
• Solve clobbering issue between intel-openmp and llvm-openmp. This will cause failure when llvm-openmp replaces the libiomp5md.dll from intel-openmp.
  • I solved this temporarily by simply re-compiling intel-fortran-rt against intel-openmp instead of llvm-openmp. No longer conflicts
• Solve intermittent issue with OpenMP returning a too high number for the number of threads (>1e6 threads) causing extreme spikes in memory usages
  • I solved this by simply disabling openmp on windows.
• Pass majority of sequential tests (>90%)

Dependencies

1. Build and compile HDF5 with Fortran enabled on cf.
   LLVM Flang needs a fix:
   • bump to latest hdf5 version and windows fortran support w/flang hdf5-feedstock#217
   • [flang] Linker for non-constant accesses to kind arrays (integer_kind, logical_kind, real_kind) llvm/llvm-project#89403
2. Compile libmed with Fortran enabled (and use "long long" MED int type) once HDF5 is compiled
3. Compile Medcoupling with updated libmed
4. Compile Metis with 64 bit integers
   • We need to either create a separate cf package "metis-aster" or make a dedicated variant of such as metis=5.1.0=*aster*
5. Compile scotch with 64 bit integers
   • use flang18 not flang5 scotch-feedstock#82
   • We need to either create a separate cf package "scotch-aster" or make a dedicated variant of such as scotch=7.0.4=*aster*
6. Compile mumps against scotch and metis and use 64 bit integers
   • [Draft] Try to build with flang 18 on Windows mumps-feedstock#111
   • We need to either create a separate cf package "mumps-aster" or make a dedicated variant of such as mumps=5.6.2=*aster*
   • Compile and Link mumps against Metis and Scotch. I have managed to do that in https://github.com/Krande/condapackaging/tree/main/src/code_aster/mumps by relying on the scivision repo for mumps

[Krande]

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

• 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 Alternatives to symlinking Code Aster pyd files #66

[Krande]

fyi @ldallolio

[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 <#66> — Reply to this email directly, view it on GitHub <#65 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAPAUDJHZGN7LTLO6BPGZ3DZHFNGJAVCNFSM6AAAAABIUGK452VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNRVGA2DONJTGE> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>