[Dune] dune-alugrid: why insertProcessBorder improves efficiency

[Andreas Dedner]

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dune-project.org/pipermail/dune/attachments/20141014/6c128f2c/attachment.htm>