Remarks on the new salome_meca-lgpl-2024.1.0-1-20240327 released today

mf

Hello,

I tried SM2022 and CA16.7, with this one I succeeded to build the MPI version.
With SM2024 and CA17.2 I still get the above error, maybe something wrong with user rights, IDK (see image below). The 'stable_mpi' was my mistake, should say 'testing_mpi'. This simulation runs fine in all other versions of this SM2024.

Mario.

eedzo

mf Hi Mario, I also cannot get the mpi version to run whenever I input a number greater than 1 into the 'Number of MPI CPU' field. I was having the same issues with SM2023. I have also tried running the compiled stable release from SM2022 in SM2024 but still doesn't run with a number greater than 1 into the 'Number of MPI CPU' field.

mf

Hello,

I finally ran into some trouble with this container, not on the system mentioned above, but on a different one:
Ubuntu 22.04LTS,
no Nvidia GPU, rather onboard Intel HDA
singularity-ce version 4.0.1-jammy
X11 (no Wayland) also applies to system in first message.

When in Asterstudy, I press a save file dialogue like in IMPR_RESU or IMPR_TABLE, the whole SM2024 crashes. It is the button, with the three dots in between unite and localhost:

As soon as the button is pressed, the window crashes and this is printed to the terminal:

AsterStudy: sam.-11-21:05:50.519 AsterStudy activated
(SALOME_Session_Server_No_Server:3246): Gtk-WARNING **: 21:06:07.094: Failed to measure available space: Erreur d’obtention des informations du système de fichiers pour /media/drive2 : Aucun fichier ou dossier de ce type
(SALOME_Session_Server_No_Server:3246): Gtk-WARNING **: 21:06:35.457: Failed to measure available space: Erreur d’obtention des informations du système de fichiers pour /media/drive2 : Aucun fichier ou dossier de ce type

It seems, the save file dialogue itself crashes and takes the whole SM with it. It tries to measure the size of a mounted drive?
Interestingly, all the open file dialogoues in Asterstudy (liken LIRE_MAILLAGE) are not affected:

Notice, these dialogues are in french, which I do not mind, but they are clearly different from all the others in SM2024. All these work on the other system mentioned above. Strange!

This is what a standard open file window looks like in SM2024:

Mario.

hberro

Hi Mario,

Try binding your /media folder for singularity using

-B /media

When calling the SM launcher.

mf

eedzo
Hello,

yes, container, prerequisites and code_aster_mpi don't match yet. The best I could do was SM2022 and CA16.7mpi.

Mario.

AsterO'dactyle

Hello,

I've managed to compile a 17.2 MPI version on container 2024 without any problems.

1/ Pulling src and devtools repositories from Gitlab
2/ Launch the container in shell mode (add --shell)
3/ Go to ~/dev/codeaster/src
4/ ./waf configure
5/ ./waf install test -n zzzz506c

The random test (with two CPUs) runs and is OK.

mf

AsterO'dactyle
Hello,

apart from the test in the command line, have you tried launching something in SM2024? I got the error in message #11,

Mario.

AsterO'dactyle

k_zurawski

AsterO'dactyle So if it's working on your system, could you please share what version of system, singularity, system language, and hardware are you using?

AsterO'dactyle

Integrated post-treatment in AsterStudy is ok too

eedzo

AsterO'dactyle
When 'Number of MPI CPU' is set to greater than 1 this is the error.

AsterO'dactyle

Hello,

You cannot use AsterStudy to launch a MPI>1 version of code_aster. It's not possible. That's sure.

mf

AsterO'dactyle

Hello,

I do not know what you are trying to achieve with this, but we are past that. I have been using SM since 2021 (?) to launch Code_Aster MPI versions. It would be next to useless to me without MPI.

Just ran this, especially for you:

SM2022_CA_MPI_16.7 can be downloaded here:
https://drive.google.com/file/d/1YmbZWEDjsbMarjEy-OHsgqI2ye4JRLSs/view?usp=drive_link

I don't understand what's going on here. How does EDF launch their MPI workloads on a cluster, I assume exactly the same way....

Mario.

AsterO'dactyle

Hello,

I don't get it.
In any case, asterstudy is not generally used to run MPI calculations on clusters.
And if we do, we're talking about the versions compiled on the clusters and not the versions embedded in salome_meca.
By the way, how do you run aster 16.7 in salome_meca_2022 ? Even the Python version isn't normally the right one???

mf

AsterO'dactyle
Hello,

what do you mean? An MPI version is used for large simulations, with many bodies, many timesteps or the like. How would I do that without a GUI? It would take much longer. Only small models can be prepared without a GUI.

To answer your question I quote your colleague Nicolas_p: "From 16.3.2 : salome_meca-edf-2023.1.0-1-20221225-scibian-10 -> so use 20221225 prequisities". These prereqs are also in the container of SM2022.

How am I supposed to do anything else, if SM2023 fails? I mean, how many times have we mentioned that (10 times or more!)? Nobody has done anything about that, by the way. Which means, not many users will have an MPI version with GUI in the coming year. And if SM2024 fails too, then we are also talking about not many users having an MPI version in the future +2 years.

What is going here?

Mario.

hberro

I think the mpi params in Asterstudy are designed for cluster usage (SLURM and such). I'm not sure that they can be used for a local MPI installation where no scheduling is required.

But that doesn't mean you can't prepare your case using Asterstudy and then run it in command line using run_aster...

mf

hberro
Hello,

what problem is your answer regarding to? My singularity file and my working dirs are always in home, this has worked for years now. In this thread, three problems were presented or mentioned (+ the problems Krysztof encountered):
1.) SM2023 always crashes with SIG SEGV in Asterstudy or ParaVis.
2.) SM2024 crashes in Ubuntu22.04 on a specific machine when pressing the '...' button in IMPR_RESU or IMPR_TABLE.
3.) SM2024 with CA17.2mpi does not start simulations, it just stops with an error.

Which problem is solved by binding to /media (a folder I don't use for SM or CA). Is it the second problem with the strange '...' button error?

Regarding your second post: to me, it's not important what they are designed for. I, and many other users, have used them and use them regularly, this works. Why would I launch a second instance to run the sim, if the pressing of a button is enough? There are no parameters for SLURM in this mask.

Mario.

k_zurawski

mf
I'm also reporting a SM crash when pressing '...' button in IMPR_RESU.

nicolas_p

No mpi version are provided inside AsterStudy so it can't wotk. As advised, the best way is to use AsterStudy to prepare your study and use run_aster in an other container (the one that you want) to run your study. That is how I work everyday on local machine (for cluster this an other question).

MPI prerequisites of the development version are also provided to help people if they want to develop but not thinked to be used inside AsterStudy directly.

If the solution is not appropriate for you, you can compile everything from scratch outside the container and configure AsterStudy to use it

salome_meca is fisrtly developed for EDF users and follow their needs.

Irvise

Hi,

thank you very much for the new release! It works much much better than the last one 😛

With the quick time I had to play with it, I had no crashes and I am happy to say that the container works with the new open source NVIDIA graphics drivers without issue, which was not the case with the previous versions. In order to tell the container to use my NVIDIA GFX card I just ran __NV_PRIME_RENDER_OFFLOAD=1 __GLX_VENDOR_LIBRARY_NAME=nvidia ./salome_meca-lgpl-2024.1.0-1-20240327-scibian-11 as it is indicated by NVIDIA for dual GPU systems and it works without issue! However, I still cannot get graphics acceleration with the integrated AMD graphics... I get a segmentation fault error the moment I load any 3D graphical environment...

Thank you very much,
Fer

« Previous Page