[Dune] dune-alugrid: why insertProcessBorder improves efficiency

Aleksejs Fomins aleksejs.fomins at lspr.ch
Tue Oct 14 15:21:14 CEST 2014


Dear Andreas,

Thank you for your reply.

This is good news. I will choose the route you propose.

Cheers,
Aleksejs

On 10/14/2014 03:14 PM, Andreas Dedner wrote:
> Hi.
> 1) The default behaviour of the GridFactory in ALUGrid is to figure out
> all missing boundary segments
>     but of course ones that have been added by the user are not
> overwritten or something - only
>     missing ones are added. So there is no problem when you ad all of
> them - only additional
>     computational cost because ALU has to figure out which boundary
> segments are missing (if any).
> 2) There is a non-standard method on the GridFactory:
>      Grid *createGrid ( const bool addMissingBoundaries, const
> std::string dgfName = "" );
>      So you can call factory.createGrid(fals);
>      if you are sure that all boundary segments (including the process
> borders have been added).
>      If all boundaries have been added this should lead to the same
> final grid as under (1) but will be
>      slightly more efficient - especially on large parallel machines.
> Andreas
> 
> On 14/10/14 08:28, Aleksejs Fomins wrote:
>> Hey Martin,
>>
>> I have just realized that it would be extremely convenient for me if I
>> forced the user to enter all boundarySegments to the
>> curvilinearGridFactory. The reason for that is that I need to keep track
>> of the curvature of the boundaries in the metagrid, and if AluGrid
>> decides to construct some extra boundaries it will be very hard to track
>> them later and interpolate over them.
>>
>> Is it possible to explicitly tell alugrid gridfactory that all boundary
>> segments will be provided and it need not create any additional ones, or
>> will it be able to figure it out?
>>
>> Regards,
>> Aleksejs
>>
>> On 10/07/2014 10:41 AM, Martin Nolte wrote:
>>> Hi Aleksejs,
>>>
>>> unfortunately, DUNE does not force you to insert all domain boundary
>>> segments. Hence, you cannot distinguish process borders from domain
>>> boundaries without actually matching them.
>>>
>>> If you actually know all domain boundaries, you can use your simple
>>> algorithm to detect the process borders and insert them by hand (with
>>> the given method). That's what the method is provided for!
>>>
>>> Internally, ALUGrid's grid factory will use exactly the same algorithm
>>> to find all boundaries of the local grid that have not been inserted by
>>> the user. To find out which of these are actually domain boundaries and
>>> which ones are process borders, these are then gathered on all
>>> processes. Each process then removes the _received_ set of boundaries
>>> from his map. What remains are actually domain boundaries. Yeah, it is a
>>> lot of work for a small interface deficiency ;-).
>>>
>>> But: Are you really sure you need to know this?
>>>
>>> Best,
>>>
>>> Martin
>>>
>>> On 10/07/2014 09:34 AM, Aleksejs Fomins wrote:
>>>> Dear Dune,
>>>>
>>>> I was thinking of calculating the process borders to pass to alugrid
>>>> constructor, and I do not understand why this operation requires global
>>>> communication as stated in the dune-alugrid paper.
>>>>
>>>> I propose the algorithm (3D):
>>>> 1) Make an std::set of faces (face = indices of all facial vertices
>>>> sorted in ascending order)
>>>> 2) Go over all elements on this process
>>>> 3) For all faces of each element, put face in the set
>>>> 4) If the set already contains this face, remove face from set instead
>>>> of inserting it
>>>> 5) Resulting set should contain only process borders and domain
>>>> boundaries
>>>> 6) Subtract domain boundaries that were inserted using
>>>> insertBoundarySegment on this process.
>>>>
>>>> No global communication, get interprocessor boundaries with complexity
>>>> O(N log N) where N is number of elements on the process.
>>>>
>>>>
>>>> Can somebody please hint me to what I am missing?
>>>>
>>>> Best,
>>>> Aleksejs
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> 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
> 
> 
> 
> 
> _______________________________________________
> Dune mailing list
> Dune at dune-project.org
> http://lists.dune-project.org/mailman/listinfo/dune
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 551 bytes
Desc: OpenPGP digital signature
URL: <https://lists.dune-project.org/pipermail/dune/attachments/20141014/8fc46919/attachment.sig>


More information about the Dune mailing list