Import of UNV mesh type

[jessejohns]

The generic use of importing a mesh:

[Mesh]
file = example.unv
dim = 3
[]

Returns the error from line 686 of /src/mesh/unstructured_mesh.c:

if (mesh_data == NULL)
libmesh_error_msg("Error! You must pass a valid MeshData pointer to read UNV files!");

when trying to use a UNV mesh that is normally supported by libMesh.

[friedmud]

Is there any chance you could just not use UNV? Can your meshing program output something else (like Abaqus or even ExodusII)?

UNV is really not used very much so this isn't going to be a high priority for us...

[jessejohns]

SALOME is a commonly used CAD and meshing software and IDEAS UNV is very commonly used, particularly in CFD codes like OpenFOAM, Code_saturne, STAR-CCM+ and some FEM codes like ElmerFEM. Other formats from SALOME are MED, STL, GMF and CGNS. UNV is preferred because it supports many different cell shapes and descriptions for volumes and surfaces. MED and CGNS formats would also be desirable.

MOOSE workshop training indicates that UNV is supported, so I figured this would be supported.

[friedmud]

I'm not saying we won't support it... just that it's not going to get a high priority right now so you may be better off converting it to something else in the meantime...

[jwpeterson]

@jessejohns, any idea what type of elements are used in the oneRegion.unv and twoRegion.unv files you sent? I'm currently getting the error:

ERROR: UNV-element type 11 not supported.

so it appears to be some element that libmesh does not support reading. Some of the element types we do support are 41, 42, 44, 45, 91, 92, 94, 95, 111, 112, 115, 116, and 118...

Looking at the file, it seems like they might be 1D elements with 2 nodes? A quick google search for the the i-deas format didn't turn up anything helpful yet, so if you can point me to some authoritative documentation for the UNV format, that would also be helpful.

[jessejohns]

Hello,

Thank you for looking into this. I don't have documentation - I just requested it from Siemens, however, OpenFOAM has a mesh conversion tool that works very well. It can be found here:

https://github.com/OpenFOAM/OpenFOAM-2.3.x/blob/9fd0db5cf9fcf1bc2c3f79c7fc7640c2546c680d/applications/utilities/mesh/conversion/ideasUnvToFoam/ideasUnvToFoam.C

So, what I see from this is that "11" should simply be skipped. Lines 322-327:

if (feID == 11) { // Rod. Skip. is.getLine(line); is.getLine(line); }

[jwpeterson]

Your entire file consists of elements of type 11, so skipping that type would skip everything. I eventually came across this which shows that type 11 is a "beam" type element which has some extra data associated to it which we can probably ignore. I'm attempting to read them as 1D "Edge2" elements now, will let you know what happens...

[jwpeterson]

Your entire file consists of elements of type 11

Never mind, I didn't scroll down far enough. Looks like there are some type 41 (TRIs) and type 111 (TETs) elements there as well. We still might not be able to skip reading the 1D and 2D stuff though, in case they are used for setting BCs...

[jessejohns]

Those 11 elements (see
http://www.sdrl.uc.edu/universal-file-formats-for-modal-analysis-testing-1/file-format-storehouse/unv_2411.htm/)
in the beginning are simply defining the vertices that are used by when
defining 41 and 111 elements. All of the boundary conditions should only
be using the 41 elements - ie the faces of the surfaces.

This does bring up an interesting point, if one were to make "nodesets" --
If the 11 elements were skipped, then this might pose a problem.

On Fri, Jul 18, 2014 at 4:15 PM, jwpeterson notifications@github.com
wrote:

Your entire file consists of elements of type 11

Never mind, I didn't scroll down far enough. Looks like there are some
type 41 (TRIs) and type 111 (TETs) elements there as well. We still might
not be able to skip reading the 1D and 2D stuff though, in case they are
used for setting BCs...

—
Reply to this email directly or view it on GitHub
#3476 (comment).

[jessejohns]

So, it appears that the 2411 on line 19 and 2412 on line 2712 determines
which standard is being used and the purpose of the section. So, this
specifies the boundary conditions:

http://www.sdrl.uc.edu/universal-file-formats-for-modal-analysis-testing-1/file-format-storehouse/unv_2467.htm/

On Fri, Jul 18, 2014 at 4:22 PM, Jesse Johns jesse.m.johns@gmail.com
wrote:

Those 11 elements (see
http://www.sdrl.uc.edu/universal-file-formats-for-modal-analysis-testing-1/file-format-storehouse/unv_2411.htm/)
in the beginning are simply defining the vertices that are used by when
defining 41 and 111 elements. All of the boundary conditions should only
be using the 41 elements - ie the faces of the surfaces.

This does bring up an interesting point, if one were to make "nodesets" --
If the 11 elements were skipped, then this might pose a problem.

On Fri, Jul 18, 2014 at 4:15 PM, jwpeterson notifications@github.com
wrote:

Your entire file consists of elements of type 11

Never mind, I didn't scroll down far enough. Looks like there are some
type 41 (TRIs) and type 111 (TETs) elements there as well. We still might
not be able to skip reading the 1D and 2D stuff though, in case they are
used for setting BCs...

—
Reply to this email directly or view it on GitHub
#3476 (comment).

[jwpeterson]

I've gotten this branch to the point where we can successfully read the file, but I'll need to do more work to handle the elements of different dimension and to parse the boundary conditions section, which libmesh has never parsed before. So it's going to be a little while before it will all work in MOOSE.

[jessejohns]

Let me know if you want any more complicated boundary conditions when the
time comes.

Cheers.

On Fri, Jul 18, 2014 at 5:42 PM, jwpeterson notifications@github.com
wrote:

I've gotten this branch https://github.com/libMesh/libmesh/commits/unv
to the point where we can successfully read the file, but I'll need to do
more work to handle the elements of different dimension and to parse the
boundary conditions section, which libmesh has never parsed before. So it's
going to be a little while before it will all work in MOOSE.

—
Reply to this email directly or view it on GitHub
#3476 (comment).

[jwpeterson]

This has been working for a while now... forgot to close the issue.