Topological Optimization

jacob

after changing the paragraph and the line in Stage_1 in ORG it worked for me

mf

jacob
Hello,
the error is already in the MECA_STATIQUE before:

[1,0]<stdout>: Soit un taux de remplissage de 0.021 %.
[1,1]<stdout>:La matrice est de taille 156927 équations.
[1,1]<stdout>: Elle contient 2673198 termes non nuls si elle est symétrique et 5189469 termes non nuls si elle
[1,1]<stdout>:n'est pas symétrique.
[1,1]<stdout>: Soit un taux de remplissage de 0.021 %.
[1,2]<stderr>: Evaluation failed with: {'INST': 2.0}
[1,2]<stderr>: Detailed traceback of evaluation:
[1,3]<stderr>:Evaluation failed with: {'INST': 2.0}
[1,3]<stderr>: Detailed traceback of evaluation:
[1,3]<stderr>:Traceback (most recent call last):
[1,3]<stderr>: File "code_of_0000000c", line 1, in <module>
[1,3]<stderr>:NameError: name 'X' is not defined
[1,2]<stderr>:Traceback (most recent call last):
[1,2]<stderr>: File "code_of_0000000c", line 1, in <module>
[1,2]<stderr>:NameError: name 'X' is not defined
[1,2]<stdout>:
[1,2]<stdout>:Exception: Trying to close the database after an uncaught exception...
[1,2]<stdout>:
[1,2]<stdout>:
[1,2]<stdout>: Publishing the result of the current command MECA_STATIQUE...

When that happens, I get no result and thus no VMIS_2.csv etc.
It seems I arrive at an unsolvable situation for MECA_STATIQUE. I tried different meshes from Netgen, Gmsh, and Hexa. Nothing worked. This I also had with previous algorithms from time to time. But it is weird it has to do only with MPI.

How can I opt for a minimal change from iteration to iteration?

Thanks,

Mario.

jacob

It seems there is something wrong with the E function, hard to tell, since I don't have your mesh + BC.

Try it with the template example.

You mean this?
relaxation = "no"
relaxation = "yes"
p_relax = 3 # start relaxing when p = 3
if relaxation == "yes":
relaxation_factor_end = 0.8 # 0.8 -> allow 20% density change in next iteration for each point

mf

Your beam example works mit MPI. Even without the separation of singularity commands from above.

So it's my own definition of mesh and BC (only one fix and one force)... hmmmmmmm

It's still puzzling that it works without MPI but with, it doesn't.

jacob

So, can you share the mesh?

mf

jacob
Sure, but it's too big to share it here. I'll try gdrive. Will post link when done.

I'll share the whole working directory that rests in STUDY. I copy my mesh from ORG_3D that's the only difference to your setup. The rest is pretty much like in your /beam. I omitted the UNAFFECTED group entirely, since it is present nowhere.

https://drive.google.com/drive/folders/19Cry1ssyzWhwVTX06R1kpz7xChjyfr6G?usp=drive_link

Please let me know when you have it.

jacob

hmm.. it works on my computer, I only changed the 16.2 to testing_mpi (16.4) and the line inp in stage_1

might be a version issue

mf

jacob

Thanks for testing. So my 16.7MPI is the culprit. I will change that, I still have the old files.

jacob

Regarding MPI do you have any benefit from that?
Usually if I have less than 1000 000 dof using

P mpi_nbcpu 1
P mpi_nbnoeud 1
P ncpus 5

is usually faster than e.g

P mpi_nbcpu 5
P mpi_nbnoeud 1
P ncpus 1

and for even larger studies mpi consumes much memory...

mf

jacob

A factor of two is always possible with MPI. Regarding your settings: if you have 6 cores (my assumption), then
P mpi_nbcpu 2
P mpi_nbnoeud 1
P ncpus 2

is likely to be faster. Probably
P mpi_nbcpu 1
P mpi_nbnoeud 1
P ncpus 4

is also better than the odd 5.
There are many commands in CA that are also quicker with MPI. Try to avoid odd numbers, instead use powers of 2 or factors of 2, you don't benefit from 'oversubscribing' (that is, giving the CPU too much and it has to wait. If you check htop and see numbers higher than 6 with your 6 cores, then the setting is too ambitious. Remember: your CPU also has other stuff to do that need some CPU, these can interrupt if they are important. And then CA is slower). CA likes hyperthreading to be OFF, by the way. Yeah memory you can never have enough......

Mario

jacob

I have 16, but using more than 8 mpi_nbcpu always leads to much slower time than OpenMP ...

For example, this was done on supercomputer for 2 000 000 dof and OpenMP had basically the same speed.

mf

jacob
It depends on the type of simulation, also. I've only seen less benefit from MPI in thermal simulations with CA, every other sim I think is better off with MPI.
If you look at you table, and keep in mind you only have limited amount of CPU, then you basically assign your work to it in the best manner. Let's say you have 16 cores in your table, then you'll choose 8/2 (MPI/OMP) and not 1/16. The results of 4/1 and 1/4 are strange indeed. Processes like storing data are, I think, mostly single core processes. So, like in Amdahl's law, if you have a lot of storing data to do, you'll likely not profit so much from MPI.
It also depends on the type of CPU. Since a few years CPU have performance and efficiency cores that behave differently (does not apply to servers and workstations, I think).
Try 4/2 or 6/2 on your machine, 8/2 is maybe already too much because of housekeeping processes and graphics and other stuff. Somewhere in the CA literature it also says to always both MPI and OMP,

Mario.

jacob

As you can see 4/2 is not much faster than OpenMP. (maybe 10 %, but it's useless)

mf

jacob

Maybe this simulation is an edge case of some sorts. This is absolutely not my experience. And also: what do you want to do, if you have 2 CPUs? You have to use MPI.

jacob

It was just normal static study.

can you try this with 4/2 and 1/4-8?
Just open MODEL_1.hdf in MODEL and generate mesh, save to folder MESH as ML_box_1.med.

https://forum.code-aster.org/public/assets/files/2025-02-19/1739965952-972957-box.rar

mf

jacob
Maybe later, I have OpenFOAM running all day also. My sims are mostly nonlinear, maybe it's that. Also benefits are connected to certain minimum numbers of DOFs per CPU.

And then what? Should I record times? Does it stop automatically at a specific time?

EDIT: there are 2 missing groups 'Group_Of_All_Faces' and 'Group_Of_All_Volumes', I deleted the call for ...Faces and added ...Volumes. Then I get

║ ║
║ les 20592 mailles imprimées ci-dessus n'appartiennent pas au modèle ║
║ et pourtant elles ont été affectées dans le mot-clé facteur : PRES_REP

I can't use this.

jacob

when saving check

Yeah, I am interested in the time difference. It's just simple statics with 1 step.

It doesn't matter if it is linear or nonlinear, MPI is about solving KU=F, in nonlinear you just do it many times, so the speed up is in one iteration.

mf

jacob
That's not the reason for the missing groups.

It's probably WAY too small, storing and reading data will take more time than STAT_NON_LINE.

Still getting the PRES_REP error. Can't correct the geometry, have different shaper version (error upon changing to shaper).

jacob

yes it is, checking will create 'Group_Of_All_Faces' and 'Group_Of_All_Volumes',

well 2e6 dof takes for example 2 min, but if I have a nonlinear study I have 2 min * 1000, so I would need to speed up even these "small" studies.

mf

jacob
Ah this is a kind of standard group, I don't work with these. Good to know, I created them by hand in the last examples.

The benefit here seems to be small in the lower counts, indeed:
1/4: 6m35s
1/8: 5m13s
4/2: 4m26s
8/2: 2m54s --> sweet spot
16/2: 2m43s

« Previous Page Next Page »