<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 6.5.7655.11">
<TITLE>RE: [Dune] Returning Geometries As Objects</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->
<P><FONT SIZE=2>In my I only get the geometry object once anyway so I<BR>
would not see any performance impact. So for me the geometry can be<BR>
computed each time I call geometry().<BR>
The question is: is Oliver's<BR>
assumption correct that all users of DUNE do not care about the possible<BR>
performance impact (or if they do have assumed that calling geometry()<BR>
again and again might be a performance issue and have avoided it)?<BR>
There has not been a lot<BR>
of comments on this issue from a lot of people which seems to indicate<BR>
that users are fine with the possible performance loss.<BR>
So perhaps we do not need a transition phase for the sake of maintaining<BR>
performance? Perhaps people could comment...<BR>
<BR>
Best<BR>
Andreas<BR>
<BR>
<BR>
-----Original Message-----<BR>
From: dune-bounces+a.s.dedner=warwick.ac.uk@dune-project.org on behalf of Martin Nolte<BR>
Sent: Wed 2/8/2012 6:35 AM<BR>
To: Oliver Sander<BR>
Cc: Dune<BR>
Subject: Re: [Dune] Returning Geometries As Objects<BR>
<BR>
Hi Oli,<BR>
<BR>
it's not assembly speed we care for. Our evolution operators are usually<BR>
highly non-linear. From our experience, it is often more efficient to use a<BR>
small timestep, so that few iterations of the solvers (non-linear and linear)<BR>
are required. In this situation, assembling the matrix makes little sense (and<BR>
is not required for Krylov methods), so we actually evaluate the linearized<BR>
operator (i.e., we do a grid traversal) each time it is applied in the solver.<BR>
<BR>
Providing numbers is always a lot of work and I don't care enough to do it.<BR>
Besides, you're hard to convince, anyway. However, I do think code performance<BR>
is an important piece in the success of Dune.<BR>
<BR>
Best,<BR>
<BR>
Martin<BR>
<BR>
On 02/07/2012 03:55 PM, Oliver Sander wrote:<BR>
> Hi Martin,<BR>
><BR>
>><BR>
>> as far as I understood Christian, he wants the lifetime (I mean the time<BR>
>> in which the geometry remains valid) to be unlimited before the next<BR>
>> release. Changing the user code to call geometry only once (which would<BR>
>> be wise anyway) might take a lot of time and,<BR>
><BR>
> This does not convince me, because a) I think the number of users that are as<BR>
> keen<BR>
> on top assembly speed as you are is not very big b) in standard assembly routines<BR>
> you usually acquire the geometry only once anyways c) until I hear numbers<BR>
> no speed-loss argument is going to convince me anyways.<BR>
><BR>
> I know speed matters a great deal to your group, but I don't think you<BR>
> guys are representative for the greater Dune community.<BR>
><BR>
> Cheers,<BR>
> Oliver<BR>
><BR>
>> therefore, I think a<BR>
>> longer transition period would be good.<BR>
>><BR>
>> Moreover, I'm still not sure on the correct path. I see at least three<BR>
>> possibilities:<BR>
>><BR>
>> A geometry object is valid<BR>
>> (a) for ever (i.e., as long as it exists)<BR>
>> (b) as long as the grid, the entity belongs to<BR>
>> (c) as long as the entity exists within the grid<BR>
>> (d) as long as the corresponding entity pointer is valid (current<BR>
>> situation)<BR>
>><BR>
>> I think we should at least prescribe (c), so that, e.g., references to<BR>
>> the corners are allowed.<BR>
>><BR>
>> So: What kind of limit on the lifetime of a geometry do you have in mind?<BR>
>><BR>
>> Best,<BR>
>><BR>
>> Martin<BR>
>><BR>
>><BR>
>><BR>
>> On 02/07/2012 11:56 AM, Oliver Sander wrote:<BR>
>>> This pretty much exactly reflects my view. I don't think I want the<BR>
>>> reference feature in there either. A variable that looks like an<BR>
>>> object but is in fact a reference is a big violation of the principle<BR>
>>> of least surprise. To me, the difficult-to-find bugs that lurk here<BR>
>>> are far more serious than potential speed loss.<BR>
>>><BR>
>>> Concerning the speed loss: are the measurements of how much loss to<BR>
>>> expect? And can that not be mitigated in the calling code by making<BR>
>>> sure to call each geometry-Method only once?<BR>
>>><BR>
>>> best,<BR>
>>> Oliver<BR>
>>><BR>
>>>><BR>
>>>> I'm against a merge, unless we agree to disable the reference feature<BR>
>>>> before the next release. Yes, this will require updates in all grid<BR>
>>>> implementations, but I think it is necessary to make this change show<BR>
>>>> its full potential and to actually value all the work and time you<BR>
>>>> spent here.<BR>
>>>><BR>
>>>> If we can agree on this, I have no furthe objections regarding a<BR>
>>>> merge. I think it is well enough tested to actually do a merge. My<BR>
>>>> main concern is about adding undesired features which we (might) have<BR>
>>>> to deal with for an unforseable time.<BR>
>>>><BR>
>>>> And "we agree" does not necessarily require a formal vote. I think it<BR>
>>>> just means that those people involved in (core) grid implementations<BR>
>>>> have to agree. I, for my part, am willing to do add the necessary<BR>
>>>> changes. Now we only need an opinion from Robert and Oliver [assuming<BR>
>>>> that you actually want to use you new feature ;-)].<BR>
>>>><BR>
>>>> Cheers<BR>
>>>> Christian<BR>
>>>><BR>
>>>><BR>
>>>> _______________________________________________<BR>
>>>> Dune mailing list<BR>
>>>> Dune@dune-project.org<BR>
>>>> <A HREF="http://lists.dune-project.org/mailman/listinfo/dune">http://lists.dune-project.org/mailman/listinfo/dune</A><BR>
>>><BR>
>>> _______________________________________________<BR>
>>> Dune mailing list<BR>
>>> Dune@dune-project.org<BR>
>>> <A HREF="http://lists.dune-project.org/mailman/listinfo/dune">http://lists.dune-project.org/mailman/listinfo/dune</A><BR>
>><BR>
<BR>
--<BR>
Dr. Martin Nolte <nolte@mathematik.uni-freiburg.de><BR>
<BR>
Universität Freiburg phone: +49-761-203-5630<BR>
Abteilung für angewandte Mathematik fax: +49-761-203-5632<BR>
Hermann-Herder-Straße 10<BR>
79104 Freiburg, Germany<BR>
<BR>
_______________________________________________<BR>
Dune mailing list<BR>
Dune@dune-project.org<BR>
<A HREF="http://lists.dune-project.org/mailman/listinfo/dune">http://lists.dune-project.org/mailman/listinfo/dune</A><BR>
<BR>
</FONT>
</P>
</BODY>
</HTML>