[mpich2-dev] Update resized.c code to match the comments.

[Rajeev Thakur]

Bob,
         This test was intentionally designed to catch bugs in the
implementation. lb, ub, etc are explained in Sec 4.1.6, pg 96, of MPI 2.1.
Setting an lb does not change what part of the buffer will be sent or
written. It affects the calculation of extent or ub, as the case may be. In
this case, the extent was specified as 12, so ub becomes 16. The first int
will be written at 0 (no matter where the lb is), the next int will be
written at 12 (lowest displacement + extent), and so on. There is something
else called true_lb (page 98), which represents the true lower bound of the
data accessed by the datatype, which in this case is 0.
 
I have fixed the comment. The test began life with lb set to 0. I thought it
would be more interesting to set it to something even beyond the end of the
type :-), hence it became 4, but the comment stayed  the same.
 
There is no end to what tricks you can play with datatypes. For example, you
can even set the ub to be lower than the lb :-). What happens is well
defined. 
 
Rajeev


  _____  

From: mpich2-dev-bounces at mcs.anl.gov [mailto:mpich2-dev-bounces at mcs.anl.gov]
On Behalf Of Bob Cernohous
Sent: Thursday, April 09, 2009 6:27 PM
To: mpich2-dev at mcs.anl.gov
Subject: Re: [mpich2-dev] Update resized.c code to match the comments.




> On Thu, Apr 09, 2009 at 04:10:06PM -0500, Bob Cernohous wrote:
> > Hi,
> > 
> > The io/resized.c test is failing in 1.1b1.   It looks like the code
> > doesn't match the comments.  It says use an lb at 0, but sets lb to
> > 4.  If I change the code, it runs fine.  Comments?
> 
> Hi Bob.  Yeah, sorry, the comment is wrong.  The code is correct in
> that it finds a tricky case with respect to tiling of types.  If you
> set the LB to 0 it's not a very tricky type at all :>

Ok, I'll look into this but let's start with the resize test.  I 
obviously don't understand it. 

It seemed to make sense to me that a lb 0, extent 12 would write the 
two int's at offsets 0 and 12.   What's the lb 3 really do?  Why would 
it still write to 0 and 12? 

> 
> It took us a bunch of iterations after introducing an optimization in
> adio/common to get this right.   We didn't have a test for resized
> types before we introduced the optimization, but if we did, it would
> have failed, too.  adio/ad_bgl is based on this older version of
> adio/common, so it's failing the resized test. 
> 
> How would you like to play this one, Bob?   I can tell you our svn
> revisions of interest and you can either port these into adio/ad_bgl
> or you can try to debug adio/ad_bgl as-is.  
> 
> Honestly, I don't know which will be more work. 
> 
> The svn revisions of interest went in over the summer of 2008:
> 
> r3219
> r3193
> r1001
> r983
> r988
> r984
> r968
> r960
> r958
> r956
> 
> Sorry I don't have a better answer for you.
> 
> ==rob
> 
> -- 
> Rob Latham
> Mathematics and Computer Science Division
> Argonne National Lab, IL USA


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.mcs.anl.gov/mailman/private/mpich2-dev/attachments/20090409/779164b8/attachment.htm>