[Dune-devel] MultiLinearGeometry with static GeometryType

Oliver Sander sander at igpm.rwth-aachen.de
Mon Oct 29 14:41:11 CET 2012


Hi Martin,
> statically known topologyIds are already implemented in the 
> MultiLinearGeometry (see hasSingleGeometryType in the traits class). 
> GeometryGrid makes use of this feature, if the host grid consists 
> solely of either simplices or cubes. My first tests indicate that the 
> "new" code is superior in peformance to the old one (around 20% 
> faster). However, further test have to be performed.
ah, I think I get it.  So the Type 'TopologyId' is either an unsigned 
int (in the dynamic case) or a special
type specifiying the geometry type directly?

Just out of curiosity: how much is the speed difference between 
MultiLinearGeometry with
and without hasSingleGeometryType set?  Because *in theory* the compiler 
would produce very
similar code if the run-time topologyId parameter would happen to be a 
compile-time constant.

>
> As to AlbertaGrid: The GenericGeometries are only used if you define 
> DUNE_ALBERTA_USE_GENERICGEOMETRY (as proof of concept). The 
> specialized Geometry implementation for AlbertaGrid makes use of some 
> Alberta internals and should be slightly more efficient. I am not yet 
> decided whether to adapt the GeneridGeometry variant to 
> MultiLinearGeometry or to it entirely.
>
But either way you would not want to keep BasicGeometry in there?

> With your second point you seem to have read my mind. Indeed, I 
> intended to use some helper class (call it factory, if you like) to 
> generate them.
Very nice.

> However, to my knowledge they are only used in the reference element 
> (where I have a simple replacement). So I currently don't consider 
> this a priority task.
I don't use them at all, but that's not to say it is not an interesting 
feature.  I remember Andreas
saying that he used them a bit.

>
> Discussing migrations from BasicGeometry to MultiLinearGeometry: What 
> should we do with the "old" implementation? It is quite a few files 
> and classes that are no longer needed. Would deprecating the 
> constructors of BasicGeometry be sufficient?
IMO, yes.

best,
Oliver

>
> Best,
>
> Martin
>
>
> On 10/29/2012 08:43 AM, Oliver Sander wrote:
>> Hi Martin,
>> I would like to get your opinion on something.  As far as I understand
>> there are at least two things that BasicGeometry does and 
>> MultiLinearGeometry
>> does not.
>>    The first one is to provide a Geometry with a 
>> GeometryType/topologyId that is
>> known at compile time.  Do you think that feature is still necessary? 
>> Or is a
>> MultiLinearGeometry called with a compile-time topologyId argument 
>> just as
>> fast?  Do you plan to implement a MultiLinearGeometry with a 
>> compile-time
>> topologyId in the future?
>> One place where that feature is used is in AlbertaGrid.  Would you 
>> object
>> to replacing the BasicGeometry in AlbertaGrid by a MultiLinearGeometry?
>>    The second point is the construction of trace geometries.  Do you 
>> think
>> it is feasable/a good idea to have that functionality in a sort-of 
>> factory class?
>> Ideally, such a factory would take a Geometry implementation and a 
>> subentity
>> number as input, and provide the corresponding trace geometry.
>> Thanks for you time,
>> Oliver
>>
>> _______________________________________________
>> Dune-devel mailing list
>> Dune-devel at dune-project.org
>> http://lists.dune-project.org/mailman/listinfo/dune-devel
>





More information about the Dune-devel mailing list