If that refinement is based on maximum temperature gradient inside the element it could lead to that nonsense number of elements.
The documentation only mentions energy density:
Adjusted mesh spacing is calculated in every mesh node basing on the variation of the energy density in the node’s vicinity, which is proven to be the most reliable estimation of error distribution.
But yeah, such adaptive refinements are typically flux-based. Abaqus uses heat flux error indicator.
1 Like
You’re right, lack of time doesn’t excuse the error. If mesh size is so crucial to the result, how will you verify a real-world scenario? With programs designed for 2D thermal calculations, such as Flixo or Therm, you don’t build such a precise mesh, and both programs are verified for compliance with the ISO10211 standard. In my opinion, your models have too complex a mesh for such simple shapes. What will you do if the real model is much more complex, for example, with small 10mm screws and an 8mm diameter heating cable? You have a huge model for a very simple example. Plus, a 2D problem requires so many layers in 3D? Start with large, regular elements and compare their sizes for the error value. In my opinion, the mesh shapes at the edge caused errors. Work on slicing and extruding the mesh. Fast meshing = big error. Lots of work on the mesh = fast and accurate results.
Program validation involves demonstrating that the maximum error in the results is less than the permissible value, considered a benchmark. The fact that someone manages to obtain an accurate result in 1 model out of 100 is not necessary. Are you meshing a 1000mm rectangle into 5mm tetrahedral elements? Have you seen my result for a 250mm mesh? After all, an accurate element is one with all sides equal. This condition is not met on an edge. This problem is not present in cubic elements. Tetrahedra are a solution for complex shells and result in longer computational times. In the best case, 1 cube = 2 tetrahedra.
In case 1, it’s also good to ensure that nodes are placed in the temperature measurement points to avoid interpolation errors. But indeed, a 2D model is enough:
Case 1 2D.pmx (59.7 KB)
1 Like
Nice, thanks. I’ll ping the devs there.
1 Like
TBH I tried to do 2D but couldn’t mesh, Then meshed it in Gmsh and imported to PrePoMax, but couldn’t run. Then saw that some programmes did it in 3D, so I did.
I looked at your file and it seems the results of many points would fall outside the allowed margin of error (fail) – maybe that’s why many programmes did 3D with fine meshing
The mesh in that file is not particularly dense (2 second-order elements per surface subregion). CalculiX internally expands 2D elements into 3D ones so it should be equivalent to hex mesh. Of course, you can also control the thickness, but there’s no specific value here.
1 Like
For your Case4 model, the element size limit is 10mm (1/5 B for B=50mm). The exact result is 5mm (1/10 B). Simply tighten the mesh at the edge.
Example 1:
Example 2:
Example 3:
Example 4:
Case4:
Comparison of the time taken to calculate the accuracy of your model’s result with mine.
A) 155 918 elements and a temperature of 0.8023 degrees Celsius
B) 1 372 838 elements and a temperature of 0.8003 degrees Celsius
The standard temperature result is 0.805 degrees Celsius
My:
Your:
I wanted to check the meshes used by QuickField or COMSOL, but they don’t show them. COMSOL just goes with “Extremely fine” for the exterior boundary of the
iron bar (regions with the largest temperature gradients) and default settings for the rest of the model. We also know that Simscale went the same way. They didn’t bother to use hex meshes either, but it’s definitely better to optimize the mesh, especially before publishing/sharing these validation cases somewhere (such as on the CalculiX forum).
1 Like
1 Like
Thanks @MisiaKu and @FEAnalyst. Happy for you to optimise the meshes and post the results here (I’m fairly new to PrePoMax and meshing)
It’s only slightly densified where I expect accurate results. This rule applies to all FEM programs. In construction, reinforced concrete slab calculations use a division of approximately 1/10 less width. I’m not a mesh expert like FEAnalyst. Don’t make holes in solids and slabs, as they initiate mesh densification around the sharp tip of the hole.
1 Like
Unfortunately, the result is worse than mine. The mesh is too loose. I tried it on cubes earlier.
A 4/50 split is bad. 5/50 is better.
I didn’t optimize it. Just generated a reasonably looking hex mesh. In the .pmx file it can be easily switched to second-orded and/or refined if needed. The algorithm is Gmsh transfinite so it can be easily refined by adjusting the global element size.
Ultimately, it would be good to export .inp files with minimum sufficient meshes and share them on the CalculiX forum.
(Sorry for any translation errors) For example 4, I don’t have a better idea for the temperature result on the outer side. In my opinion, the minimum mesh size on the rod is 1/10 * 50mm = 5mm, the maximum is 50mm. The mesh must be smooth and the mesh gradation between 0.1 and 0.3mm. TIE constraints should not be used as a shortcut, as they don’t yield anything. You can very quickly get a result of 0.801°C or, in a slightly longer timeframe, around 0.803°C. The best I can come up with requires additional subdivision and is 0.804°C. The exact result is 0.805°C. I can’t adjust the mesh any better. Additional subdivisions don’t yield anything.
1. Very fast and minimal work :
2. It’s better if you just adjust the meshing parameters a bi t :
3. It’s best if you need additional subdivisions of the solid s:
-370,1 mW − 60,68 mW − 61,68 mW − 47,57 mW = -540,03 mW
9303 + 7428 + 113608 + 36341 + 72021 = 238 701 Nodes
