[Dune] Returning Geometries As Objects

[Oliver Sander]

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
>