Re: [deal.II] Re: maybe a novice question about parallel vectors in deal.ii
Dear Timo: After reading your comment: "SparseMatrix::vmult(dst, src) does not require ghost entries in the vector src (but it won't hurt either)" I started to check this in my own codes (that uses a lot of vmults) and realized that I always use ''src'' that is locally relevant. I did that since from the point of view of each MPI process ''SparseMatrix'' is just a ''flat'' (rather than tall) rectangular matrix: meaning that, to perform a matrix vector product the information that I need from ''src'' is the locally relevant one, not just the locally owned one. Does it pay-off to use ''src'' that is locally relevant rather than locally owned? Is this more efficient? For me is clear that if ''src'' is merely locally owned it just doesn't have enough information to compute ''its part'', and at some point vmult will have to ship (from another MPI process) the missing ''relevant'' information in the src vector, is this correct? So it seems as if, from the very beginning, it is better to feed vmult with with locally relevant ''src''? Just trying to optimize my code … Many thanks Ignacio. On Wednesday, February 26, 2014 at 4:53:33 PM UTC-6, Timo Heister wrote: > > > Thanks for the help! I understand better what it is I cannot do. But I > still > > need a piece of advice on how to compute and store in a parallel > simulation > > the quantity: M(u-uold) > > No, SparseMatrix::vmult(dst, src) does not require ghost entries in > the vector src (but it won't hurt either). Because we are writing into > dst, dst must not have ghosts. > > > I still think this is convoluted. Any (better) ideas? > > Ghosted vectors are only needed if you read from individual vector > entries and in a couple of places in the library: > - DataOut > - error computation > - FEValues::get_function_values > > And probably a few other things I forgot. > > -- > Timo Heister > http://www.math.clemson.edu/~heister/ > -- The deal.II project is located at http://www.dealii.org/ For mailing list/forum options, see https://groups.google.com/d/forum/dealii?hl=en --- You received this message because you are subscribed to the Google Groups "deal.II User Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to dealii+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [deal.II] Re: maybe a novice question about parallel vectors in deal.ii
Dear Timo: After reading your comment: "SparseMatrix::vmult(dst, src) does not require ghost entries in the vector src (but it won't hurt either)" I started to check this in my own codes (that uses a lot of vmults) and realized that I always use ''src'' that is locally relevant. I did that since from the point of view of each MPI process ''SparseMatrix'' is just a ''flat'' (rather than tall) rectangular matrix: meaning that, to perform a matrix vector product the information that I need from ''src'' is the locally relevant one, not just the locally owned one. Does it pay-off to use ''src'' that is locally relevant rather than locally owned? Is this more efficient? For me is clear that if ''src'' is merely locally owned it just doesn't have enough information to compute ''its part'', and at some point vmult will have to ship the missing ''relevant'' information in the src vector, is this correct? So it seems as if, from the very beginning, it is better to feed vmult with with locally relevant ''src''? Just trying to optimize my code … Many thanks Ignacio. On Wednesday, February 26, 2014 at 4:53:33 PM UTC-6, Timo Heister wrote: > > > Thanks for the help! I understand better what it is I cannot do. But I > still > > need a piece of advice on how to compute and store in a parallel > simulation > > the quantity: M(u-uold) > > No, SparseMatrix::vmult(dst, src) does not require ghost entries in > the vector src (but it won't hurt either). Because we are writing into > dst, dst must not have ghosts. > > > I still think this is convoluted. Any (better) ideas? > > Ghosted vectors are only needed if you read from individual vector > entries and in a couple of places in the library: > - DataOut > - error computation > - FEValues::get_function_values > > And probably a few other things I forgot. > > -- > Timo Heister > http://www.math.clemson.edu/~heister/ > -- The deal.II project is located at http://www.dealii.org/ For mailing list/forum options, see https://groups.google.com/d/forum/dealii?hl=en --- You received this message because you are subscribed to the Google Groups "deal.II User Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to dealii+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [deal.II] Re: CMake extra libraries?
On Friday, June 16, 2017 at 5:43:27 PM UTC+2, Wolfgang Bangerth wrote: > > On 06/15/2017 03:32 PM, Bruno Turcksin wrote: > > The problem is that > > Trilinos botched their TrilinosConfig.cmake. What we do is load the > > TrilinosConfig.cmake to get their flags but if they don't put them in, > > there is little we can do. > What is done in both Spack (https://github.com/LLNL/spack/blob/develop/var/spack/repos/builtin/packages/trilinos/package.py#L578-L590) and Homebrew (https://github.com/Homebrew/homebrew-science/blob/master/trilinos.rb#L286-L289) is to manually remove PyTrilinos from COMPONENTS_LIST in /lib/cmake/Trilinos/TrilinosConfig.cmake This issue is known to Trilinos for some time already https://github.com/trilinos/Trilinos/issues/866 , to my knowledge the first mentioning is May 2015 https://github.com/Homebrew/homebrew-science/issues/2148#issuecomment-103614509 . Regards, Denis. -- The deal.II project is located at http://www.dealii.org/ For mailing list/forum options, see https://groups.google.com/d/forum/dealii?hl=en --- You received this message because you are subscribed to the Google Groups "deal.II User Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to dealii+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
