Thanks, Jed. That was helpful. On 9 November 2013 21:15, Jed Brown <[email protected]> wrote:
> 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. >
