I am trying to mesh a volume consisting of a box cut by a complex surface (topography/bathymetry). I first mesh the surfaces (which takes an extremely long time), and then attempt to create the volume meshes. I am unable to get the first volume to mesh. In each case, I see:
mesh volume all
TetMeshGems mesher found!
WARNING: (7003050): WAR 3050
ERROR: /scratch/charlesw3/data/GNS-svn/charlesw/wiebke-2019/Tongariro_mesh/mesh_may_2021/tongariro_mesh_lev3a.jou (40). (-7003000): ERR 3000 : NOT ENOUGH MEMORY
WARNING: (7000000):
ELAPSED TIME 1.9e-05 SEC. ( 0 SEC. WITHOUT OVERHEAD)
ERROR: /scratch/charlesw3/data/GNS-svn/charlesw/wiebke-2019/Tongariro_mesh/mesh_may_2021/tongariro_mesh_lev3a.jou (40). Failed to adapt mesh
ERROR: /scratch/charlesw3/data/GNS-svn/charlesw/wiebke-2019/Tongariro_mesh/mesh_may_2021/tongariro_mesh_lev3a.jou (40). Volume 1 meshing unsuccessful using scheme: tetmesh
TetMeshGems mesher found!
WARNING: (7000000):
ELAPSED TIME 1.4e-05 SEC. ( 0 SEC. WITHOUT OVERHEAD)
-->Loading new coordinates
-->Loading tetrahedrons
Generated 6279410 tets for Volume 3.
WARNING: >>>>Poor Quality Tet Generated!<<<< on Volume 3
(For example, the Shape metric for Tet 1359019 is 0.0429614 .)
The threshold for a Tet is 0.2
Volume 3 meshing completed using scheme: tetmesh
Meshing time: 799.214818
ERROR: /scratch/charlesw3/data/GNS-svn/charlesw/wiebke-2019/Tongariro_mesh/mesh_may_2021/tongariro_mesh_lev3a.jou (40). 1 volume(s) did not mesh : 1
Even though some volumes failed to mesh, Cubit will log
the command in the journal file for future use.Although some entities failed to mesh, Cubit will log the command in the journal file anyway, for future use.
Finished Command: mesh volume all
So volume 3 is being meshed, but not volume 1. I have monitored the memory usage, and Cubit never uses more than 8.7% of the machine memory (system memory is 128 GB). For this problem, I am also using an Exodus field to control the cell sizing.
Is there some way to increase the allocated memory, or is there another way around this problem?
The “Failed to adapt mesh” error occurs only when you are using an Exodus type sizing function. The memory for mesh adaptation is defined in code as a minimum of 5Gb and it can grow based on the number of nodes in your background grid.
The memory is not a user settable parameter except by modifying the size of your background Exodus sizing function.
How may points are in your Exodus sizing function?
Thanks. I am specifying the sizing information at the nodes of a tetrahedral mesh (209,950 nodes, 1,259,329 cells). Is that too large? A couple of questions:
Once I have provided the sizing function information, is it OK to delete the associated mesh? If so, would that improve the memory issue?
Right now, I am providing all the sizing information in a single material block. Would it help to instead provide two blocks, and then delete the one I am not using? I would then reimport the sizing function mesh and delete the other block.
The code indicates that it is allocating 1 Mb for every 85 nodes. That means that you should only be allocating around 2.5 Gb. I am not sure about the root cause of this problem.
I would suggest trying your solution. Let me know if there is still a problem.
I tried my option #2 above and it did not work. I am still trying other options. I know that in the past I have used meshes over twice as large to provide my sizing function information without a problem; however, looking at some of my previous meshes, I realized that I was using Trelis to do that (either 17.0 or 17.1, I’m not sure which). Did something change which might cause this problem?
Thanks,
Charles
p.s. After looking in the manual I found something called ‘Sizing Source Sizing Function’, which does some of what I’m trying to do externally. I turned on developer features, but I am unable to get this feature to work. If all else fails, maybe that would be another option.
Hi Karl,
I have placed the relevant files on ftp: ftp://ftp.gns.cri.nz/pub/charlesw/cubit-test-26-July-2021. The tarball includes the mesh, the Cubit geometry file, the journal files I’m using, and a README. Please let me know if you need anything else.
I got the files and on my Linux box, it took all night to mesh surface 8. I have been able to replicate the problem and I am investigating the memory error.
Is this what you are expecting from the adaptive mesh refinement? The volume meshing was fast with the automatic memory assignment. I’m still looking into the surface meshing.
It’s a bit hard to tell. I’m attaching a couple of Paraview plots to show the sizing function info. The first is a slice through the entire mesh, where there is an ellipsoidal region with higher resolution in the center that dies off toward the boundaries. In the second plot I have thresholded the cell size to show that there are blobs of higher resolution surrounding our observation points (white dots). You don’t have the observation points but I can send them (VTK file) if it’s useful.
I set a clipping plane just above the dividing surface 8. It is hard to tell exactly, but it looks like the mesh density generally follows the VTK scalar plot that you have posted.
The fix for this is in our build pipeline and will be part of the next release.
@charlesw - we don’t have a firm release date yet, but you can grab our latest development releases (which should have the fix) from the public downloads page:
