search

JuliaParallel / PETSc.jl

Julia wrappers for the PETSc library
Other
121 stars 38 forks source link

Update PETSc_jll with more solvers #146

Closed jkozdon closed 3 weeks ago

jkozdon commented 3 years ago

https://github.com/JuliaPackaging/Yggdrasil/pull/3249 does not add the following libraries, so this should be revisited at some point

see: https://github.com/JuliaPackaging/Yggdrasil/pull/3249#issuecomment-880067871

amartinhuertas commented 2 years ago

Hi @jkozdon ! Is there any chance that this issue gets sorted out soon? We are interested into having support for these libraries in PETSC_jll.

jkozdon commented 2 years ago

Hi @amartinhuertas!

I haven't looked at this any further, I'd be happy for someone to take this on!

In theory you can build a custom PETSc instance with this enabled.

In all honesty PETSc.jl development has stalled as my fall teaching started... hoping to get back to it in the new year since I should have a bit more time. (And at least get #149 merged)

A bigger problem that needs to be sorted out is those raised in https://github.com/JuliaPackaging/Yggdrasil/pull/3801 where our current mechanism for supporting multiple PETSc libraries will fail.

amartinhuertas commented 2 years ago

Thanks for your detailed response @jkozdon !

On another note, note that we are also developing our own wrappers for PETSc.jl, in particular, here https://github.com/gridap/GridapPETSc.jl. In these, we have some macros to generate C wrappers (it does not actually rely on Cbinding.jl package, anyway), and also a way to treat the deallocation of PETSc objects in a parallel context which is GC friendly.

jkozdon commented 2 years ago

@amartinhuertas I will have to take a look at what you all have done.

I wonder if the efforts could / should be combine?

It seems to me having two different PETSc wrappers floating around is not such a good thing.

You all also have more active development team which this package would certainly benefit from. If you'd like to chat about this possibility sometime, I'd be game.

amartinhuertas commented 2 years ago

Please note that GridapPETSc.jl is not intended solely to be Julia wrappers for PETSc (although it has its own wrappers to PETSc, just as PETSc.jl, and thus there is some overlap here). It implements some of the abstract interfaces of our finite element packages Gridap.jl/GridapDistributed.jl , so that we can leverage them with PETSc as a solver library.

Perhaps @fverdugo and @stevengj may also want to contribute to this discussion.

jkozdon commented 2 years ago

Please note that GridapPETSc.jl is not intended solely to be Julia wrappers for PETSc

That's fair and I understand.

Sounds like the two efforts should remain separate.

I took a look at the GridapPETSc.jl parallel garbage collection. I'd thought of doing something similar for PETSc.jl and was thinking that it could still result in deadlock situations, but rethinking about it, I do now think that it's OK and not a bad way to go.

I was trying to think of a situation where you would end up accumulating a PETSc objects that need to be cleaned up in performance critical pieces of code, but I don't think that you should be destroying objects in performance critical codes that require collective clean up.

I'll have to consider putting this into PETSc.jl when I get some time to work on it again. Thanks for the suggestion.

ViralBShah commented 3 weeks ago

@boriskaus I believe these solvers are now added to PETSc_jll. Should we close this issue or update its title?

boriskaus commented 3 weeks ago

yes these are now included in PETSc_jll. The problem of interacting with the GC remains, but there is a separate issue for that