Negative number of tetrahedra in high-res mesh generation

Question

Hello,

I am trying to generate a high resolution mesh (dx = 2 um) with mesher, but the terminal output shows a negative number of tetrahedra. When I run it in a simulation, I get "std::bad_array_new_length" errors. Is there anything that can be done to get around this? 

This is my mesher script:

/u1/jav630/Jan10_openCARP-Actors/openCARP-Actors/environment_setup/openCARP/_build/bin/mesher \

-size[0] 0.1444 \

-size[1] 0.2604 \

-size[2] 0.159 \

-bath[0] -0.0 \

-bath[1] -0.0 \

-bath[2] -0.0 \

-center[0] 0.0722 \

-center[1] 0.1302 \

-center[2] 0.0795 \

-resolution[0] 2.0 \

-resolution[1] 2.0 \

-resolution[2] 2.0 \

-mesh 2024-08-01_Fine/block \

-Elem3D 0 \

-fibers.rotEndo 0.0 \

-fibers.rotEpi 0.0 \

-fibers.sheetEndo 90.0 \

-fibers.sheetEpi 90.0 \

-periodic 0 \

-periodic_tag 1234 \

-perturb 0.0

Please let me know if further information is required.

Thank you!

Joyce 

Answer 1

Mesher is a rather simple tool for generating small meshes on the fly. I don't think it's suitable for generating meshes with >3 billion elements.

https://gmsh.info might be a good option here.

Comments

Ok, I got that. I simulated the most recent mesh with the mesh.Block definition:

geom = mesh.Block(size=(1.444, 2.604, 1.590), resolution=args.dx/1000)

For me it is possible with your stimulus definition in a .par file:

stim[0].name            = "S1"
stim[0].elec.geom_type  = 2
stim[0].elec.p0[0]      = 0.0
stim[0].elec.p1[0]      = 222.0
stim[0].elec.p0[1]      = 0.0
stim[0].elec.p1[1]      = 222.0
stim[0].elec.p0[2]      = 0.0
stim[0].elec.p1[2]      = 222.0
stim[0].ptcl.duration   = 2.0
stim[0].pulse.strength  = 300

I do not get an empty stimulus error. I chose several combinations to test, e.g. --dt 10 and --dx 100.

So, this underlines the mesh definition is incorrect. Could you send me the mesh file in opencarp format? Something should be incorrect there. Maybe the coordinates of the electrode and the mesh do not match. Next would be the vtk file and if there are still problems I will install gmsh and check that.

---

Hi Moritz, thank you for your reply. In your testing did you try --dx 2 yet? If not, could you please try this value? The mesh and stimulus do work for all dx values greater than this, but I am interested in a resolution of 0.002 mm.

---

However, since I can't get any resolution working from an external mesh, I guess either way it makes sense to share the opencarp mesh files with you. Where can I send it?

---

Sorry for the delayed response. The problem is within the conversion of gmsh to openCARP readable mesh.

There are two ways which fixed the issue for me you could try:
1) you open the file with gmsh and add a volume "Physical groups" -> "Geometry" -> "Physical groups" -> "Add" -> "Volume" by clicking on the volume before you safe the mesh as vtk-file.

2) use a short bash script:
GMSH="/opt/homebrew/bin/gmsh"
$GMSH -parse_and_exit bidomain_005cm3.geo
sed -i 's/CellEntityIds/elemTags/g' bidomain_005cm3.vtk
meshtool convert -imsh=bidomain_005cm3.vtk -omsh=bidomain_005cm3 -ofmt=carp_txt

The mesh name is given by the path to your mesh files:
meshname = 'meshes/test/bidomain_005cm3'

After the conversion of the gmsh file you need to adjust your run.py and set the:
IntraTags = [27] and ExtraTags = [27]. This is the default, which is set if you add a volume the gmsh geometry.

I hope this solves the problem.

---

Hi Moritz, thank you for the response. After following those two steps, the test mesh (dx 100um) is working with openCARP now!

I am unfortunately having issues now with generating my original mesh in Gmsh, which has a dx of 2um.  At the start of this thread, Axel had suggested I use Gmsh because Mesher could not handle large meshes, however, despite using Gmsh, the process keeps getting killed. I am not sure if you can help with this as Gmsh is outside of your domain. If you happen to have any suggestions though, please let me know!

Either way, thanks again for your help.