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 : [email protected] >> Unsubscribe : https://launchpad.net/~dolfin >> More help : https://help.launchpad.net/ListHelp > > _______________________________________________ Mailing list: https://launchpad.net/~dolfin Post to : [email protected] Unsubscribe : https://launchpad.net/~dolfin More help : https://help.launchpad.net/ListHelp
