dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

This should be fixed now. I'm surprised it wasn't detected before.

The problem was a missing check for how to "uniformly" partition 
tetrahedra into 8 smaller tetrahedra. One congruent tetrahedron is cut 
away from each corner and then the remaining octahedron is cut into 4 
more pieces. There are 3 choices for how to cut the octahedron and a 
check was missing for how to make that cut correctly (along the shortest 
of the 3 possible paths). I was under the impression that by cutting the 
along the same direction every time (relative to some numbering scheme), 
we could avoid that check, but apparently our numbering scheme does not 
help. Perhaps it did earlier and it broke at some point when the 
numbering scheme was changed.

I've added a check now so it should work, but please confirm that it does.

--
Anders


Douglas N Arnold skrev 2010-10-10 08.31:
> In my opinion this is a major problem.  In 2D one can
> test convergence by computing on an initial mesh and
> then repeating calling refine. The error decreases
> with the expected power. This does not happen at
> all in 3D, even in the simplest cases.
>
> There are many mesh refinement algorithms for 3D.
> The one I know, when applied repeatedly to the mesh
> given by UnitCube(1,1,1) will create the meshes
> given by UnitCube(2,2,2), UnitCube(4,4,4), ...
> The current refine is not doing that, which seems
> wrong to me.
>
> Examples of refinement algorithms that would work
> are the one in paper
> http://umn.edu/~arnold/papers/bistet.pdf
> or related algorithms by Maubach, Bansch, or Joe
> and Liu, which are referenced in that paper.
> Even the very simple to implement Rivara longest edge
> bisection would do the trick.
>
>
> On 10/07/2010 03:54 AM, Marie Rognes wrote:
> > Something slightly peculiar seems to happen with 3d refinement. Refining
> > a 1 x 1 x 1 Unit Cube 3 times gives largest cell diameter that is
> > increasing (but smallest cell diameter that is decreasing as expected).
> > It does not seem to (only) be a bug in hmax()/hmin(), odd convergence
> > rates are also observed. Any ideas?
> >
> > Example:
> >
> > from dolfin import *
> >
> > mesh = UnitCube(1, 1, 1)
> >
> > for i in range(3):
> > mesh = refine(mesh)
> >
> > print "Refinement level = ", i
> > print "h_max = ", mesh.hmax()
> > print "h_min = ", mesh.hmin()
> >
> > gives:
> >
> > Refinement level = 0
> > h_max = 1.65831239518
> > h_min = 0.866025403784
> > Refinement level = 1
> > h_max = 1.47901994577
> > h_min = 0.433012701892
> > Refinement level = 2
> > h_max = 1.7809758561
> > h_min = 0.216506350946
> >
> > --
> > Marie
>
> _______________________________________________
> Mailing list: https://launchpad.net/~dolfin
> Post to : dolfin@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~dolfin
> More help : https://help.launchpad.net/ListHelp


--
Anders