dolfin team mailing list archive

[Marie Rognes <meg@xxxxxxxxx>]

On 21. okt. 2010 09:58, Anders Logg wrote:
> 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.
>


Works :)

--
Marie


> -- 
> 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
>
>