(hotmail just switched formats and it looks like they are trying to force html
on everyone,
I'm top posting since I don't have any idea if the reply text is marked etc )
Is there any indication this is a problem with floating point precision as
someone pointed
out on another recent thread ? One of the first
things I did with libmesh was write my own mesh generator using rational
numbers( 2 ints for
numerator and denominator) and
was debating about trying to make a node with rational locations :) The original
meshes that I know about seem to be largely regularly spaced and refinements
just occur in multiples of the original spacing. No ideas on subsequent
deformations
or other modifications but this, combined with an obstacle source ( list of
polygons
at fixed voltages as precursors to electrodes ) looks like
it will work ok for me and it was a good excuse to play with rational numbers
rather than play with stochastic fp and tolerance parameters.
Also sometimes it is easier to read fractions or reduce precision in a
meaningful way
given a procedure for dividing up some numerical range. I can print these things
as n/(1<<m) for example .
fwiw. Thanks.
From: John Peterson <jwpeter...@gmail.com>
Sent: Monday, September 26, 2016 10:22 AM
To: Thiago Milanetto Schlittler
Cc: libmesh-users
Subject: Re: [Libmesh-users] TetGen mesh interface's "triangulate_pointset()"
stop running
On Sat, Sep 24, 2016 at 9:19 AM, Thiago Milanetto Schlittler <
thiago...@gmail.com> wrote:
> Hello!
>
> I'm having a weird problem with the method "triangulate_pointset()",
> from the TetGenMeshInterface class. Essentially, it seems like it is
> stalling after several calls. In my code, I have to calculate several
> polyhedron intersections and mesh them. To do so, I built a
> Mesh_Intersection class, which has the following method:
>
> void Mesh_Intersection::triangulate_intersection(const
> std::set<libMesh::Point> & input_points)
> {
> /*
> * input_points : set containing the intersection
> * polyhedron's vertices.
> * m_libMesh_PolyhedronMesh : a libMesh::Mesh, member of the
> Mesh_Intersection
> * cleared when calling this method.
> */
>
> m_libMesh_PolyhedronMesh.clear();
>
> // Insert points into the mesh
> for(std::set<libMesh::Point>::const_iterator it_set =
> input_points.begin();
> it_set != input_points.end();
> ++it_set)
> {
> m_libMesh_PolyhedronMesh.add_point(*it_set);
> }
>
> libMesh::TetGenMeshInterface
> temp_tetgen_interface(m_libMesh_PolyhedronMesh);
> temp_tetgen_interface.triangulate_pointset();
> }
>
> The code stalls at the last line. I already tested the input_points,
> and they are valid. I'm using libMesh 1.0.0, compiled with Intel icpc v.
> 16.0.3 and Intel MPI v. 5.1.2, on Linux. The m_libMesh_PolyhedronMesh is
> associated to a single processor. I don't think that it is a
> communicator problem because it happens even with only one processor. I
> think that the problem is associated to the compiler, since it works
> well on a machine where I used gcc 4.9. Did anyone else have a similar
> problem?
>
Yes, I have seen tetgen go into an infinite loop before, but due to the
complexity of the Tetgen codebase, was not really able to determine why at
the time. If I recall correctly, the problem was also
architecture/compiler dependent, and the mesh generation problem itself was
not complicated, i.e. just looking at the geometry, you would not think
that mesh generation would be an issue. I tried searching back through my
email for some thread that would have more information on this, but could
not find anything...
If tetgen is important to your application, you may want to try updating
it. We are still apparently using version 1.4.1 from back in 2006, but
there is a version 1.5 available from the tetgen.org website. Another
possibility you might want to investigate is the PETSc team's C-based
rewrite of Tetgen, called ctetgen (https://bitbucket.org/petsc/ctetgen). I
petsc / ctetgen — Bitbucket
bitbucket.org
f225517 ctetgen now uses regular PETSc makefile because ad hoc was fragile and
often did not work
get a ton of warnings when compiling Tetgen, and get the impression that it
is not the cleanest piece of code ever... if the PETSc guys decided to
entirely rewrite it and maintain a forked version, they probably had a
compelling reason to do so. I would definitely be willing to switch to
ctetgen (we'll probably have to update some of our interface code slightly
to do so) but don't really have time to work on that myself.
--
John
------------------------------------------------------------------------------
_______________________________________________
Libmesh-users mailing list
Libmesh-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-users
Libmesh-users Info Page - SourceForge
lists.sourceforge.net
To see the collection of prior postings to the list, visit the Libmesh-users
Archives. Using Libmesh-users: To post a message to all the list members ...
------------------------------------------------------------------------------
_______________________________________________
Libmesh-users mailing list
Libmesh-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-users
