dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

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