Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

LA::d::Vector<double> for component wise reordered FESystem #14069

Open
ghost opened this issue Jun 28, 2022 · 2 comments
Open

LA::d::Vector<double> for component wise reordered FESystem #14069

ghost opened this issue Jun 28, 2022 · 2 comments

Comments

@ghost
Copy link

ghost commented Jun 28, 2022

In a current application program I work with TrilinosWrappers::MPI::Vector. However in a subroutine I do a L2 projection of the gradient of the TrilinosWrappers::MPI::Vector. Therefore I looked into VectorTools::project and set up the mass matrix as MatrixFreeOperator. However, I need to transfer the TrilinosWrappers::MPI::Vector to a LinearAlgebra::distributed::Vector<double>. The problem is, that I consider a vector-valued problem and reorder the DOFs component wise. The assertion which is thrown requires locally_owned_indices.is_contiguous() == true. Is there a chance to transfer a TrilinosWrappers::MPI::Vector into a LinearAlgebra::distributed::Vector<double> overcomming this issue? If I turn of the component wise reordering it works, but this is not the way I can proceed, as I want to later develop a block-preconditioner for the problem.

Any suggestions how to proceed?

@kronbichler
Copy link
Member

The assumption of a contiguous index range for the locally owned dofs is to render certain operations more efficient.

Whichever way we put it, I think there will be some need for adaptations in the deal.II source code to support your case. Since you mention the desire to work on a block preconditioner later, would it be an option to fill a LinearAlgebra::distributed::BlockVector instead? In that case, we would need to make sure to be able to interface with a Trilinos vector from the block vector, and probably to detect the case in the VectorTools::project function. I think most interfaces are already prepared for that, so there are probably only small adaptations necessary. Do you want to give it a try?

@ghost
Copy link
Author

ghost commented Jun 29, 2022

Many thanks for your suggestion! Yesterday evening I was thinking a lot on this problem and using a LinearAlgebra::distributed::BlockVector<double> was also my final thought. I will work on this as I need it for my own project_gradient function. I have also #12699 open. Should I do the major revision of VectorTools::project there or open different minor PRs for this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants