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

Try using Krylov to solve the Poisson equation #3812

Draft
wants to merge 2 commits into
base: main
Choose a base branch
from
Draft

Conversation

glwagner
Copy link
Member

@glwagner glwagner commented Oct 2, 2024

This PR adds support for Krylov.jl and aims to test it out for solving the Poisson equation.

cc @xkykai @amontoison

Closes #3803

@glwagner glwagner marked this pull request as draft October 2, 2024 00:03
@glwagner
Copy link
Member Author

glwagner commented Oct 15, 2024

To do:

  • Implement mul! for the Laplacian operator
  • Implement a wrapper type for Field that subtypes AbstractVector?
  • Implement ldiv! for the FFT-based preconditioner (after the first two are done), planning to use ldiv=true with cg

This example illustrates implementing a custom operator:

https://jso.dev/Krylov.jl/dev/matrix_free/

Here is the documentation for implementing preconditioners in Krylov:

https://jso.dev/Krylov.jl/dev/preconditioners/

In Krylov, we want to remove broadcasting.

To make Field look like a vector we just need

struct QuasiVector{FT, F} <: AbstractVector{FT}
    field :: F
    function QuasiVector(field)
        FT = eltype(field)
        F = typeof(field)
        return new{FT, F}(field)
    end
end

@amontoison
Copy link

amontoison commented Oct 16, 2024

@glwagner I remember now why the right-hand side b is an AbstractVector{FC}: I use the type FC for type stability with the keyword arguments (tolerances, etc.) as well as default values (sqrt(eps(real(FC)))).

@glwagner
Copy link
Member Author

@glwagner I remember now why the right-hand side b is an AbstractVector{FC}: I use the type FC for type stability with the keyword arguments (tolerances, etc.) as well as default values (sqrt(eps(real(FC)))).

True but then you could use AbstractArray{FT} similarly right?

@amontoison
Copy link

amontoison commented Oct 16, 2024

Yes, I can use AbstractArray{FT}, but it should represent a vector (whatever format he has).
For common array types, it always leads to an AbstractVector, so I never found the need to remove it.
I was always hesitant to relax this constraint because the type of b is used for allocating the "vectors" in the workspace of a Krylov method.
If a user makes a mistake and provides a matrix with one column instead of a vector, it will fail internally with an unfriendly error message.

@glwagner
Copy link
Member Author

If a user makes a mistake and provides a matrix with one column instead of a vector, it will fail internally with an unfriendly error message.

Ah for sure. I was just remarking that if you need the eltype, you can use AbstractArray{FT} (or you can simply call eltype, which is preferred by YASGuide --- type parameters should be used for dispatch only).

I think it's ok if you keep AbstractVector. We can create a wrapper for Krylov.

@amontoison
Copy link

amontoison commented Nov 5, 2024

@glwagner @xkykai
I added a example in the documentation for you:
https://jso.dev/Krylov.jl/previews/PR927/custom_workspaces

@glwagner
Copy link
Member Author

glwagner commented Nov 6, 2024

@glwagner @xkykai I added a example in the documentation for you: https://jso.dev/Krylov.jl/previews/PR927/custom_workspaces

Just a comment --- the Poisson operator is usually denoted $\nabla^2$ (rather than just $\nabla$ which denotes a gradient and yields a vector):

image

otherwise this is great!

@amontoison
Copy link

Thanks!
Good catch for typo with \nabla, I will fix it.

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

Successfully merging this pull request may close these issues.

Implement KrylovPoissonSolver
2 participants