Anush Krishnan <[email protected]> writes: >> C * C^T is the influence of particles on each other? Why can't you >> compute that analytically (without referencing the grid directly)? >> > > I haven't thought about that. The interpolation coefficients would depend > upon the relative positions of the body points with respect to the grid, > and the product matrix will depend on their positions with respect to each > other. I don't know if this can be done without referencing the grid.
Are you on a structured grid? It seems like you would use fmod to transplant the body point into a region of a reference patch, but I don't see why you need global indices of those grid points. > I also have a couple of related questions: > > [1] Suppose my body moves, and the positions of the body points change, > will I have to completely deallocate C^T and reallocate the new rows on > each process? It's possible that the number of non-zeros on each process > can change. What would you suggest as the best strategy to do this? Just create a new matrix. > [2] For a two dimensional staggered grid, I would need to interpolate both > the x- and y- velocity components. So my system [C][u]=[b] will be: > > /Cx 0 \ /u\ = /bx\ > \0 Cy/ \v/ \by/ > > Currently, I set up the right hand side as a single vector of size > 2*numBodyPoints using VecCreate, and use the global index of the rows when > I want to assemble the matrix C. Suppose I made it a DMComposite of bx and > by (which I can create as 1-D DAs), how can I reference the correct row of > the vector? I would have interlaced the bx and by (dof=2) so you can index it as one vector. Splitting components at collocated points is confusing and bad for performance. > Also, is it possible to create a composite vector of two vectors that are > not distributed arrays? You can do anything with VecScatter.
pgpwC87PdAGYQ.pgp
Description: PGP signature
