Building code_aster on Ubuntu 24.04

[fsimonis]

This is probably also valid for Ubuntu 22.04.

Building code_aster 14.6.0 (stable) is currently not possible due to a row of issues.

import imp

The setup script and some dependency python scripts use the deprecated and now removed import imp. As the dependencies are nested in archives, patching isn't easy.

Workaround for me was to add the following to the /lib/python3.12/sitecustomize.py the usercustomize.py would be less invasive though:

import importlib
import sys
sys.modules['imp'] = importlib

mumps

This dependency has a row of Error: Type mismatch in argument errors in file mpi.f.
export FCFLAGS=-fallow-argument-mismatch solves this issue

mfront

This dependency has missing type errors in C++ files.

tfel

A massive amount of no type named X and X is not member of std errors.
Also access to struct members which aren't found

[MakisH]

Thanks for the detailed investigation and summary! These are some of the issues me and @IshaanDesai also faced in the context of upgrading the VM to Ubuntu 22.04 (precice/vm#45 (comment)).

Now that we have a build of the VM with preCICE v3, which includes code_aster, I think we should:

• Upgrade to Ubuntu 24.04
• Disable the code_aster step in the provisioning
• Wait for the next stable release of code_aster

We don't use this adapter in any other CI workflow at the moment, and it is not that users ask for this every day. Besides, if we have issues building it in newer versions, users will have the same issue.

[fsimonis]

Another interesting observation is that code_aster bundles a lot of dependencies that are also dependencies of PETSc.

This should lead to version conflicts when loading these libraries at runtime.

https://ubuntu.pkgs.org/22.04/ubuntu-universe-arm64/libpetsc-real3.15_3.15.5+dfsg1-1build2_arm64.deb.html

Namely: mumps blas hdf5 scotch

[MakisH]

In precice/vm#94, I started porting the VM to Ubuntu 24.04.

@BytePaul is working on building code_aster and the adapter on that. Please document here all your intermediate findings.

[BytePaul]

Issue: MUMPS Compilation Failed Due to Type Mismatch in mpi.f

While compiling MUMPS, I ran into multiple type mismatch errors in the Fortran file mpi.f. The issue occurred while executing:

gfortran -O -O2 -fPIC -DPORD_INTSIZE64 -fopenmp -fdefault-real-8 -fdefault-double-8 -fdefault-integer-8 -c mpi.f -o mpi.o

The error log included the following:

CALL MUMPS_COPY_LOGICAL( SENDBUF, RECVBUF, COUNT )
Error: Type mismatch in argument ‘s’; passed INTEGER(4) to LOGICAL(4)

CALL MUMPS_COPY_REAL( SENDBUF, RECVBUF, COUNT )
Error: Type mismatch in argument ‘s’; passed INTEGER(4) to REAL(4)

CALL MUMPS_COPY_DOUBLE_PRECISION( SENDBUF, RECVBUF, COUNT )
Error: Type mismatch in argument ‘s’; passed INTEGER(4) to REAL(8)

CALL MUMPS_COPY_COMPLEX( SENDBUF, RECVBUF, COUNT )
Error: Type mismatch in argument ‘s’; passed INTEGER(4) to COMPLEX(4)

These errors stem from GFortran 10+, which by default treats argument type mismatches as errors instead of warnings, as per Fortran 2008+ standard compliance.

Solution

Adding the flag -fallow-argument-mismatch to the Fortran compiler flags did not work in my case.

Instead, I solved the problem by downgrading gfortran to version 9.5, which restored the previous behavior where mismatches are allowed as warnings.

After downgrading:

MUMPS compiled successfully

Code_Aster could proceed with the installation

Recommendation

If you're facing similar errors and cannot patch the Fortran code or interfaces directly, try using:

sudo apt install gfortran-9
Then set it as default:

sudo update-alternatives --install /usr/bin/gfortran gfortran /usr/bin/gfortran-9 90
This approach resolved the installation issues for me when working with MUMPS 5.1.2 as part of Code_Aster 14.6.0 setup.

Hope this helps others facing similar legacy compatibility issues!

[MakisH]

Note: The latest code_aster version is still the 15.2 testing and the unstable branch based on that: https://code-aster.org/spip.php?rubrique21

If 15.2 works, then let's go with 15.2 and upgrade the adapter.

I have no idea if we have users and if yes, which users are currently using which version.

[BytePaul]

Missing as_run and profile.sh after Setup

During installation, I encountered the following error:

'aster' requires this file : /home/vagrant/code_aster/bin/as_run  
'aster' requires this file : /home/vagrant/code_aster/etc/codeaster/profile.sh  
*** Exception raised : missing objects 

Context:
Initially, I skipped the installation of MUMPS, TFEL, and AsterTk, assuming they were optional.
Later, after realising that MUMPS appears essential for the proper compilation of Code_Aster, I went back and successfully installed mumps-5.1.2.

Despite this, rerunning setup.py still does not generate as_run or profile.sh, and the installation fails with the same missing object error.

Next Steps:
I am currently reviewing the log files and installation flow to understand what might still be missing or misconfigured. It appears that even with MUMPS installed, something else may be required to trigger full Code_Aster installation, including script generation.

Any suggestions or insights into how to force as_run and profile.sh generation or which specific step/flag might be blocking it would be appreciated.

[MakisH]

Initially, I skipped the installation of MUMPS, TFEL, and AsterTk, assuming they were optional.

Do I understand correctly that TFEL and AsterTk are required dependencies?

I would suggest starting from TFEL. It seems to be very well maintained. Can it be that installing a newer version than what code_aster 14.6 builds by default works?

[BytePaul]

TFEL and AsterTk are not required dependencies.

I can look into installing TFEL and its effects if uninstalled.

[MakisH]

But then it should build without TFEL, and it would not make sense to look into that direction.

The first step would be to look into the logs and understand why these objects are not produced. There must be some clear compilation error for some component.

[stefano2734]

Websites at Code Aster org are not here at newest level with stable 16 series and new development series 17.

New stable series is 16 with actual 16.5 and 16.6 next door at EDF test.

https://code-aster.org/spip.php?article295
Salome Meca 2023 and 2024 includes Salome 9.x and code aster stable 16.5 and dev 17.x with huge Salome Meca package.
Code aster only:
https://anaconda.org/conda-forge/code-aster/files?type=&version=16.5.0
https://code-aster-windows.com/download/

See more links in #29
and in #28

With significant changes to 15.3 and higher with full python support.
See introduction of development with 14 papers in https://code-aster.org/spip.php?article860
Session 20 and 21 are here most important to a precice adapter.

So new adapter to actual systems should be on base of code aster stable 16.5 or next 16.6 which is in EDF 6-month-production-test.