libmesh-users

[Libmesh-users] size limit for exodus?

[robert <rob...@un...>]

Hello,

is there a size limit for writing exodus files and reading them with 
paraview?

I do

TetGenIO TG(mesh);
TG.read ("main_ldio.1.ele");
mesh.write("tryfunwrite.e");

and read it with paraview afterwards. If the file main_ldio.1.ele has 
less than 800 000  elements (all tetrahedra) it works fine, if it is 
bigger paraview gives me the error:

"A reader for tryfunwrite.e could not be found"
.

Reading and writing with libmesh works without error. If I write it as 
*.mesh file it works (however, if I set subdomains they are not written 
in *.mesh). I am pretty sure that the file is ok. I created it with 
tetgen and can look at it with medit.

Thanks,
Robert

Re: [Libmesh-users] size limit for exodus?

[Paul T. B. <ptb...@gm...>]

On Thu, Jun 7, 2012 at 9:42 AM, robert <rob...@un...> wrote:

> is there a size limit for writing exodus files and reading them with
> paraview?
>

To my knowledge, you are only limited by the memory on your computer. I've
used ParaView to visualize solutions with 20+ variables and several million
elements on my laptop no problem.

TetGenIO TG(mesh);
> TG.read ("main_ldio.1.ele");
> mesh.write("tryfunwrite.e");
>

The code is incomplete, but you're writing the mesh (which I'm assuming is
a Mesh object) and that will be written in ``libMesh" format. If you want
Exodus, you need to use an ExodusII object.

Paul

Re: [Libmesh-users] size limit for exodus?

[robert <rob...@un...>]

Thanks for the fast reply.
if I use an Exodus object I get the same result.
I'll try to find a better computer. But it's strange that ParaView asks 
me which reader to use if only my computer is the problem.



On 06/07/2012 04:47 PM, Paul T. Bauman wrote:
> On Thu, Jun 7, 2012 at 9:42 AM, robert <rob...@un... 
> <mailto:rob...@un...>> wrote:
>
>     is there a size limit for writing exodus files and reading them with
>     paraview?
>
>
> To my knowledge, you are only limited by the memory on your computer. 
> I've used ParaView to visualize solutions with 20+ variables and 
> several million elements on my laptop no problem.
>
>     TetGenIO TG(mesh);
>     TG.read ("main_ldio.1.ele");
>     mesh.write("tryfunwrite.e");
>
>
> The code is incomplete, but you're writing the mesh (which I'm 
> assuming is a Mesh object) and that will be written in ``libMesh" 
> format. If you want Exodus, you need to use an ExodusII object.
>
> Paul

Re: [Libmesh-users] size limit for exodus?

[robert <rob...@un...>]

But you're right, just installed paraview on a lab-computer and there it 
worked fine.
thanks

On 06/07/2012 04:47 PM, Paul T. Bauman wrote:
> On Thu, Jun 7, 2012 at 9:42 AM, robert <rob...@un... 
> <mailto:rob...@un...>> wrote:
>
>     is there a size limit for writing exodus files and reading them with
>     paraview?
>
>
> To my knowledge, you are only limited by the memory on your computer. 
> I've used ParaView to visualize solutions with 20+ variables and 
> several million elements on my laptop no problem.
>
>     TetGenIO TG(mesh);
>     TG.read ("main_ldio.1.ele");
>     mesh.write("tryfunwrite.e");
>
>
> The code is incomplete, but you're writing the mesh (which I'm 
> assuming is a Mesh object) and that will be written in ``libMesh" 
> format. If you want Exodus, you need to use an ExodusII object.
>
> Paul

Re: [Libmesh-users] size limit for exodus?

[John P. <jwp...@gm...>]

On Thu, Jun 7, 2012 at 8:47 AM, Paul T. Bauman <ptb...@gm...> wrote:
> On Thu, Jun 7, 2012 at 9:42 AM, robert <rob...@un...> wrote:
>
>> is there a size limit for writing exodus files and reading them with
>> paraview?
>>
>
> To my knowledge, you are only limited by the memory on your computer. I've
> used ParaView to visualize solutions with 20+ variables and several million
> elements on my laptop no problem.
>
> TetGenIO TG(mesh);
>> TG.read ("main_ldio.1.ele");
>> mesh.write("tryfunwrite.e");
>>
>
> The code is incomplete, but you're writing the mesh (which I'm assuming is
> a Mesh object) and that will be written in ``libMesh" format. If you want
> Exodus, you need to use an ExodusII object.

No, actually what he's done here is fine for producing an Exodus file.
 The mesh.write function tries to be smart like that...

I vaguely remember a "big" or "large" option being available for
ExodusII files, at least when writing from cubit?

I'm having a hard time finding the ExodusII documentation at the
moment, but it may be possible you are bumping up against this limit?

Depending on how old your paraview is, you might also just try getting
the latest version and see if that helps...

-- 
John

Re: [Libmesh-users] size limit for exodus?

[Paul T. B. <ptb...@gm...>]

On Thu, Jun 7, 2012 at 10:07 AM, John Peterson <jwp...@gm...> wrote:

> No, actually what he's done here is fine for producing an Exodus file.
>  The mesh.write function tries to be smart like that...
>

Dammit, you're right of course. I was thinking of solution writes. That's
what I get for not looking at the code first. Sorry for the confusion.

Re: [Libmesh-users] size limit for exodus?

[John P. <jwp...@gm...>]

On Thu, Jun 7, 2012 at 9:07 AM, John Peterson <jwp...@gm...> wrote:
> On Thu, Jun 7, 2012 at 8:47 AM, Paul T. Bauman <ptb...@gm...> wrote:
>> On Thu, Jun 7, 2012 at 9:42 AM, robert <rob...@un...> wrote:
>>
>>> is there a size limit for writing exodus files and reading them with
>>> paraview?
>>>
>>
>> To my knowledge, you are only limited by the memory on your computer. I've
>> used ParaView to visualize solutions with 20+ variables and several million
>> elements on my laptop no problem.
>>
>> TetGenIO TG(mesh);
>>> TG.read ("main_ldio.1.ele");
>>> mesh.write("tryfunwrite.e");
>>>
>>
>> The code is incomplete, but you're writing the mesh (which I'm assuming is
>> a Mesh object) and that will be written in ``libMesh" format. If you want
>> Exodus, you need to use an ExodusII object.
>
> No, actually what he's done here is fine for producing an Exodus file.
>  The mesh.write function tries to be smart like that...
>
> I vaguely remember a "big" or "large" option being available for
> ExodusII files, at least when writing from cubit?

This attachment probably won't make it to the list, but for
completeness, it looks like you are limited to about 90M nodes in the
"original" exodusII format, but the "large model" format is good up to
270M nodes.

With only 800k tets, I doubt you were anywhere near this...

-- 
John

[Libmesh-users] Remeshing during calculation with tetgen

[robert <rob...@un...>]

ok, thanks for your reply.
In general, do you have a better suggestion for a mesh generator? I need 
to predefine my geometry and subdomains in any CAD program, export it 
and mesh it. Then, during the calculation re-meshing would be great when 
the domains get deformed and the elements badly shaped.

So far I have tried the following: During the calculation the mesh is 
deformed. Then I write it to a file, re-mesh it manually with tetgen, 
import the new mesh to libmesh (new EquationSystems object), manually 
project the old solution on the new equationsystems with 
system.point_value (...) . However, point_value works with point_locator 
and for meshes with several million elements this takes too long. 
Strictly speaking, I start a new calculation with new mesh and 
equationsystems objects and use the old solution as starting conditions.

As I said, this is not very efficient and quite limited for application.

Thanks, Robert


On 06/07/2012 06:45 PM, John Peterson wrote:
> On Thu, Jun 7, 2012 at 10:23 AM, robert<rob...@un...>  wrote:
>> I think the problem is really my computer - i installed paraview on a better
>> machine and it works with the same file.
>>
>>
>> I'd just like to ask another question which might not be interesting enough
>> for the list:
>> can I use the class TetGenMeshInterface to re-construct my mesh when it
>> becomes badly shaped due to deformation?
> Probably not without some additional development and an improved
> understanding (on my part) of what Tetgen is actually capable of.
>
> If the geometry is relatively simple (no holes) it should in principle
> be possible to throw away all the elements and re-tetrahedralize
> through the TetGenMeshInterface::triangulate_conformingDelaunayMesh()
> interface.
>
> I will say that I have not found tetgen to be a particularly robust
> mesh generator in the past, however.  For example, I had to make the
> miscellaneous_ex6 geometry very simple for Tetgen to successfully
> generate a Mesh (and it behaved differently on Mac vs. Linux).
>
>> What happens with the
>> regions/subdomains and the EquationSystems object then.
> Well, throwing away all the elements as I suggested would obviously
> lose the subdomain information, so that would be trouble.
>
> Assuming you had a list of tet faces defining the subdomain
> boundaries,  it might be possible to perform a constrained Delaunay
> tetredralization in Tetgen, though I don't know how to do it and our
> interface doesn't provide the capability.
>
> The EquationSystems object *should* be able to re-initialize itself
> after significant changes to the Mesh... it is designed to do this for
> arbitrary refinement/coarsening, so it may just "work".
>
> A long-term goal of mine is to interface with a better tetrahedral
> mesh generation library in libmesh.
>

Re: [Libmesh-users] Remeshing during calculation with tetgen

[John P. <jwp...@gm...>]

On Fri, Jun 8, 2012 at 1:08 AM, robert <rob...@un...> wrote:
> ok, thanks for your reply.
> In general, do you have a better suggestion for a mesh generator? I need

There's CGAL (http://www.cgal.org/) which Andrew Slaughter mentioned
on the list a couple days ago (I hadn't heard of it before that).

Gmsh (http://www.geuz.org/gmsh/) appears to have an API, but I don't
know exactly what it can do, and I haven't found much documentation.

-- 
John

Re: [Libmesh-users] Remeshing during calculation with tetgen

[Martin L. <lu...@va...>]

Hi Robert

robert <rob...@un...> writes:
> In general, do you have a better suggestion for a mesh generator? I need 
> to predefine my geometry and subdomains in any CAD program, export it 
> and mesh it. Then, during the calculation re-meshing would be great when 
> the domains get deformed and the elements badly shaped.

GMSH usually works nicely. I usually write the nodal coordinats of the
outlines to a file, read them with Python, call gmsh in batch mode, and
then start a new simulation from scratch (no state variables to be
mapped). Not effiecient nor elegant, but at least this works more
reliably than calling Triangle from within Libmesh.

If I remember correctly, gmsh is using Triangle internally (did not check).

Would be nice to have a better generic solution, though.

Best, Martin