Help with import of mesh-files from the format .unv

Mesh generators, CAD programs, and other tools
elgrip
Posts: 9
Joined: 30 Nov 2011, 07:06
Antispam: Yes

Re: Help with import of mesh-files from the format .unv

Post by elgrip » 10 Feb 2012, 03:17

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 already-meshed 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 6-8 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 auto-hexahedralisation 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 10-20 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 10-20 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 pre-meshed beam.
(15.6 KiB) Downloaded 120 times

mzenker
Posts: 1741
Joined: 07 Dec 2009, 11:49
Location: Germany

Re: Help with import of mesh-files from the format .unv

Post by mzenker » 10 Feb 2012, 12:17

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

raback
Site Admin
Posts: 3264
Joined: 22 Aug 2009, 11:57
Antispam: Yes
Location: Espoo, Finland
Contact:

Re: Help with import of mesh-files from the format .unv

Post by raback » 10 Feb 2012, 16:49

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

elgrip
Posts: 9
Joined: 30 Nov 2011, 07:06
Antispam: Yes

Re: Help with import of mesh-files from the format .unv

Post by elgrip » 10 Feb 2012, 19:57

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.
BeamElmerTuteAlMetal.msh
Gmsh example
(725.61 KiB) Downloaded 139 times
Attachments
BeamSalomeMesh_2.unv
Salome first-order sample mesh
(510.49 KiB) Downloaded 136 times
BeamSalomeMesh_1Quadratic.unv
Salome sample quadratic mesh
(137.18 KiB) Downloaded 118 times

mzenker
Posts: 1741
Joined: 07 Dec 2009, 11:49
Location: Germany

Re: Help with import of mesh-files from the format .unv

Post by mzenker » 13 Feb 2012, 12:19

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

elgrip
Posts: 9
Joined: 30 Nov 2011, 07:06
Antispam: Yes

Re: Help with import of mesh-files from the format .unv

Post by elgrip » 14 Feb 2012, 18:11

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 already-meshed beam. That mesh works just fine. I don't know how that was generated however; maybe manually, and not from geometry translation.

mzenker
Posts: 1741
Joined: 07 Dec 2009, 11:49
Location: Germany

Re: Help with import of mesh-files from the format .unv

Post by mzenker » 14 Feb 2012, 19:38

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

raback
Site Admin
Posts: 3264
Joined: 22 Aug 2009, 11:57
Antispam: Yes
Location: Espoo, Finland
Contact:

Re: Help with import of mesh-files from the format .unv

Post by raback » 15 Feb 2012, 22:01

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:

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};
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 plug-in is a fork and hence we'll have to manually update the changes there sometimes time permitting.

-Peter

Post Reply