Anush Krishnan <[email protected]> writes: > Thank you very much! That worked.
Great! > I also have a couple of general questions regarding this: > > 1. In this case, I followed your advice and created a single matrix G of > type MPIAIJ and assembled it. How do I decide if I should rather use Block > Matrices (MPIBAIJ) or MatGetLocalSubMatrix to set it up? BAIJ only does square blocks and you don't have block structurex to begin with (because you don't interlace the x- and y-components of the fields). MatGetLocalSubMatrix is a convenience when it makes sense to assembled blocks on their own. That probably doesn't apply here because you don't have a reason to assemble, say, the gradient of pressure in the y-direction only. > 2. Various functions exist to help us access the correct indices when > required (e.g. DMDAGetAO, DMCompositeGetGlobalISs, DMDAGetCorners, > VecGetOwnershipRange, etc.) And sometimes, there are multiple ways by which > we can obtain the same indices. In such cases, are some of these functions > preferable to others (either because they are faster or need to allocate > less memory)? Many uses of AO are fairly heavy-weight because any global-to-local operation either needs non-scalable memory or a lookup structure that is slower than an array. DMDAGetCorners() is extremely cheap and doesn't use much memory, so if that is all you need, use that. DMCompositeGetGlobalISs() is cheap on its own, but accessing the resulting ISs often boils down to an array of indices, which would mildly increase your memory bandwidth demands if you do it in a performance-sensitive traversal. Usually these things are only needed during setup, at which point they are cheap as long as they are scalable.
pgpXppmLsaO9w.pgp
Description: PGP signature
