dolfin team mailing list archive

["Garth N. Wells" <gnw20@xxxxxxxxx>]

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 ;).

Garth

> --
> Anders