Discussion Locked This discussion was was locked by a forum moderator.

Making unions, intersections and such

Sergiy Kalnaus
Hello,
this is the question regarding the "Internal error in geometry decomposition" message that I'm consistently getting. What I'm trying to build is a 3D RVE of particulate composite (see attached picture). Each sphere has a soft shell and a hard core. So the shells can overlap, cores cannot. Also shells of course cannot penetrate the cores. I generate random 3D seed with spheres of prescribed size distribution (Gaussian in this case) using my own C++ code. Then input everything into COMSOL, sphere by sphere. By playing with Compose boolean operation I managed to remove parts of the shells that were protruding into cores (see one of the steps attached). Now I want to unite the shells. Two (in red) got merged without a problem. When I'm trying to add the third one (the bottom one) I get the geometry decomposition error. This error appears persistantly for a range of tolerances from 1e-03 to 1e-10. This is where I hit the wall really. What causes this error? Is there a better way to make such geometry? Tweaking repair tolerance helps in some cases, but does not in many cases. What do I do then (tolerance is the only variable I can change in this process)? In fact, quite often application of union results in dissapearance of the objects I was truing to merge. I guess I just don't get this logic.
Any help is much appreciated!
Thanks!


5 Replies Last Post 31/07/2015, 09:19 GMT-04:00
Posted: 5 years ago 16/11/2012, 01:30 GMT-05:00
Hi

I suspect it comes from the numerous silver faces you have when you make spheres just interact on a single point. For any FEM 2D or worse 3D model a point link is a singularity, for a mesh and the physics thereafter.

If you have a matrix of material, try to avoid that the "spheres" are touching, or that they touch and overlap frankly

--
Good luck
Ivar
Hi I suspect it comes from the numerous silver faces you have when you make spheres just interact on a single point. For any FEM 2D or worse 3D model a point link is a singularity, for a mesh and the physics thereafter. If you have a matrix of material, try to avoid that the "spheres" are touching, or that they touch and overlap frankly -- Good luck Ivar

Sergiy Kalnaus
Posted: 5 years ago 16/11/2012, 13:49 GMT-05:00
Ivar,
thank you for your reply. I need them to touch. Or to overlap just a little. The point is to study the percolation behavior and how the properties of "soft shells" influence that. What would be your suggestion on how to work around this?
I've run the scenarios of loose packings when the shells or spheres make no contact. Now it's time to switch to dense packings.
I just don't understand why in some cases making union works and in other nearly identical cases it doesn't. The error message does not give any details on what exactly caused the error...

Thank you very much for your time and help!
Ivar, thank you for your reply. I need them to touch. Or to overlap just a little. The point is to study the percolation behavior and how the properties of "soft shells" influence that. What would be your suggestion on how to work around this? I've run the scenarios of loose packings when the shells or spheres make no contact. Now it's time to switch to dense packings. I just don't understand why in some cases making union works and in other nearly identical cases it doesn't. The error message does not give any details on what exactly caused the error... Thank you very much for your time and help!

Posted: 5 years ago 16/11/2012, 15:26 GMT-05:00
Hi

I susepct, but it can come from other things too, that its linked to these small regions of just contact or little overlap. in "reality" I expect that you will not have true point contact, but rather local contact regions over a small cylindrical area. Perhaps it works by adding small cylinders, to avoid those silver faces which leads to long thin mesh elments and numerical errors for the meshing algorithm

--
Good luck
Ivar
Hi I susepct, but it can come from other things too, that its linked to these small regions of just contact or little overlap. in "reality" I expect that you will not have true point contact, but rather local contact regions over a small cylindrical area. Perhaps it works by adding small cylinders, to avoid those silver faces which leads to long thin mesh elments and numerical errors for the meshing algorithm -- Good luck Ivar

Daniyar Bossinov
Posted: 2 years ago 31/07/2015, 06:22 GMT-04:00

Hello,
this is the question regarding the "Internal error in geometry decomposition" message that I'm consistently getting. What I'm trying to build is a 3D RVE of particulate composite (see attached picture). Each sphere has a soft shell and a hard core. So the shells can overlap, cores cannot. Also shells of course cannot penetrate the cores. I generate random 3D seed with spheres of prescribed size distribution (Gaussian in this case) using my own C++ code. Then input everything into COMSOL, sphere by sphere. By playing with Compose boolean operation I managed to remove parts of the shells that were protruding into cores (see one of the steps attached). Now I want to unite the shells. Two (in red) got merged without a problem. When I'm trying to add the third one (the bottom one) I get the geometry decomposition error. This error appears persistantly for a range of tolerances from 1e-03 to 1e-10. This is where I hit the wall really. What causes this error? Is there a better way to make such geometry? Tweaking repair tolerance helps in some cases, but does not in many cases. What do I do then (tolerance is the only variable I can change in this process)? In fact, quite often application of union results in dissapearance of the objects I was truing to merge. I guess I just don't get this logic.
Any help is much appreciated!
Thanks!


Hello! How are you?
Can you send me your generated random 3D seed with spheres of prescribed size distribution (Gaussian) using your own C++ code please. My email dansho.91@mail.ru. Thank you!
[QUOTE] Hello, this is the question regarding the "Internal error in geometry decomposition" message that I'm consistently getting. What I'm trying to build is a 3D RVE of particulate composite (see attached picture). Each sphere has a soft shell and a hard core. So the shells can overlap, cores cannot. Also shells of course cannot penetrate the cores. I generate random 3D seed with spheres of prescribed size distribution (Gaussian in this case) using my own C++ code. Then input everything into COMSOL, sphere by sphere. By playing with Compose boolean operation I managed to remove parts of the shells that were protruding into cores (see one of the steps attached). Now I want to unite the shells. Two (in red) got merged without a problem. When I'm trying to add the third one (the bottom one) I get the geometry decomposition error. This error appears persistantly for a range of tolerances from 1e-03 to 1e-10. This is where I hit the wall really. What causes this error? Is there a better way to make such geometry? Tweaking repair tolerance helps in some cases, but does not in many cases. What do I do then (tolerance is the only variable I can change in this process)? In fact, quite often application of union results in dissapearance of the objects I was truing to merge. I guess I just don't get this logic. Any help is much appreciated! Thanks! [/QUOTE] Hello! How are you? Can you send me your generated random 3D seed with spheres of prescribed size distribution (Gaussian) using your own C++ code please. My email dansho.91@mail.ru. Thank you!

Walter Frei COMSOL Employee
Posted: 2 years ago 31/07/2015, 09:19 GMT-04:00
Hello,

Based upon the screenshots that you've posted, it does look like this model was generated in COMSOL version 3.5a or earlier, and this software was last released over five years ago.

We do first encourage you to upgrade to COMSOL version 5.1, as there have been significant improvements to the geometry code over the last several releases of the software.

We will close this thread for now, as the latest posted questions are digressing into topics unrelated to COMSOL Multiphysics. If there are related questions, please feel free to start a new thread.
Hello, Based upon the screenshots that you've posted, it does look like this model was generated in COMSOL version 3.5a or earlier, and this software was last released over five years ago. We do first encourage you to upgrade to COMSOL version 5.1, as there have been significant improvements to the geometry code over the last several releases of the software. We will close this thread for now, as the latest posted questions are digressing into topics unrelated to COMSOL Multiphysics. If there are related questions, please feel free to start a new thread.

Note that while COMSOL employees may participate in the discussion forum, COMSOL® software users who are on-subscription should submit their questions via the Support Center for a more comprehensive response from the Technical Support team.