Tetgen support with Libmesh

[Antoine Jacquey]

Hi all,

I have a question regarding the support of meshes generated using the software Tetgen (http://wias-berlin.de/software/tetgen/).
I am a long-time user of this mesh generator and I'm quite happy with it.

I saw that Libmesh can read and write tetgen meshes but in the Moose documentation, only the writing part is supported. Is this limited by Moose or is it just an omission in the documentation?

And if there is no possibilities to read those meshes for Moose, do you know any alternative to export a mesh generated by Tetgen to a supported format?

Thanks in advance.

Best,

Antoine J

[Peterson, JW]

On Thu, Jun 11, 2015 at 9:35 AM, Antoine Jacquey <antoine...@gmail.com> wrote:

Hi all,

I have a question regarding the support of meshes generated using the software Tetgen (http://wias-berlin.de/software/tetgen/).
I am a long-time user of this mesh generator and I'm quite happy with it.

I saw that Libmesh can read and write tetgen meshes but in the Moose documentation, only the writing part is supported. Is this limited by Moose or is it just an omission in the documentation?

Reading Tetgen files should work in MOOSE if you name them with .node or .ele extensions.  But, I suspect no one has tried this because Tetgen is no longer enabled by default in libmesh due to its license.  You have to configure libmesh (run update_and_rebuild_libmesh.sh) with --disable-strict-lgpl to get it.

As an aside, I've had a lot of trouble in the past getting Tetgen to generate meshes programmatically using the libmesh interface due to Tegen crashing, infinite looping, etc.  How do you typically use Tetgen to generate meshes?

And if there is no possibilities to read those meshes for Moose, do you know any alternative to export a mesh generated by Tetgen to a supported format?

 

We'll fix MOOSE if this doesn't work.

--

John

[Antoine Jacquey]

Ok thanks for your answer John.

I use a meshing software based on Tetgen developed in my center to deal with complex geometry (ref1 and ref2). Instead of reading the Tetgen mesh in Moose, I think we are going to add an Exodus II export in our software. In this sense it will be easier to define the side sets for the boundary conditions.

Thanks a lot.

Antoine

[Derek Gaston]

Antoine,

It should be straightforward to add ExodusII output support snd that will definitely make it a lot easier to use MOOSE. Let us know if you have questions about ExodusII.

As for your meshing software... is it available anywhere? It looks really cool...

Derek

--
You received this message because you are subscribed to the Google Groups "moose-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to moose-users...@googlegroups.com.
Visit this group at http://groups.google.com/group/moose-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/moose-users/659c4499-25c8-48d8-977c-612015b1101c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Peterson, JW]

On Fri, Jun 12, 2015 at 10:44 AM, Derek Gaston <frie...@gmail.com> wrote:

Antoine,

It should be straightforward to add ExodusII output support snd that will definitely make it a lot easier to use MOOSE. Let us know if you have questions about ExodusII.

As for your meshing software... is it available anywhere? It looks really cool...

I love that it's called "MeshIt". 

--

John

[Antoine Jacquey]

I manages to add a really simple output in ASCII format. I then use ncgen function to generate an ExodusII mesh file. That seems to work fine.
Do you have any tip to have a direct implementation of ExodusII format (I am not really familiar with writing binary files directly...)

With this export, I managed to deal with 2D domains (triangle elements) with block IDs within the 3D tetrahedra. In MeshIt, we often use also 1D blocks within 3D domains (to represent well path for example). I checked the Exodus documentation and I saw that there are several element types for 1D elements (TRUSS, BEAM and SHELL). I didn't really get the differences between them, has someone any tip?

I also have a non-related question. When I run a simulation with ExodusII output, I often can't read the file anymore when I have a lot of time steps for a big mesh (I open the Exodus file with paraview). I suppose it's related to the file size, no? Is there a way to avoid this problem?

Concerning MeshIt, there is no liscence yet, it's still under discussion with our institute but should be a free liscence anyway. If you want to give it a try, please contact the main developer (Mauro Cacace, cac...@gfz-potsdam.de) and he can send you an executable.

Cheers,
Antoine

[Cody Permann]

There is an ExodusII library that you can download off from SourceForge (the same on that exists in the "contrib" folder in libMesh. You'll want to use that library to write ExodusII format. There are indeed differences between the various element types. Some of them have more degrees of freedom and/or more "sides" within a given dimension. I know that's vague but I don't use all the various types myself either.

I haven't heard of not being able to read the mesh. Some of our users have single output files that are several Gigabytes in size. What errors are you getting? Can you run "ncdump" on the file?

Cody

--

You received this message because you are subscribed to the Google Groups "moose-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to moose-users...@googlegroups.com.
Visit this group at http://groups.google.com/group/moose-users.

To view this discussion on the web visit https://groups.google.com/d/msgid/moose-users/77763dee-bf92-43a6-bceb-30aec0a7df42%40googlegroups.com.

[Antoine Jacquey]

Ok tanks for this information.

Concerning the exodus output, it seems to be related to Windows, I can open the file with no problem on linux with Paraview. And nothing wrong with the file when I run ncdump on it.

[Derek Gaston]

What is the size of the file? What file system do you have on that Windows machine? Old Windows file systems wouldn't deal properly with files over 2GB...

On Wed, Jun 24, 2015 at 10:33 AM Antoine Jacquey <antoine...@gmail.com> wrote:

Ok tanks for this information.

Concerning the exodus output, it seems to be related to Windows, I can open the file with no problem on linux with Paraview. And nothing wrong with the file when I run ncdump on it.

--
You received this message because you are subscribed to the Google Groups "moose-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to moose-users...@googlegroups.com.
Visit this group at http://groups.google.com/group/moose-users.

To view this discussion on the web visit https://groups.google.com/d/msgid/moose-users/4827a463-fbce-4d7c-b84e-f814874d1d95%40googlegroups.com.

[Antoine Jacquey]

The file is 2.5 GB. I have NTFS file system on Windows.

[Derek Gaston]

NTFS should be fine.  In that case I would actually suspect that Paraview on Windows must not be able to handle files that large.

Just another reason NOT to use Windows ;-)

Derek

To view this discussion on the web visit https://groups.google.com/d/msgid/moose-users/0bac82eb-74c8-4fec-aad6-83ace67d5c48%40googlegroups.com.

[Cody Permann]

Before you go down this path. How big of a mesh are you running? Unless it's 10s to 100s of millions of elements you most likely won't see any significant savings in your mesh data structures and it can cost you quite of but of extra time too.

Also, if the mesh is small enough you can make it parallel after you read it in with the "distribution" parameter in the mesh block (which is yet another indication that you probably don't need parallel mesh in the first place).

Cody

On Fri, Jul 3, 2015 at 7:56 AM Antoine Jacquey <antoine...@gmail.com> wrote:

Hi,

I am trying to split an Exodus mesh using SEACAS/loadbal as mentionned in one tutorial.
What are the correct options to specify exactely?

I obtain a mesh.nem file but couldn't find a way to use it in my moose input file.

To view this discussion on the web visit https://groups.google.com/d/msgid/moose-users/bcfc84fc-3217-4748-a902-69f8caff4dd0%40googlegroups.com.

[Antoine Jacquey]

Yeah, I notice often that Windows is not the OS to use...

I have a unrelated question about mesh partioning. I saw somewhere in one pdf that one can use the SEACAS library (loadbal) to split a mesh into n pieces.
I installed this library and I now try to split a Exodus mesh into 24 pieces.

I didn't manage to find the proper arguments to give to loadbal to do that. Does anyone has an loadbal instruction line to share?

Thanks in advance.
Cheers,

Antoine

[Antoine Jacquey]

Thanks Cody, I hadn't seen your answer actually.

I managed to use loadbal and I did some tests.
So my mesh is about 500 k elements and indeed, like you said it takes a little bit more time when I split the mesh.

I will try with 5 millions elements to see if spliting the mesh speeds up the process.

Thanks a lot.

Antoine

[Cody Permann]

It should never be faster to use parallel mesh. It might use a little less memory but it won't be faster.

Cody

--
You received this message because you are subscribed to the Google Groups "moose-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to moose-users...@googlegroups.com.
Visit this group at http://groups.google.com/group/moose-users.

To view this discussion on the web visit https://groups.google.com/d/msgid/moose-users/c8d68d06-4a56-4943-961f-fe070b84e884%40googlegroups.com.

[Derek Gaston]

Cody is giving good advice here for the general case... Speed is usually not one of the reasons to use parallel mesh (in fact, many operations in MOOSE are sped up when using SERIAL mesh because we can take advantage of some of the redundancy!).

However I will say that it is technically possible for parallel mesh to read faster than serial mesh. You would need hundreds of millions of elements and need to be running on 10,000 or more processors and be using a parallel file system (like Lustre, etc.). In that case the disk contention can be freed up by using parallel mesh, so the whole simulation MIGHT start faster.

Parallel mesh is really intended for truly MASSIVE problems.

Derek

To view this discussion on the web visit https://groups.google.com/d/msgid/moose-users/CAK06EuV73rV23nRAMiR3fbZNrbx-cRVUC%2B8yb%2BO8ZyW_Nnyn0w%40mail.gmail.com.

[Antoine Jacquey]

Ok thanks a lot for your answers.

I might not need parallel mesh for now then.

Antoine

[Robert Podgorney]

Antoine,

Can you provide an update with how everything worked out for you on this?  I just noticed this discussion thread as I am in the process of trying to develop a workflow to go from Petrel and/or LeapFrog Geothermal into our FALCON code.  I just downloaded the MeshIt paper, and am looking forward to reading it.

Best,

Rob Podgorney

[eDgar]

On Monday, November 27, 2017 at 10:46:44 PM UTC, Robert Podgorney wrote:

Antoine,

Can you provide an update with how everything worked out for you on this?  I just noticed this discussion thread as I am in the process of trying to develop a workflow to go from Petrel and/or LeapFrog Geothermal into our FALCON code.  I just downloaded the MeshIt paper, and am looking forward to reading it.

Why is nobody using Gmsh? (actual question). It is GPL (no license issues), it has a GUI, can be scripted and seems to work pretty well.
http://gmsh.info/

[Antoine Jacquey]

Dear Robert,

As stated in my email, the developers of MeshIt are still discussing with our institution about licensing the source code to make it publicly availabl but they are confident that this will happen anytime soon. We will keep you updated.

Concerning Edgar comment, Gmsh is also useful but when we start dealing with complex geometries (geological reservoirs) and even more when we want to deal with lower dimensional elements embedded in a 3D mesh for representing fractures, faults or well paths, Gmsh may not be the most intuitive mesh generator and there are some space for further developments there.

Cheers,
Antoine

[Alexander Lindsay]

If you search this list, you should see that we have a fair number of gmsh users. I myself use gmsh regularly.

Alex

--

You received this message because you are subscribed to the Google Groups "moose-users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to moose-users+unsubscribe@googlegroups.com.
Visit this group at https://groups.google.com/group/moose-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/moose-users/55f3fd43-bdd9-4189-8bf4-925300b42c7d%40googlegroups.com.

[eDgar]

On Wednesday, November 29, 2017 at 10:15:15 AM UTC, Antoine Jacquey wrote:

Gmsh is also useful but when we start dealing with complex geometries (geological reservoirs) and even more when we want to deal with lower dimensional elements embedded in a 3D mesh for representing fractures, faults or well paths, Gmsh may not be the most intuitive mesh generator and there are some space for further developments there.

Very informative, merci Antoine.

[eDgar]

On Wednesday, November 29, 2017 at 3:34:30 PM UTC, Alexander Lindsay wrote:

If you search this list, you should see that we have a fair number of gmsh users. I myself use gmsh regularly.

Thanks, Alex, and good to know.

[Antoine Jacquey]

Yes, this is for sure, I also use Gmsh quite often. I was just mentioning some specific cases for which other mesh generators can be easier to use than Gmsh.

Cheers,

Antoine

To unsubscribe from this group and stop receiving emails from it, send an email to moose-users...@googlegroups.com.

Visit this group at https://groups.google.com/group/moose-users.