Help with import of meshfiles from the format .unv
Re: Help with import of meshfiles from the format .unv
TOPIC: Still Mesh Import; but more generally, Elmer and Mesh Simulation Accuracies and Compatibilities.
Hello Peter; thanks for the request for the 'minimalistic example';
Following upon the above conversation thread, the Elmer tutorial for elasticity has an alreadymeshed beam to work with. Replacing its material with Elmer's Al metal, which has the same character as the US grade 6061 Al alloy, yields a displacement of about 9mm under load, which also agrees with the SolidWorks and theory results.
Attached is the "BeamElmerTuteAlMetal.STP" file I used to attempt meshing with Elmer, Gmsh, and Salome.
So firstly, here are the crazy results from Elmer and Gmsh:
With Elmer standard mesh settings, I got 1.4m deflection. Putting H=10 in nglib yielded 7.9m deflection. Remeshing with ElmerGrid gave 68 trapezoids deep meshing through the beam height, but 7.9m deflection.
Using GMSH simple meshing, order 2, with 1 or 2 trapezoid depth, 8.9m defl. Putting max size = 5, order 2 yielded no convergence for Elmer. With max size = 10, Frontal 2 + 3D yielded 7.3m defl. With max size 20, order 2; 9m defl.
In general Gmsh quads and frontal choices yield a mesh but Elmer solver did not run with such meshes.
Final Gmsh test was with Frontal all, no recombine triangles, min/max 0/10, element order 2, with about 6 mesh depth on short side, plus tetrahedral optimisation, yielded a deflection of 4m after 26 Elmer iterations.
And now here are the more realistic results using Salome's meshes ...
Hexahedral regular mesh, exported as "unv", about 15 elements per short side face of the beam, and running Elmers' TFQMR solver, ILU0, 21 iterations with mostly 500 internal iterations, started to converge at the 15th run, yielding 5.4 mm deflection, which is only a factor of about 2 from reality.
Slight change to GCR, ILU1 after 7 iterations gave 5.4mm deflection.
With autohexahedralisation in Salome, using 6 members per side with widths scaled from edge to centre to other edge as 1, 0.7, 0.4, 0.4, 0.7, 1 at the positions 0, 0.2, 0.4, 0.6, 0.8, 1 positions yielded 1.9mm deflection. With 10 members per side, 3.7mm deflection; and 15 members per side, 5.4mm deflection. Changing the density of members to attain a lower density in the centre yielded 5.1mm deflection for 15 members; but going to 30 elements per side yielded finally 7.7mm, within about 10% of reality but with very slow Elmer convergence.
With tetrahedral meshes in Salome, 0.1 'length' parameter, got 1.7mm defl. But with 0.01 'length', got 1020 elements per side and 7.9mm deflection  at last! And with 0.005 'length', yielding 170,000 volumes and a very regular mesh with about 40 elements on the 100mm face, was very slow to mesh but Elmer analysed very fast, for the pretty exact 8.8mm result.
For similar testing that I performed on a simple Al disk 200mm dia 10mm thick, with atmospheric pressure on one side and with a fixed rim, where the expected deflection is 25 microns, again I found Elmer and Gmsh did not work, but Salome with 'length' of 0.002 and 170,000 elements (seems like a lot, doesn't it!) gave 21 microns whereas 0.005 'length' was only 17 micron deflection, too far off to be useful. Salome kept working well yielding up to 22 micron deflection, until I reached 0.001 'length', where it failed. With such dense meshes, Elmer's result, and time to converge, was independent of the solution method.
So my conclusion from the above is that you can put a lot of work into Elmer's and Gmsh's meshes, but Salome yields reasonable results right away. And Salome works best with Tet meshes, is almost accurate enough with 1020 elements per side but 40 elements per side (or almost 200,000 elements on a simple shape) will bring it up to expectation levels; and that Salome's quadratic mesh output always crashes Elmer, or is a null field as you found.
Hello Peter; thanks for the request for the 'minimalistic example';
Following upon the above conversation thread, the Elmer tutorial for elasticity has an alreadymeshed beam to work with. Replacing its material with Elmer's Al metal, which has the same character as the US grade 6061 Al alloy, yields a displacement of about 9mm under load, which also agrees with the SolidWorks and theory results.
Attached is the "BeamElmerTuteAlMetal.STP" file I used to attempt meshing with Elmer, Gmsh, and Salome.
So firstly, here are the crazy results from Elmer and Gmsh:
With Elmer standard mesh settings, I got 1.4m deflection. Putting H=10 in nglib yielded 7.9m deflection. Remeshing with ElmerGrid gave 68 trapezoids deep meshing through the beam height, but 7.9m deflection.
Using GMSH simple meshing, order 2, with 1 or 2 trapezoid depth, 8.9m defl. Putting max size = 5, order 2 yielded no convergence for Elmer. With max size = 10, Frontal 2 + 3D yielded 7.3m defl. With max size 20, order 2; 9m defl.
In general Gmsh quads and frontal choices yield a mesh but Elmer solver did not run with such meshes.
Final Gmsh test was with Frontal all, no recombine triangles, min/max 0/10, element order 2, with about 6 mesh depth on short side, plus tetrahedral optimisation, yielded a deflection of 4m after 26 Elmer iterations.
And now here are the more realistic results using Salome's meshes ...
Hexahedral regular mesh, exported as "unv", about 15 elements per short side face of the beam, and running Elmers' TFQMR solver, ILU0, 21 iterations with mostly 500 internal iterations, started to converge at the 15th run, yielding 5.4 mm deflection, which is only a factor of about 2 from reality.
Slight change to GCR, ILU1 after 7 iterations gave 5.4mm deflection.
With autohexahedralisation in Salome, using 6 members per side with widths scaled from edge to centre to other edge as 1, 0.7, 0.4, 0.4, 0.7, 1 at the positions 0, 0.2, 0.4, 0.6, 0.8, 1 positions yielded 1.9mm deflection. With 10 members per side, 3.7mm deflection; and 15 members per side, 5.4mm deflection. Changing the density of members to attain a lower density in the centre yielded 5.1mm deflection for 15 members; but going to 30 elements per side yielded finally 7.7mm, within about 10% of reality but with very slow Elmer convergence.
With tetrahedral meshes in Salome, 0.1 'length' parameter, got 1.7mm defl. But with 0.01 'length', got 1020 elements per side and 7.9mm deflection  at last! And with 0.005 'length', yielding 170,000 volumes and a very regular mesh with about 40 elements on the 100mm face, was very slow to mesh but Elmer analysed very fast, for the pretty exact 8.8mm result.
For similar testing that I performed on a simple Al disk 200mm dia 10mm thick, with atmospheric pressure on one side and with a fixed rim, where the expected deflection is 25 microns, again I found Elmer and Gmsh did not work, but Salome with 'length' of 0.002 and 170,000 elements (seems like a lot, doesn't it!) gave 21 microns whereas 0.005 'length' was only 17 micron deflection, too far off to be useful. Salome kept working well yielding up to 22 micron deflection, until I reached 0.001 'length', where it failed. With such dense meshes, Elmer's result, and time to converge, was independent of the solution method.
So my conclusion from the above is that you can put a lot of work into Elmer's and Gmsh's meshes, but Salome yields reasonable results right away. And Salome works best with Tet meshes, is almost accurate enough with 1020 elements per side but 40 elements per side (or almost 200,000 elements on a simple shape) will bring it up to expectation levels; and that Salome's quadratic mesh output always crashes Elmer, or is a null field as you found.
 Attachments

 BeamElmerTuteAlMetal.STEP
 STP file for the Elmer Beam Elasticity tutorial, for meshing tests to compare with the Elmer tute's premeshed beam.
 (15.6 KiB) Downloaded 132 times
Re: Help with import of meshfiles from the format .unv
Hi ,
I would be curious to know what the differences between the meshes are. Apparently the gmsh and Salome meshes are so different that the results differ by 3 orders of magnitude. Could you post some example meshes so that one can get a feeling on what gmsh did wrong and Salome did right?
Matthias
I would be curious to know what the differences between the meshes are. Apparently the gmsh and Salome meshes are so different that the results differ by 3 orders of magnitude. Could you post some example meshes so that one can get a feeling on what gmsh did wrong and Salome did right?
Matthias

 Site Admin
 Posts: 3359
 Joined: 22 Aug 2009, 11:57
 Antispam: Yes
 Location: Espoo, Finland
 Contact:
Re: Help with import of meshfiles from the format .unv
Hi elgrip
Thanx for the detailed explanation. However, with "minimalistic example" I meant the .unv file with quadratic elements. I don't use Salome myself.
Peter
Thanx for the detailed explanation. However, with "minimalistic example" I meant the .unv file with quadratic elements. I don't use Salome myself.
Peter
Re: Help with import of meshfiles from the format .unv
Thanks for the quick replies and requests for meshes. Here are some examples; the .msh are from Gmsh, and the .unv are from Salome; and of course you can always just import the earlier .stp geometry file into Elmer and see how Elmer meshes it, and then gives similar results to what I found. Some of my meshes were about 30MB in size so the attached files are small samples.
 Attachments

 BeamSalomeMesh_2.unv
 Salome firstorder sample mesh
 (510.49 KiB) Downloaded 148 times

 BeamSalomeMesh_1Quadratic.unv
 Salome sample quadratic mesh
 (137.18 KiB) Downloaded 130 times
Re: Help with import of meshfiles from the format .unv
Hmmm...
The msh file won't load in gmsh ("wrong vertex index 0") and crashes ElmerGUI. The unv file (BeamSalomeMesh_2.unv) crashes ElmerGUI, but opens in gmsh.
Does the msh file open for you in gmsh or ElmerGUI?
Matthias
The msh file won't load in gmsh ("wrong vertex index 0") and crashes ElmerGUI. The unv file (BeamSalomeMesh_2.unv) crashes ElmerGUI, but opens in gmsh.
Does the msh file open for you in gmsh or ElmerGUI?
Matthias
Re: Help with import of meshfiles from the format .unv
Sorry; I chose the files randomly, to be small enough to fit the 1MB restriction for upload to this forum. I am not sure of exactly what those .msh and .unv files relate to, given the very large experimental space I described traversing in my prior post.
Please import the .stp geometry into Elmer, gmsh, or Salome, and see what happens. You should discover the same problems I found. If there are methods of obtaining the correct physical results from Elmer or gmsh, or of obtaining correct results from Salome with larger mesh resolution, they would be very helpful solutions to the above mysteries.
As noted before, the original tutorial for Elmer has an alreadymeshed beam. That mesh works just fine. I don't know how that was generated however; maybe manually, and not from geometry translation.
Please import the .stp geometry into Elmer, gmsh, or Salome, and see what happens. You should discover the same problems I found. If there are methods of obtaining the correct physical results from Elmer or gmsh, or of obtaining correct results from Salome with larger mesh resolution, they would be very helpful solutions to the above mysteries.
As noted before, the original tutorial for Elmer has an alreadymeshed beam. That mesh works just fine. I don't know how that was generated however; maybe manually, and not from geometry translation.
Re: Help with import of meshfiles from the format .unv
Hi,
I am not a mechanics guy and have never done elastcity simulations before, so someone else has to help you here. I was just interested in the kind of mesh that did work and did not work for your case.
Matthias
I am not a mechanics guy and have never done elastcity simulations before, so someone else has to help you here. I was just interested in the kind of mesh that did work and did not work for your case.
Matthias

 Site Admin
 Posts: 3359
 Joined: 22 Aug 2009, 11:57
 Antispam: Yes
 Location: Espoo, Finland
 Contact:
Re: Help with import of meshfiles from the format .unv
Hi
The current svn version (rev. 5562) has some fixes that were able to read in the .unv examples provided above. Among other things node ordering in Elmer and unv is totally different. For example, for quadratic hexas the permutation is:
As you can understand this requires some manual work is is prone to errors.
To get these to use you must recompile ElmerGrid. Unfortunately the ElmerGUI plugin is a fork and hence we'll have to manually update the changes there sometimes time permitting.
Peter
The current svn version (rev. 5562) has some fixes that were able to read in the .unv examples provided above. Among other things node ordering in Elmer and unv is totally different. For example, for quadratic hexas the permutation is:
Code: Select all
int order820[]={1,3,5,7,13,15,17,19,2,4,6,8,9,10,11,12,14,16,18,20};
To get these to use you must recompile ElmerGrid. Unfortunately the ElmerGUI plugin is a fork and hence we'll have to manually update the changes there sometimes time permitting.
Peter