Does contact continue formulation use multiple cores(MPI)?

vishwas

Hello,
I have trying to leverage multiple cores in a forming simulation. Something like below.

But it seems that Continue contact method does not allow to use MPI and due to this, only One CORE is being uitlised. This is making simulation really slow.
I set these parameters in .export file
P actions make_etude P debug nodebug P memjob 20480000 P memory_limit 20000.0 P mode interactif P mpi_nbcpu 4 P mpi_nbnoeud 1 P ncpus 2 P nomjob test1 P time_limit 3700200.0 P tpsjob 616710 P version testing_mpi A memjeveux 2000.0 A tpmax 3700200.0 F comm stage1.comm D 1 F mmed mesh_1.med D 20 F mmed mesh_2.med D 30 F libr stress_strain_curve.txt D 21 R base base-stage1 RC 0 F mess stage1.mess R 6
I tried to use MATR_DISTRIBUEE='OUI', inside SOLVEUR=_F(METHODE='MUMPS') and
DISTRIBUTION=_F( PARTITIONNEUR='METIS', METHODE='SOUS_DOMAINE' ),
but got this error from code_aster

[1,0]<stdout>: ╔================================================================================================╗
[1,0]<stdout>: ║ <EXCEPTION> <MECANONLINE_6> ║
[1,0]<stdout>: ║ ║
[1,0]<stdout>: ║ L'option MATR_DISTRIBUEE='OUI' est interdite avec le contact continu. ║
[1,0]<stdout>: ╚================================================================================================╝
If I use
DISTRIBUTION=_F(
METHODE='CENTRALISE'
),
I get the following meeage:
[1,0]<stdout>: Le calcul est séquentiel, on ne peut donc pas utiliser MATR_DISTRIBUEE='OUI'.
[1,0]<stdout>: On force MATR_DISTRIBUEE='NON'.

Does this mean that a simulation with continue contact is really only using 1 core even though task manager says all cores(assigned by mpi_nbcpu )say 100 % usage?
I think I will get same error if I use PETSC solver and similar setting in_F(MATR_DISTRIBUEE='OUI'). SO, PETSC is also not able to use MPI with continue contact?
Will ncpus>1(like 2 or 3) help reduce simulation time ?

Regards
Anirudh

AsterO'dactyle

HEllo,

Don't use MATR_DISTRIBUEE with PETSc. PETSc use MPI
This option is used to distribute data across the CPUs. At worst, it uses more memory.

vishwas

Hello,
Thank you for replying.
I firstly used MATR_DISTRIBUEE ='OUI' with MUMPS solver and these settings in AFFE_MODELE

AFFE_MODELE= F(DISTRIBUTION=F(
PARTITIONNEUR='METIS',
METHODE='SOUS_DOMAINE'
),)

SOLVEUR=_F(ACCELERATION='AUTO',
ELIM_LAGR='LAGR2',
FILTRAGE_MATRICE=-1,
GESTION_MEMOIRE='AUTO',
LOW_RANK_SEUIL=0.0,
MATR_DISTRIBUEE='OUI',
METHODE='MUMPS',
MIXER_PRECISION='NON',
NPREC=11,
PCENT_PIVOT=35,
POSTTRAITEMENTS='AUTO',
PRETRAITEMENTS='AUTO',
RENUM='SCOTCH',
RESI_RELA=-1.0,
STOP_SINGULIER='NON',
TYPE_RESOL='AUTO')

It threw the error mentioned above
L'option MATR_DISTRIBUEE='OUI' est interdite avec le contact continu.

Then If I change METHODE='CENTRALISE' in AFFE_MODELE with MUMPS solver and MATR_DISTRIBUEE='OUI'
then this is the message:
Le calcul est séquentiel, on ne peut donc pas utiliser MATR_DISTRIBUEE='OUI'.
On force MATR_DISTRIBUEE='NON'.

Using SOLVEUR=F(METHODE='PETSC')
I tried as an alternative to MUMPS but it I think it produced same sequential message and had problems with convergence.
Using SOLVEUR=F(METHODE='GCPC'), it threw singularity matrix error of LAGC_C DOF.

Regards
Anirudh Nehra

AsterO'dactyle

Hello

MATR_DISTRIBUE doesn't work with contact.
Using PETSc is no guarantee. Like all iterative solvers, it lacks robustness and requires a dedicated preconditioner. You must test different variants and different preconditioners (PRE_COND). There is no guarantee.
Effective preconditioners for contact/friction problems (particularly Lagrangian and augmented Lagrangian, i.e., saddle-point problems) remain a major area of research.

GCPC almost never works for nonlinear problems; it is a very old iterative solver.

mf

AsterO'dactyle
Hello,

hasn't MATR_DISTRIBUEE=OUI with DEFI_CONTACT been possible in older versions? I vaguely remember it being possible in CA15.4? I had a dual CPU system for 5+ years now and I remember CA complaining about it when I used a newer version.

Mario.

AsterO'dactyle

You were right. Yes, I checked.
It's been disabled since version 15.5.10.
There's an issue in the distribution that causes incorrect results. We decided to disable it.

mf

AsterO'dactyle

Thanks, is this going to be reverted in future versions? Because, I think you'll understand, it can be a severe limitation even with only 2 CPUs (RAM usage, % of RAM usable is only slightly above 50%? I don't know exactly how much I could not use...), even more so on a cluster. What do you do on a cluster? Max out the RAM on CPU0 (but how do you know which one will be used? Or do you max out the RAM on certain nodes?) because more memory is consumed on one CPU?
I understand that MATR_DISTRIBUE=NON or OUI is pointless on single CPU systems, because this one CPU gets all the RAM anyway.

Mario.