Everybody is correct. Using the extremely sparse, nearly diagonal MPI matrix will have a bit more overhead than doing the rotations on the elements due to the needed MPI check and general use of a sparse-sparse-sparse matrix vector product. But if a code does not have support for the local transformations the extra cost of the the sparse matrix operation will be trivial relative to the rest of computations and so is fine to use.
Barry > On May 31, 2021, at 1:00 PM, Sanjay Govindjee <[email protected]> wrote: > > In our FEA code we perform the rotations at the local level, before assembly > so that it is easy to apply the boundary conditions, then unrotate locally > after solution to get the usual Cartesian components. Somehow this seems > more efficient than doing this globally, but perhaps I am missing something. > -sanjay > > On 5/31/21 9:33 AM, Matthew Knepley wrote: >> On Mon, May 31, 2021 at 11:12 AM Stefano Zampini <[email protected] >> <mailto:[email protected]>> wrote: >> Mike >> >> as long as P is a sparse matrix with compatible rows and cols (i.e. rows(P)= >> cols(A) = rows (A)) , MatPtAP will compute the result. >> >> Stefano and Mark are correct. This will work. >> >> I implemented the same thing in my code in a different way. I put this >> transformation into the mapping between local and global vector spaces. The >> global degrees of >> freedom are the ones you want for boundary conditions (normal and tangential >> to the boundary), and I eliminate the ones that are constrained. The local >> degrees of >> freedom are the normal Caresian ones, and these are used for assembly. The >> map is used when I execute DMGlobalToLocal() and DMLocalToGlobal(). There is >> an >> example of me doing this in SNES ex71, Poiseuille flow in a tilted channel. >> >> Thanks, >> >> Matt >> >> Il giorno lun 31 mag 2021 alle ore 16:52 Mark Adams <[email protected] >> <mailto:[email protected]>> ha scritto: >> >> >> On Mon, May 31, 2021 at 9:20 AM Michael Wick <[email protected] >> <mailto:[email protected]>> wrote: >> Hi PETSc team: >> >> I am considering implementing a skew roller boundary condition for my >> elasticity problem. The method is based on this journal paper: >> http://inside.mines.edu/~vgriffit/pubs/All_J_Pubs/18.pdf >> <http://inside.mines.edu/~vgriffit/pubs/All_J_Pubs/18.pdf> >> >> Or you may find the method in the attached Bathe's slides, pages 9 -10. >> >> Roughly speaking, a (very) sparse matrix T will be created which takes the >> shape [ I, O; O, R], where R is a 3x3 rotation matrix. And the original >> linear problem K U = F will be modified into (T^t K T) (T^t U) = T^t F. In >> doing so, one can enforce a roller boundary condition on a slanted surface. >> >> I think it can be an easy option if I can generate the T matrix and do two >> matrix multiplications to get T^t K T. I noticed that there is a MatPtAP >> function. Yet, after reading a previous discussion, it seems that this >> function is not designed for this purposes >> (https://lists.mcs.anl.gov/pipermail/petsc-users/2018-June/035477.html >> <https://lists.mcs.anl.gov/pipermail/petsc-users/2018-June/035477.html>). >> >> Yes, and no. It is motivated and optimized for a Galerkin coarse grid >> operator for AMG solvers, but it is a projection and it should be fine. If >> not, we will fix it. >> >> We try to test our methods of "empty" operators , but I don't know if >> MatPtAP has ever been tested for super sparse P. Give it a shot and see what >> happens. >> >> Mark >> >> >> I assume I can only call MatMatMult & MatTransposeMatMult to do this job, >> correct? Is there any existingly PETSc function to do T^t K T in one call? >> >> Thanks, >> >> Mike >> >> >> >> -- >> Stefano >> >> >> -- >> What most experimenters take for granted before they begin their experiments >> is infinitely more interesting than any results to which their experiments >> lead. >> -- Norbert Wiener >> >> https://www.cse.buffalo.edu/~knepley/ <http://www.cse.buffalo.edu/~knepley/> >
