[Users] PUGH Questions

[Erik Schnetter]

On May 10, 2008, at 11:38:21, Andreas Schäfer wrote:

> On 15:48 Fri 09 May     , Erik Schnetter wrote:
>>
>> Carpet n-sects, where n is chosen depending on the
>> number of processors.  Each dimension is n-sected only once.  While
>> bisection leads to a binary tree, n-section leads to a wider and more
>> shallow tree.
>
> How exactly do you choose n? Does n have to be a divisor of the number
> of processors? If you n-sec each dimension only once, couldn't this
> also lead to a degenerated surface to volume ratio?

We choose n such that the ratio of n to the total number of processors  
is approximately the same as the ratio of the side length to the total  
number of grid points.  Each sub-block is then n-sected  
independently.  The surface-to-volume ratio should stay small, except  
if there are only very few processors or if the domain has a  
degenerated shape.

For example, the following domain shape could be generated on five  
processors:

	AAABBB
	AAABBB
	CCDDEE
	CCDDEE
	CCDDEE

where the letter describes which processor owns a grid point.  This  
could arise by first 2-secting in the vertical direction, and then 2- 
secting and 3-secting the upper and lower parts, respectively.

> I'm not sure how "each dimension is n-sected only once" affects this,
> but using bisections we've observed a nasty effect during load
> balancing that we call "flip over":

> Could the example above happen when balancing the load with Carpet? If
> not, how does the n-section work exactly?

We are cheating: during load balancing, we re-distribute the grid  
completely.  This works for us since we need to redistribute only  
every N time steps, and (after some optimisations) the time spent  
redistributing the whole grid does not seem to be too expensive for  
us.  Having said this, we are just now defining a benchmark to  
actually measure this under "realistic" conditions instead of just  
examining timing information in production runs.

-erik

-- 
Erik Schnetter <schnetter at cct.lsu.edu>   http://www.cct.lsu.edu/~eschnett/

My email is as private as my paper mail.  I therefore support encrypting
and signing email messages.  Get my PGP key from www.keyserver.net.



-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 194 bytes
Desc: This is a digitally signed message part
Url : http://www.cactuscode.org/pipermail/users/attachments/20080517/e80cd80f/attachment.bin