[Dune] Returning Geometries As Objects

Wed Feb 8 14:14:30 CET 2012

Hi,
> 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).
I would agree, that many users (not developers) from the math community 
are no performance-freaks. And honestly, I would not delay your work 
because of possible performance loss of code which is not 
"well-programmed". IMHO, everyone who __really__ relies on performance 
has to take the effort of having well-programmed code.
Of course, the information about changes should be easily available. So 
why not just....
1.) add a warning to the svn-log and to the doxygen documentation of the 
function to reach everyone on the trunk.
2.) add a warning to the changelog for the next release and state it 
clearly on the homepage.
1.) and 2.) should be sufficient to warn most existing DUNE users.
3.) Our new students/colleagues usually start with the howtos / examples 
and then modify them to get their first programmes. So, if these 
examples are "well-programmed", the correct geometry handling should 
already spread through copy-and-paste....
But that's just a single-user opinion.....
Best,
Matthias
>
> 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.-Ing Dipl.-Math. Matthias Wohlmuth
************
**********  Department of Mathematics (M2)
********  Technische Universität München (TU Munich)
******  Boltzmannstr. 3, 85748 Garching, Germany
****
**  http://www-m2.ma.tum.de/bin/view/Allgemeines/MatthiasWohlmuth
****  matthias.wohlmuth at ma.tum.de
******  Phone: +49 89 / 289 18441
********  Fax: +49 89 / 289 18435
**********  Office: 03.10.036
*****************************************************************