MMG3D Lagrangian motion: cannot maintain body shape

#4

Hi Jay,

Is it possible to send me:

  • a mesh and displacement with a surface rotor almost valid at the begining but degenerated after a Mmg call? (If you dont want to share your mesh, you can send it by private mail at algiane.froehly@inria.fr);
  • your Mmg parameters.

I need to reproduce this issue to figure out what happens…

Thank you by advance,
Regards,
Algiane

#5

Hi,
I am facing similar problem with the MMG3D. Some of the boundary faces are missing despite those faces are not specified with ref 10. So they are static.
Furthermore, I am using the -nosurf option, but clearly it has been overridden.
The motion done correctly, but the farfield surface now is not usable.
I am using the -lag 2 option, however, if I use the -lag 1 option, this problem doesn’t happen
I am attaching screenshoots for the mesh before and after motion.

Regards,
saleh

before
before.png1848×1024 75.8 KB
after
after.png1848×1024 338 KB

#6

I am attaching the log files for -lag 1 and -lag 2 options.

lag2.dat (10.5 KB) lag1.dat (6.8 KB)

#7

Hello,

Are you compiling with Scotch, by chance?
I have to dig deeper for the exact reason for this, but I see that there is an issue when using Scotch with the Lagrangian motion: surfaces can be deformed with or without the nosurf option, and the displacement can be incomplete.

Thank you in advance,
Luca

#8

Hi Luca,
Thanks for your reply.

Actually, I compiled using the standard procedure, and I didn’t include the Scotch library explicitly in any way.
The displacement is done as specified without any problem, the problem only in the outer domain surfaces.
Could you please mention the cases when the mmg3d overrides the -nosurf option?

Regards,
Saleh

#9

Hello Saleh,
I asked you because currently I am able to reproduce problems with non-preserved surfaces with the Lagrangian motion only when using Scotch.

  • Could you please exclude the case you are accidentally using a Scotch library automatically found in your system by explicitly enforcing USE_SCOTCH to OFF before configuring and rerunning Mmg?
  • Also, could you share the mesh, displacement and options you are using to help me debug the issue? (Even privately at my professional address luca.cirrottola@inria.fr if it is confidential)

Thank you,
Luca

1 Like
#10

Hi Luca,

In the problem I had described above, I was using the older version of mmg (Feb 2020).
According to your recommendation (despite I checked the cmake log, and it’s written that the Scotch library was not found) I removed the old version and installed the latest version 5.5.1 (Oct. 14, 2020) enforcing USE_SCOTCH to OFF, and I noticed the followings:

  • The process now takes more time, and this sentence is printed on the screen unnecessarily about a hundred time: “Realized displacement: 1.000000”. That was not the case in the previous version
  • I am receiving now this error : “Error: MMG5_defsizreg: at least 1 wrong point qualification : xp ? 0.” for the same mesh and solution files
  • The case is generic, and I am attaching it here
  • I use the following command:
    mmg3d_O3 file.mesh -lag 2 -nosurf

Thank you in advance
Regards,
Saleh

file.tar.xz (3.8 MB)

#11

Dear Saleh,
Thank you for your test case! I have been able to run it, reproduce the issue and break it down:

  • There was an unallowed edge split acting on the surface with or without nosurf, this behaviour was a bug and it has been fixed in the latest master branch.
  • The verbosity was excessive for the its standard value (-v 1), this also has been fixed.

Now the command mmg3d_O3 file -lag 2 -nosurf delivers the result you expect (the warning about bad tetra orientation is not a problem, as Mmg can re-orient input tetra by itself, neither the warning about the required edges is worrying).

Please note that Lagrangian motion is still not working with Scotch.
Let me know if you experience further issues!

Yours,
Luca

P.S.

Please note that your mesh has indeed large edge size variations, so in case you wish to run Mmg with surface adaptation, a single Hausdorff parameter won’t fit all the boundaries. Local parameters should be used in this case to avoid extreme refinements/derefinements and possible failures during the mesh optimization phase.

Here I attach a general script to use them by library call, just in case.main.c (6.9 KB)
You can compile it with a line in the spirit of gcc main.c -I$mmg_include_dir -L$mmg_lib_dir -lmmg3d -L$elas_lib_dir -lelas.
The program needs two arguments: the input mesh and the output mesh file name. Than it applies a displacement of value 0.08 in the z-direction on the surface 10 and runs Mmg in Lagrangian mode 2, with a small Hausdorff parameter on the airplane surfaces and a big one on the outer surfaces.
If you set MMG3D_IPARAM_nosurf to 0, you (luckily) recover the same results as with mmg3d_O3 file -lag 2 -nosurf.

1 Like
#12

Thank you Luca

It works now.

Actually, I prefer for the time being to fix the surfaces of the geometry, however, thanks for your script and I will give a try soon.

Regards,
Saleh

#13

By the way, I wonder if the deformed mesh with fixing the surfaces still hold the same ids? the number of triangles are the same, but what about their orders?

Regards,
Saleh

#14

Hello Saleh,

  • Triangles IDs are surely changed even required or nosurf (as Mmg reconstruct the boundary internally),
  • required points IDs are not changed if Scotch is not used,
  • required tetra IDs could change if a tetra with lower ID is deleted during adaptation (but I should double-check this last one).

So, if in your case you need to recognize the surface triangles, their IDs will be changed but not those of their vertices (ia,ib,ic): a possible strategy could be to fill a hash table using the triplet of vertices IDs (ia,ib,ic) of the input triangles, and to search in it for the matching triplet of vertices IDs of the output triangles.

(To go further, if you use Scotch the required points IDs will also be changed; but you could store the old IDs as the references of the input vertices, and than search for the triplet of vertices references on every output triangle to find the matching input triangle)

Hope that this helps and that I managed to explain myself,
Luca

1 Like
#15

Update: Now the Lagrangian motion works with Scotch too.

#16

Hi Luca,

What is the advantage of Scotch here if the Lagrangian doesn’t work in parallel? renumbering ?

Regards,
Saleh

#17

Hello Saleh,
Yes, the latter, renumbering to speedup the execution by reducing cache misses.

Yours,
Luca

1 Like
#18

Hi Luca,

When I try to deform the mesh again, even with smaller displacement, I am receiving this error:

////////////////////////////////////////////////////////////////////////////////////////////////////
– PHASE 2 : LAGRANGIAN MOTION
** LAGRANGIAN MOTION
Number of packed tetra 57750, points 13770, triangles 15362
Matrix and right-hand side assembly
Solving linear system: 8.507198E-07 in 13 iterations

** Cumulative time: 0.546s sec.
—> Realized displacement: 1.000000
17836 edges splitted, 2652 vertices collapsed, 394 elements swapped, 1518 vertices moved.
0 edges splitted, 5 vertices collapsed, 10 elements swapped, 2 vertices moved.
17836 edges splitted, 2657 vertices collapsed, 404 elements swapped, 1520 vertices moved.
—> Realized displacement: 1.000000

Warning: MMG5_spllag: all edges of tetra 3257 are required or of length null.

Error: unable to allocate larger adja table.

Check the mesh size or increase maximal authorized memory with the -m option.

Error: MMG5_split1b: unable to allocate a new element.

Check the mesh size or increase maximal authorized memory with the -m option.

Error: MMG5_spllag: unable to split.

Problem in spllag. Exiting.

ELAPSED TIME 9.466s
////////////////////////////////////////////////////////////////////////////////////////////////////

I am receiving the same error with and without -nosurf
Is it only about memory?

Could you give it a try?

Regards,
Saleh

#19

Hello Saleh,

Usually the memory error in Mmg is reliable, meaning that you should allow it to use more memory (with the -m option) in order to go on. Anyway, from a user perspective it can also be a symptom that Mmg is trying to adapt too much. With the Lagrangian option, it can mean that -hausd or -hgrad are trying to refine a lot.

Is it the same case (same mesh, same options) of the previous posts?

Yours,
Luca

#20

Hi Luca,

Actually yes, it is exactly the same case posted before, and this is why I am supersized from the memory error. I am just trying to deform it again, using the same command. I don’t think it’s a memory error.

Regards,
Saleh

#21

Hello Saleh,
Would you mind to share mesh, displacement and the exact command you are using?
I didn’t get if you are trying to further deform the output of a first run, or you are just running the very same command on the very same initial mesh (I have just checked and it still works on my computer).

Regards,
Luca

#22

Hi Luca,

Yes, I am trying to further deform the output of the first run.

Regards,

#23

Hello Saleh,
I am testing by imposing the same displacement on the output of the first deformation, and I can reproduce your problem. It seems to be an issue with the internal adaptation just after the movement that I haven’t fully identified yet.

Anyway, everything goes smooth if you use -lag 1 (only swap allowed to perform displacement).
While I try to correct the issue, a more robust solution to improve the mesh quality after the displacement could be that of running mmg3d in adaptation mode on the output (in a separate call) with the -optim option on.

Best regards,
Luca

1 Like