On Thu, Feb 10, 2011 at 11:58:03AM +0000, Garth N. Wells wrote: > > > On 10/02/11 11:54, Anders Logg wrote: > > On Thu, Feb 10, 2011 at 11:49:54AM +0000, Garth N. Wells wrote: > >> > >> > >> On 10/02/11 10:24, Marie E. Rognes wrote: > >>> On 02/10/2011 12:03 AM, Garth N. Wells wrote: > >>>> > >>>> On 09/02/11 22:43, Anders Logg wrote: > >>>>> On Wed, Feb 09, 2011 at 10:11:40AM -0800, Johan Hake wrote: > >>>>>> Hello! > >>>>>> > >>>>>> I am pretty sure the reason the Macbot still complains (mesh unit > >>>>>> test) is > >>>>>> that refine is broken for SWIG 2.0. > >>>>>> > >>>>>> I think it is some premature destruction of a refined mesh. I would > >>>>>> suggest we > >>>>>> implement a full shared_ptr version of the interface to get around this > >>>>>> problem. I have no clue of why it works for SWIG 1.3.40. Probably > >>>>>> because a > >>>>>> faulty implementation. > >>>>>> > >>>>>> I also suggest more developers upgrade to SWIG 2.0.1 and maybe one of > >>>>>> the > >>>>>> linux build bots two? If it is only the Macbot that uses SWIG 2.0 it > >>>>>> is easily > >>>>>> to think it is some Mac specific error. > >>>>>> > >>>>>> Johan > >>>>> I plan to merge with main tomorrow if my buildbot is green. Then Marie > >>>>> also needs to merge (we have both touched refine.h/cpp). Then we can > >>>>> sort out the shared_ptrs. > >>>>> > >>>> I really don't get the approach to hierarchies. Mesh refinement was > >>>> simple, and now something simple has become complex (with bugs that are > >>>> hard to track down because of the introduced complexity). > >>>> > >>> > >>> I really do get the approach to hierarchies. Mesh refinement was and is > >>> simple, but dealing with the consequences of mesh refinement has never > >>> been. A couple of different designs regarding the refinement of function > >>> spaces, functions, forms etc have been tested over the last year. I (and > >>> the AdaptiveSolver) find the current Hierarchical design transparent, > >>> elegant, and very much to the point. > >>> > >> > >> What is the function names are changed to 'adapt' (or similar)? 'refine' > >> is not very accurate because a mesh, etc, could well be refined or > >> coarsened, or nodes could just be relocated. > >> > >> With 'adapt', the purpose would be clear and it would sit nicely in the > >> directory 'adaptivity'. > >> > >> In mesh, we can keep refine as it was, and at some point add coarsen and > >> a mixture of refinement and coarsen. > > > > Yes, 'adapt' sounds like a more suitable name and 'refine' could be > > reserved for meshes. > > > > We could have adapt(mesh) and refine(mesh). Only the former would > > touch the hierarchy. Does that sound good? > > It would stop my complaining ;).
That would be a relief. ;-) -- Anders _______________________________________________ Mailing list: https://launchpad.net/~dolfin Post to : [email protected] Unsubscribe : https://launchpad.net/~dolfin More help : https://help.launchpad.net/ListHelp
