[Dune] Returning Geometries As Objects

[Martin Nolte]

Hi Oli,

as I already stated before, I don't expect any performance loss for 
well-programmed code. But: Existing codes might rely on fetching the geometry 
multiple times to be cheap. All I wanted is to smooth the path for these guys.

I think we can go with Andreas suggestion: If nobody steps forward on a 
potential performance loss in his current code, we don't really need a 
transition phase on this. The code will compile as it did before (except for 
the potentially dangling references that we have to cope with anyway).

 From the discussion (or rather from the silence) I conclude the following:
(a) We state in the documentation that the returned geometry object has to be 
valid until the next grid modification.
(b) We let the constructor of Dune::Geometry give a deprecation warning, if 
StoreGeometryReference::v is true, thus issueing a warning to the user.

I will include these changes into the branch until the end of the week and 
merge it (unless further need for discussion is expressed).

We will then need a set of FlySpray tasks for the transition of the grid 
implementations. It would be nice if someone could add them after the merge.

Best,

Martin


On 02/08/2012 11:58 AM, Oliver Sander wrote:
> Am 08.02.2012 11:28, schrieb Dedner, Andreas:
>> In my I only get the geometry object once anyway so I
>> would not see any performance impact. So for me the geometry can be
>> computed each time I call geometry().
>> The question is: is Oliver's
>> assumption correct that all users of DUNE do not care about the possible
>> performance impact (or if they do have assumed that calling geometry()
>> again and again might be a performance issue and have avoided it)?
>
> To be precise: my assumption is that *few* people care.
>
>
>> There has not been a lot
>> of comments on this issue from a lot of people which seems to indicate
>> that users are fine with the possible performance loss.
>
> Again, nobody seems to have any notion of how much loss we are talking
> about. Will my assembler need 0.5% more time? Or will assembly time
> quadruple? My degree of caring depends on the amount of performance
> loss that is to be expected.
>
> cheers,
> Oliver
>
>
>> So perhaps we do not need a transition phase for the sake of maintaining
>> performance? Perhaps people could comment...
>>
>> Best
>> Andreas
>>
>>
>> -----Original Message-----
>> From: dune-bounces+a.s.dedner=warwick.ac.uk at dune-project.org on behalf
>> of Martin Nolte
>> Sent: Wed 2/8/2012 6:35 AM
>> To: Oliver Sander
>> Cc: Dune
>> Subject: Re: [Dune] Returning Geometries As Objects
>>
>> 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
>>
>> _______________________________________________
>> 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