[Dune] parallel DUNE grid for implementing a spherical shell (UGGrid)

Eike Mueller E.Mueller at bath.ac.uk
Fri Nov 16 19:19:03 CET 2012


Dear all,

I can now also generate the icosahedral macro grid (see attached .vtu file), however when I write this out with the DGFWriter, 
the prisms do not get written to disk. Is there a way around this or do I have to do it by hand?

Thanks a lot,

Eike



Eike Mueller wrote:
> Dear all,
> 
> thank you very much for all your help, I have now solved the load 
> balancing issue, at least for the hexahedral grid.
> I wrote some sequential code which creates a macro grid with p elements 
> using the UGgrid factory, and save this as a .dgf file. I then wrote a 
> parser for .dgf files, which reads the grid from disk and also adds 
> boundary segments (this is not supported for UG at the moment). If I 
> then read in my .dgf file on p processors, all I need to do is call 
> loadBalance() and each processor automatically ends up with one element, 
> which I can then refine further. It means that at some point I store the 
> entire macro grid on one processor, but I think that is fine, as this 
> grid will maximally contain 10,000s of cells, and there is probably no 
> way this can be avoided, even if I set up the grid with a factory in one 
> go.
> 
> I did come across some strange behaviour in the DGFWriter, though. When 
> writing out the file, I got a
> 
> Warning: Ignoring nonpositive boundary id: 0
> 
> and it would not add this boundary segment to the .dgf file, which meant 
> I could not read it properly later. I traced this down to this bit of 
> code in dune/grid/io/file/dgfparser/dgfwriter.hh:
> 
> inline void DGFWriter< GV >::write ( std::ostream &gridout ) const
> [...]
> if( boundaryId <= 0 )
>         {
>           std::cerr << "Warning: Ignoring nonpositive boundary id: "
>                     << boundaryId << "." << std::endl;
>           continue;
>         }
> [...]
> 
> If I change the condition to "if( boundaryId < 0 )"
> 
> it works. Why does it exclude boundaryId = 0?
> 
> Next goal is doing the same for the icosahedral grid, for this I will 
> need prisms, and again they should only be subdivided in the horizontal 
> direction.
> 
> Thanks, Eike
> 
> PS: Andreas, the code has been checked into the GungHo! repository.
> 
> Oliver Sander wrote:
>> Am 13.11.2012 12:29, schrieb Dedner, Andreas:
>>> I might be wrong but I think Yasp only distributes the macro grid 
>>> like ALU does?
>>> So if you start with only one element then there is no way to 
>>> loadbalance it.
>>> As far as I know only UG differs from this behaviour allowing to 
>>> loadbalance leaf elements
>>> "arbitrarily" over the processors....
>> Yes, UG supposedly does that.  It is called 'vertical load 
>> balancing'.  I have never
>> actually done that, though (never had to).  Therefore I don't really 
>> know how
>> it works and whether you need special flags or anything.
>> -- 
>> Oliver
>>
>>> ________________________________________
>>> From: dune-bounces+a.s.dedner=warwick.ac.uk at dune-project.org 
>>> [dune-bounces+a.s.dedner=warwick.ac.uk at dune-project.org] on behalf of 
>>> Eike Mueller [E.Mueller at bath.ac.uk]
>>> Sent: 13 November 2012 11:04
>>> To: Oliver Sander
>>> Cc: dune at dune-project.org
>>> Subject: Re: [Dune] parallel DUNE grid for implementing a spherical 
>>> shell (UGGrid)
>>>
>>> To make it even simpler, I replaced the UGGrid by an 1x1x1 YaspGrid, 
>>> i.e. I start with a grid with one element. If I
>>> globalRefine() this once, and then loadBalance(), one processor 
>>> always ends up with the entire grid. I must be missing something
>>> very basic here.
>>> Does the load balancing in DUNE assume that if a father cell is owned 
>>> by a processor, then all it's children on the finer levels
>>> are owned by the same processor? But then calling loadBalance() after 
>>> grid refinement would not make sense. If I start with a
>>> 2x2x2 grid and do not refine, then it works, i.e. if I run on 8 
>>> cores, then each of them ends up getting one element.
>>>
>>> Thanks,
>>>
>>> Eike
>>>
>>> Oliver Sander wrote:
>>>> Am 12.11.2012 16:01, schrieb Eike Mueller:
>>>>> Hi Oliver,
>>>>>
>>>>> I tried several other strategies, but without any luck. Whatever I do,
>>>>> the algorithm seems to refuse to split up the macro cells, i.e. the 6
>>>>> elements I insert with the grid factory.
>>>>>
>>>>> I also tried to simplify the problem as much as possible. I now create
>>>>> one unit cube with the grid factory, do not insert any boundary
>>>>> segments and refine the grid by calling globalRefine(refcount), so
>>>>> that I end up with a cartesian unit cube split into 8^refcount
>>>>> elements. I then balance the grid with loadBalance() (i.e. no
>>>>> arguments). I would have thought that that should work. Still, if I
>>>>> refine 1,2 or 3 times (i.e. I should end up with 8,64,512 elements),
>>>>> for an 8 core run only one process stores the entire grid.
>>>> This should really work, can you post your test program?
>>>>
>>>> But be careful: If you load-balance small grids then all processors
>>>> get all elements, but most of them only as ghosts.  Did you
>>>> check that?
>>>>
>>>> cheers,
>>>> Oliver
>>>>
>>>>> Could this be a problem with the grid factory?
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Eike
>>>>>
>>>>> Oliver Sander wrote:
>>>>>> Am 06.11.2012 08:44, schrieb Markus Blatt:
>>>>>>> Hey Eike,
>>>>>>>
>>>>>>> On Mon, Nov 05, 2012 at 07:17:48PM +0000, Eike Mueller wrote:
>>>>>>>>> And loadbalancing would only be needed for the macrogrid, e.g.,
>>>>>>>>> not dynamic.
>>>>>>>>>
>>>>>>>> That's right, in the code I would refine the grid until there is
>>>>>>>> only cell per processor (this is the macrogrid). Then I would call
>>>>>>>> loadBalance, followed by further grid refinement. So for example
>>>>>>>> with 24 processors, I would subdivide each of the six cells in the
>>>>>>>> original grid into four cells, then loadbalance that grid and 
>>>>>>>> refine
>>>>>>>> further.
>>>>>>> Actually, this approach could be the root of the problem. The
>>>>>>> loadbalancing is a heuristic algorithm and normally one always gets
>>>>>>> some load imbalance here. But if you just have as many cells as
>>>>>>> processor, then naturally some will end up with no cells at all.
>>>>>> This is true, but it is not the whole truth.
>>>>>>
>>>>>> The default load balancing strategy of UG is Recursive Coordinate
>>>>>> Bisection.
>>>>>> This means roughly that the grid bounding box is partitionend into
>>>>>> axis-aligned
>>>>>> cells, and these cells are assigned to processors.  I reckon (I
>>>>>> didn't check)
>>>>>> that since your grid is a hollow sphere, some cells simply remain 
>>>>>> empty.
>>>>>>
>>>>>> UG offers several other strategies, but all this really is hardly
>>>>>> tested.
>>>>>> Have a look at the lbs method in ug/parallel/dddif/lb.c:533 for some
>>>>>> alternatives.
>>>>>>
>>>>>> good luck,
>>>>>> Oliver
>>>>>>
>>>>>>> How about doing some more refinement before load balancing?
>>>>>>>
>>>>>>> Cheers,
>>>>>>>
>>>>>>> Markus
>>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Dune mailing list
>>>>>> Dune at dune-project.org
>>>>>> http://lists.dune-project.org/mailman/listinfo/dune
>>>>>
>>>
>>> -- 
>>> Dr Eike Mueller
>>> Research Officer
>>>
>>> Department of Mathematical Sciences
>>> University of Bath
>>> Bath BA2 7AY, United Kingdom
>>>
>>> +44 1225 38 5633
>>> e.mueller at bath.ac.uk
>>> http://people.bath.ac.uk/em459/
>>>
>>> _______________________________________________
>>> Dune mailing list
>>> Dune at dune-project.org
>>> http://lists.dune-project.org/mailman/listinfo/dune
>>>
>>>
>>
> 
> 


-- 
Dr Eike Mueller
Research Officer

Department of Mathematical Sciences
University of Bath
Bath BA2 7AY, United Kingdom

+44 1225 38 5633
e.mueller at bath.ac.uk
http://people.bath.ac.uk/em459/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: elementdata.vtu
Type: text/xml
Size: 20225 bytes
Desc: not available
URL: <https://lists.dune-project.org/pipermail/dune/attachments/20121116/e5654274/attachment.xml>


More information about the Dune mailing list