[Dune] Returning Geometries As Objects

[Oliver Sander]

Hi Martin,
>
> Providing numbers is always a lot of work and I don't care enough to do
> it. Besides, you're hard to convince, anyway.

I am not hard to convince, but I am a scientist.  That means I want facts,
and I will not convinced by intuition alone.

:-)
Oliver

>  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
>>>
>