[Dune] Returning Geometries As Objects

[Martin Nolte]

Hi Oli,

it's not assembly speed we care for. Our evolution operators are usually 
highly non-linear. From our experience, it is often more efficient to use a 
small timestep, so that few iterations of the solvers (non-linear and linear) 
are required. In this situation, assembling the matrix makes little sense (and 
is not required for Krylov methods), so we actually evaluate the linearized 
operator (i.e., we do a grid traversal) each time it is applied in the solver.

Providing numbers is always a lot of work and I don't care enough to do it. 
Besides, you're hard to convince, anyway. However, I do think code performance 
is an important piece in the success of Dune.

Best,

Martin

On 02/07/2012 03:55 PM, Oliver Sander wrote:
> Hi Martin,
>
>>
>> as far as I understood Christian, he wants the lifetime (I mean the time
>> in which the geometry remains valid) to be unlimited before the next
>> release. Changing the user code to call geometry only once (which would
>> be wise anyway) might take a lot of time and,
>
> This does not convince me, because a) I think the number of users that are as
> keen
> on top assembly speed as you are is not very big b) in standard assembly routines
> you usually acquire the geometry only once anyways c) until I hear numbers
> no speed-loss argument is going to convince me anyways.
>
> I know speed matters a great deal to your group, but I don't think you
> guys are representative for the greater Dune community.
>
> Cheers,
> Oliver
>
>> therefore, I think a
>> longer transition period would be good.
>>
>> Moreover, I'm still not sure on the correct path. I see at least three
>> possibilities:
>>
>> A geometry object is valid
>> (a) for ever (i.e., as long as it exists)
>> (b) as long as the grid, the entity belongs to
>> (c) as long as the entity exists within the grid
>> (d) as long as the corresponding entity pointer is valid (current
>> situation)
>>
>> I think we should at least prescribe (c), so that, e.g., references to
>> the corners are allowed.
>>
>> So: What kind of limit on the lifetime of a geometry do you have in mind?
>>
>> Best,
>>
>> Martin
>>
>>
>>
>> On 02/07/2012 11:56 AM, Oliver Sander wrote:
>>> This pretty much exactly reflects my view. I don't think I want the
>>> reference feature in there either. A variable that looks like an
>>> object but is in fact a reference is a big violation of the principle
>>> of least surprise. To me, the difficult-to-find bugs that lurk here
>>> are far more serious than potential speed loss.
>>>
>>> Concerning the speed loss: are the measurements of how much loss to
>>> expect? And can that not be mitigated in the calling code by making
>>> sure to call each geometry-Method only once?
>>>
>>> best,
>>> Oliver
>>>
>>>>
>>>> I'm against a merge, unless we agree to disable the reference feature
>>>> before the next release. Yes, this will require updates in all grid
>>>> implementations, but I think it is necessary to make this change show
>>>> its full potential and to actually value all the work and time you
>>>> spent here.
>>>>
>>>> If we can agree on this, I have no furthe objections regarding a
>>>> merge. I think it is well enough tested to actually do a merge. My
>>>> main concern is about adding undesired features which we (might) have
>>>> to deal with for an unforseable time.
>>>>
>>>> And "we agree" does not necessarily require a formal vote. I think it
>>>> just means that those people involved in (core) grid implementations
>>>> have to agree. I, for my part, am willing to do add the necessary
>>>> changes. Now we only need an opinion from Robert and Oliver [assuming
>>>> that you actually want to use you new feature ;-)].
>>>>
>>>> Cheers
>>>> Christian
>>>>
>>>>
>>>> _______________________________________________
>>>> Dune mailing list
>>>> Dune at dune-project.org
>>>> http://lists.dune-project.org/mailman/listinfo/dune
>>>
>>> _______________________________________________
>>> Dune mailing list
>>> Dune at dune-project.org
>>> http://lists.dune-project.org/mailman/listinfo/dune
>>

-- 
Dr. Martin Nolte <nolte at mathematik.uni-freiburg.de>

Universität Freiburg                                   phone: +49-761-203-5630
Abteilung für angewandte Mathematik                    fax:   +49-761-203-5632
Hermann-Herder-Straße 10
79104 Freiburg, Germany