search

idaholab / moose

Multiphysics Object Oriented Simulation Environment
https://www.mooseframework.org
GNU Lesser General Public License v2.1
1.76k stars 1.05k forks source link

Import of UNV mesh type #3476

Closed jessejohns closed 10 years ago

jessejohns commented 10 years ago

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 commented 10 years ago

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 commented 10 years ago

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 commented 10 years ago

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 commented 10 years ago

@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 commented 10 years ago

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 commented 10 years ago

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 commented 10 years ago

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 commented 10 years ago

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 https://github.com/idaholab/moose/issues/3476#issuecomment-49480517.

jessejohns commented 10 years ago

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 https://github.com/idaholab/moose/issues/3476#issuecomment-49480517.

jwpeterson commented 10 years ago

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 commented 10 years ago

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 https://github.com/idaholab/moose/issues/3476#issuecomment-49487459.

jwpeterson commented 10 years ago

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