[Dune-devel] [Dune-Commit] dune-geometry r167 - branches/mn-devel/dune/geometry

Sun Aug 5 17:01:01 CEST 2012

Hi Oli,

for the changes you did, there is no need for discussion at all. Cleaning up the 
GenericGeometry stuff is also a very good idea and I appreciate your effort, 
especially since the code is complicated template magic.

Unfortunately, my changes go further than yours and do contain interface changes 
(most notably the void specialization). To merge them into the trunk, discussion 
will be necessary.

Of course, you are very welcome to port these changes to the trunk by hand. But 
I guess you have other things to do beside merging by changes to the trunk.

For me, all these changes are still work in progress. So I will not port them 
personally to the trunk until I am content with the solution. Due to the 
interface changes, we will then have to discuss what shall go into the trunk and 
what not.

The upside of this approach is that the trunk will be very stable. The downside 
is that it might well be a year until my changes will be in the trunk. But I 
still think this development model (i.e., develop in branch, discuss, merge into 
trunk) is still better than the old one (i.e., discuss, develop in trunk or vice 
versa).

Best,

Martin

On 08/05/2012 12:27 PM, Oliver Sander wrote:
> Hi Martin,
>
>>
>> I am also a bit surprised by the sudden interest in reducing compile
>> time of the generic reference elements. My impression was that most
>> developers are ok with it and would prefer to wait for a thoroughly
>> discussed solution.
>
> My interest is cleaning up the Generic*** implementations, to make
> the more accessible for maintenance. Incidentally I believe that
> a saner implementation will solve a lot of your compile-time problems.
> Since I am merely cleaning up and not changing interfaces I don't
> see why a discussion would be needed.
>
> best,
> Oliver
>
>>
>> Best,
>>
>> Martin
>>
>>
>> On 08/05/2012 10:19 AM, Oliver Sander wrote:
>>> Hi Martin,
>>> sounds great. Why not merge this into the trunk?
>>> best,
>>> Oliver
>>>
>>> Am 03.08.2012 17:37, schrieb mnolte at dune-project.org:
>>>> Author: mnolte
>>>> Date: 2012-08-03 17:37:27 +0200 (Fri, 03 Aug 2012)
>>>> New Revision: 167
>>>>
>>>> Modified:
>>>> branches/mn-devel/dune/geometry/referenceelements.hh
>>>> Log:
>>>> nearly half memory consuption for ctype=void in 8d
>>>>
>>>>
>>>> Modified: branches/mn-devel/dune/geometry/referenceelements.hh
>>>> ===================================================================
>>>> --- branches/mn-devel/dune/geometry/referenceelements.hh 2012-08-03
>>>> 15:20:03
>>>> UTC (rev 166)
>>>> +++ branches/mn-devel/dune/geometry/referenceelements.hh 2012-08-03
>>>> 15:37:27
>>>> UTC (rev 167)
>>>> @@ -4,6 +4,7 @@
>>>> #define DUNE_GEOMETRY_REFERENCEELEMENTS_HH
>>>>
>>>> #include<dune/common/forloop.hh>
>>>> +#include<dune/common/nullptr.hh>
>>>> #include<dune/common/typetraits.hh>
>>>>
>>>> #include<dune/geometry/genericgeometry/subtopologies.hh>
>>>> @@ -155,16 +156,37 @@
>>>> template< int dim>
>>>> struct ReferenceElement< void, dim>::SubEntityInfo
>>>> {
>>>> + SubEntityInfo () : numbering_( nullptr ) {}
>>>> + ~SubEntityInfo () { delete[] numbering_; }
>>>> +
>>>> + SubEntityInfo ( const SubEntityInfo&other )
>>>> + : type_( other.type_ )
>>>> + {
>>>> + std::copy( other.offset_, other.offset_ + (dim+2), offset_ );
>>>> + numbering_ = new unsigned int[ offset_[ dim+1 ] ];
>>>> + std::copy( other.numbering_, other.numbering_ + offset_[ dim+1 ],
>>>> numbering_ );
>>>> + }
>>>> +
>>>> + const SubEntityInfo&operator= ( const SubEntityInfo&other )
>>>> + {
>>>> + type_ = other.type_;
>>>> + std::copy( other.offset_, other.offset_ + (dim+2), offset_ );
>>>> +
>>>> + delete[] numbering_;
>>>> + numbering_ = new unsigned int[ offset_[ dim+1 ] ];
>>>> + std::copy( other.numbering_, other.numbering_ + offset_[ dim+1 ],
>>>> numbering_ );
>>>> + }
>>>> +
>>>> int size ( int cc ) const
>>>> {
>>>> assert( (cc>= codim())&& (cc<= dim) );
>>>> - return numbering_[ cc ].size();
>>>> + return (offset_[ cc+1 ] - offset_[ cc ]);
>>>> }
>>>>
>>>> int number ( int ii, int cc ) const
>>>> {
>>>> assert( (ii>= 0)&& (ii< size( cc )) );
>>>> - return numbering_[ cc ][ ii ];
>>>> + return numbering_[ offset_[ cc ] + ii ];
>>>> }
>>>>
>>>> const GeometryType&type () const { return type_; }
>>>> @@ -174,20 +196,27 @@
>>>> const unsigned int subId = GenericGeometry::subTopologyId(
>>>> topologyId, dim,
>>>> codim, i );
>>>> type_ = GeometryType( subId, dim-codim );
>>>>
>>>> - for( int subcodim = 0; subcodim<= dim-codim; ++subcodim )
>>>> + // compute offsets
>>>> + for( int cc = 0; cc<= codim; ++cc )
>>>> + offset_[ cc ] = 0;
>>>> + for( int cc = codim; cc<= dim; ++cc )
>>>> + offset_[ cc+1 ] = offset_[ cc ] + GenericGeometry::size( subId,
>>>> dim-codim,
>>>> cc-codim );
>>>> +
>>>> + // compute subnumbering
>>>> + delete[] numbering_;
>>>> + numbering_ = new unsigned int[ offset_[ dim+1 ] ];
>>>> + for( int cc = codim; cc<= dim; ++cc )
>>>> {
>>>> - const unsigned int size = GenericGeometry::size( subId, dim-codim,
>>>> subcodim );
>>>> -
>>>> - numbering_[ codim+subcodim ].resize( size );
>>>> - for( unsigned int j = 0; j< size; ++j )
>>>> - numbering_[ codim+subcodim ][ j ] =
>>>> GenericGeometry::subTopologyNumber(
>>>> topologyId, dim, codim, i, subcodim, j );
>>>> + for( unsigned int ii = 0; ii< offset_[ cc+1 ] - offset_[ cc ]; ++ii )
>>>> + numbering_[ offset_[ cc ] + ii ] = GenericGeometry::subTopologyNumber(
>>>> topologyId, dim, codim, i, cc-codim, ii );
>>>> }
>>>> }
>>>>
>>>> private:
>>>> int codim () const { return dim - type().dim(); }
>>>>
>>>> - std::vector< unsigned int> numbering_[ dim+1 ];
>>>> + unsigned int *numbering_;
>>>> + unsigned int offset_[ dim+2 ];
>>>> GeometryType type_;
>>>> };
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Dune-Commit mailing list
>>>> Dune-Commit at dune-project.org
>>>> http://lists.dune-project.org/mailman/listinfo/dune-commit
>>>
>>> _______________________________________________
>>> Dune-devel mailing list
>>> Dune-devel at dune-project.org
>>> http://lists.dune-project.org/mailman/listinfo/dune-devel
>>
>
> _______________________________________________
> Dune-devel mailing list
> Dune-devel at dune-project.org
> http://lists.dune-project.org/mailman/listinfo/dune-devel

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