Hi all, I found the body surface triangles are CHANGED by the MMG3D during motion, although I have used Required/nosurf etc API functions to prevent the body surface from touching. Any suggestion?
Below is the resulted rotor blade surface
Hi Jay,
The required / nosurf tags are probably ignored during the motion step:
- otherwise the nosurf option will avoid any displacement (because displacement are applied on boundary triangles);
- following the same idea, the reauired triangles are used only when Mmg improves the mesh.
I suppose that you apply a displacement over the rotor blade surface? In this case, your displacement field must preserve the rotor surface.
I hope that it will helps,
Regards,
Algiane
Hi Algiane,
The rotor can maintain its shape at the beginning phase, while it is getting worse when rotating further.
I am sure the displacement field is correctly imposed only to the rotor surface. But you are right, the
require/nosurf seem gnored completely. It there any other way can preserve the rotor surface?
Shu-Jie LI (Jay)
http://www.csrc.ac.cn/groups/sjli/
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
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
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
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
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
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)
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
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
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
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
Update: Now the Lagrangian motion works with Scotch too.
Hi Luca,
What is the advantage of Scotch here if the Lagrangian doesn’t work in parallel? renumbering ?
Regards,
Saleh
Hello Saleh,
Yes, the latter, renumbering to speedup the execution by reducing cache misses.
Yours,
Luca
1 Like
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
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
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