geom_decompose: wrong face numbering

I need to model two small wires segments (1 cm) in a large tank on either side of a disk that is about the size of a person:



The grid generation gets an error:

geom_decompose: wrong face numbering.

DiskNtankBetweenwires.fea

By shrinking the 'x' dimension (tank +/- 7.5m, wires at +/- 6m):



....the grid will generate:



DiskNtankBetweenwires-gridGenWorks.fea

But if the block (B1) x_min value is set to -7.51 (from -7.5), it fails.

I have tried smaller grid sizes.  I tried specifying grid size for each subdomain. What about reorienting the objects?

The wire dimensions are very small compared to 10m.  0.5mm radius. So that's a ratio of 10/.0005 = 2e4... Does this ratio (largest dimension to smallest dimension) have a practical limit?  Could some FEATool tolerance be changed by the user that might allow a greater difference (at some processing cost, no doubt).  

Unlike some of my models which turn out to be exploratory/learning tools, this one is tied to a specific geometry and experiment hat I want to replicate.

Any hints as to how to go about finding the problem and/or how to solve it would greatly appreciated.

Kind regards,
Randal

randress wrote

geom_decompose: wrong face numbering.

This message indicates that there has been an error in the decomposition of the geometry into minimal and non-overlapping domains. This should be equivalent to getting the intersection of OBJ1 and OBJ2, and OBJ1-OBJ2, as well as OBJ2-OBJ1 (if you manually create the minimal regions and it might work). I'm guessing the issue is the scale difference that the geometry engine can't handle well, I will try to have a look when I can but I'm not sure there is an easy fix. High aspect ratio/scale differences is unfortunately always very hard for these types of simulations, geometry, grid generation, as well as solvers.

I have released an update (Build 20.12.337) that tries to adjust tolerances to allow for larger scale differences which at least should allow this model to work. Note that if you can't really see your smallest objects when you have zoomed out on the largest one you're kind of pushing the limits for mesh based methods, at which point the smaller objects can be represented as singular points instead.

If you encounter this issue again with other geometries you can sometimes work around by first exporting your geometry as a BREP or STEP CAD file, and then meshing it manually in Gmsh as per the script below, after which the generated mesh should be able to be imported into FEATool again.


manual_gmsh_meshing.geo:

    SetFactory("OpenCASCADE");
    
    // Import Geometry (BREP or STEP CAD format).
    Merge "path_to_my_exported_geometry.brep";
    
    // Mesh size parameters.
    // (http://gmsh.info/doc/texinfo/gmsh.html#index-Mesh-size)
    // (Note API change CharacteristicLength... > MeshSize... from Gmsh v4.7.0)
    hmax = 0.1;
    Mesh.CharacteristicLengthExtendFromBoundary = 1;
    Mesh.CharacteristicLengthFromPoints = 1;
    Mesh.CharacteristicLengthFromCurvature = 1;
    Mesh.CharacteristicLengthMin = 0;
    Mesh.CharacteristicLengthMax = hmax;
    
    // Mesh geometry.
    Mesh 3;
    
    // Set output mesh format in v2
    // (http://gmsh.info/doc/texinfo/gmsh.html#MSH-file-format-version-2-_0028Legacy_0029)
    Mesh.MshFileVersion = 2;
    // Save all elements (http://gmsh.info/doc/texinfo/gmsh.html#index-Mesh_002eSaveAll)
    Mesh.SaveAll = 1;
    
    // Save mesh.
    Save "path_to_my_output_mesh.msh";