Bad cell diameter in gear mesh

Bug #1082157 reported by Joachim Haga on 2012-11-22
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
DOLFIN
Medium
Anders Logg

Bug Description

See https://bugs.launchpad.net/bugs/1034187.

The mesh used in the elasticity demo (demo/undocumented/elasticity/python/gear.xml.gz) reports a very large hmax(). hmax() is reported as 36.001, but the whole mesh is smaller than 1 in all directions. Maybe related to numerical precision for nearly degenerate cells?

from dolfin import *
mesh = Mesh("gear.xml.gz")

c = Cell(mesh, 18847)
print c.diameter()
# 36.001483031

print c.volume()
# 7.373890632542822e-11

Anders Logg (logg) on 2012-11-23
Changed in dolfin:
assignee: nobody → Anders Logg (logg)
importance: Undecided → Medium
milestone: none → 1.1.0

On reflection, perhaps it is correct after all. The diameter in
question is the diameter of the sphere with all four vertices on the
surface; i.e., it goes to infinite as the cell degenerates.

What the glyph scaling requires is really a measure of the
characteristic cell size; something with a reasonable maximum value
even in the presence of some bad cells in the mesh. It could be
incircle/insphere, or just longest side length. Is there a method to
calculate this for a (general) cell?

On 23 November 2012 08:08, Anders Logg <email address hidden> wrote:
> ** Changed in: dolfin
> Assignee: (unassigned) => Anders Logg (logg)
>
> ** Changed in: dolfin
> Importance: Undecided => Medium
>
> ** Changed in: dolfin
> Milestone: None => 1.1.0
>
> --
> You received this bug notification because you are a member of DOLFIN
> Team, which is subscribed to DOLFIN.
> https://bugs.launchpad.net/bugs/1082157
>
> Title:
> Bad cell diameter in gear mesh
>
> Status in DOLFIN:
> New
>
> Bug description:
> See https://bugs.launchpad.net/bugs/1034187.
>
> The mesh used in the elasticity demo
> (demo/undocumented/elasticity/python/gear.xml.gz) reports a very large
> hmax(). hmax() is reported as 36.001, but the whole mesh is smaller
> than 1 in all directions. Maybe related to numerical precision for
> nearly degenerate cells?
>
> from dolfin import *
> mesh = Mesh("gear.xml.gz")
>
> c = Cell(mesh, 18847)
> print c.diameter()
> # 36.001483031
>
> print c.volume()
> # 7.373890632542822e-11
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/dolfin/+bug/1082157/+subscriptions

Anders Logg (logg) wrote :

On Fri, Nov 23, 2012 at 10:19:03AM -0000, Joachim Haga wrote:
> On reflection, perhaps it is correct after all. The diameter in
> question is the diameter of the sphere with all four vertices on the
> surface; i.e., it goes to infinite as the cell degenerates.

Is the problem a tet in a corner of the mesh? Explains why I couldn't
fix it by a simple smoothing.

> What the glyph scaling requires is really a measure of the
> characteristic cell size; something with a reasonable maximum value
> even in the presence of some bad cells in the mesh. It could be
> incircle/insphere, or just longest side length. Is there a method to
> calculate this for a (general) cell?

No, but we could easily add something to the Cell class to compute
that, perhaps Cell::longest_edge_length(), or max_edge_length()? We
could also add min_edge_length().

--
Anders

> On 23 November 2012 08:08, Anders Logg <email address hidden> wrote:
> > ** Changed in: dolfin
> > Assignee: (unassigned) => Anders Logg (logg)
> >
> > ** Changed in: dolfin
> > Importance: Undecided => Medium
> >
> > ** Changed in: dolfin
> > Milestone: None => 1.1.0
> >
> >
> > Title:
> > Bad cell diameter in gear mesh
> >
> > Status in DOLFIN:
> > New
> >
> > Bug description:
> > See https://bugs.launchpad.net/bugs/1034187.
> >
> > The mesh used in the elasticity demo
> > (demo/undocumented/elasticity/python/gear.xml.gz) reports a very large
> > hmax(). hmax() is reported as 36.001, but the whole mesh is smaller
> > than 1 in all directions. Maybe related to numerical precision for
> > nearly degenerate cells?
> >
> > from dolfin import *
> > mesh = Mesh("gear.xml.gz")
> >
> > c = Cell(mesh, 18847)
> > print c.diameter()
> > # 36.001483031
> >
> > print c.volume()
> > # 7.373890632542822e-11
> >
> > To manage notifications about this bug go to:
> > https://bugs.launchpad.net/dolfin/+bug/1082157/+subscriptions
>

Joachim Haga (jobh) wrote :
Download full text (3.4 KiB)

Just a misunderstanding. The mesh can probably be fixed. I was more
concerned with what I thought was an erroneous calculation.

For the plotting I will calculate a characteristic value from the
bounding box and number of vertices, for now, I think. Perhaps some
other measure for the mesh may be useful in other instances. For
example, when deciding the time step for transport problems, the edge
size of the element is more relevant than the circumradius.

But for now, let this bug be about improving the mesh :)

-j.

On 23 November 2012 11:49, Anders Logg <email address hidden> wrote:
> On Fri, Nov 23, 2012 at 10:19:03AM -0000, Joachim Haga wrote:
>> On reflection, perhaps it is correct after all. The diameter in
>> question is the diameter of the sphere with all four vertices on the
>> surface; i.e., it goes to infinite as the cell degenerates.
>
> Is the problem a tet in a corner of the mesh? Explains why I couldn't
> fix it by a simple smoothing.
>
>> What the glyph scaling requires is really a measure of the
>> characteristic cell size; something with a reasonable maximum value
>> even in the presence of some bad cells in the mesh. It could be
>> incircle/insphere, or just longest side length. Is there a method to
>> calculate this for a (general) cell?
>
> No, but we could easily add something to the Cell class to compute
> that, perhaps Cell::longest_edge_length(), or max_edge_length()? We
> could also add min_edge_length().
>
> --
> Anders
>
>
>> On 23 November 2012 08:08, Anders Logg <email address hidden> wrote:
>> > ** Changed in: dolfin
>> > Assignee: (unassigned) => Anders Logg (logg)
>> >
>> > ** Changed in: dolfin
>> > Importance: Undecided => Medium
>> >
>> > ** Changed in: dolfin
>> > Milestone: None => 1.1.0
>> >
>> >
>> > Title:
>> > Bad cell diameter in gear mesh
>> >
>> > Status in DOLFIN:
>> > New
>> >
>> > Bug description:
>> > See https://bugs.launchpad.net/bugs/1034187.
>> >
>> > The mesh used in the elasticity demo
>> > (demo/undocumented/elasticity/python/gear.xml.gz) reports a very large
>> > hmax(). hmax() is reported as 36.001, but the whole mesh is smaller
>> > than 1 in all directions. Maybe related to numerical precision for
>> > nearly degenerate cells?
>> >
>> > from dolfin import *
>> > mesh = Mesh("gear.xml.gz")
>> >
>> > c = Cell(mesh, 18847)
>> > print c.diameter()
>> > # 36.001483031
>> >
>> > print c.volume()
>> > # 7.373890632542822e-11
>> >
>> > To manage notifications about this bug go to:
>> > https://bugs.launchpad.net/dolfin/+bug/1082157/+subscriptions
>>
>
> --
> You received this bug notification because you are a member of DOLFIN
> Team, which is subscribed to DOLFIN.
> https://bugs.launchpad.net/bugs/1082157
>
> Title:
> Bad cell diameter in gear mesh
>
> Status in DOLFIN:
> New
>
> Bug description:
> See https://bugs.launchpad.net/bugs/1034187.
>
> The mesh used in the elasticity demo
> (demo/undocumented/elasticity/python/gear.xml.gz) reports a very large
> hmax(). hmax() is reported as 36.001, but the whole mesh is smaller
> than 1 in all directions. Maybe related to numerical precision for
> nearly degenerate cells?
>
> from dolfin import *
>...

Read more...

Changed in dolfin:
milestone: 1.1.0 → trunk
Changed in dolfin:
status: New → Confirmed
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers