Direct wrappers for the underlying C++ code

[ViralBShah]

This is completely speculative, but I have often wondered about the effort that may be necessary to directly wrap the underlying C++ code in PyAMG.

Of course, it may not buy us much except simplifying installation, and Julian APIs can be wrapped around the Python APIs anyways.

I have been planning for a while to port Circuitscape to Julia and PyAMG is an important component.

[cortner]

I can look into it. Why is installation via python a concern?

(For performance it shouldn't be - one could start passing all data by reference.)

[ViralBShah]

The only concern is far away - and it is around software distribution. Circuitscape is distributed as an executable, and having a python dependency means all of julia and python has to be bundled into the executable, for Windows, Mac and Linux.

I use PyAMG as a preconditioner for CG. Will passing objects by reference make a noticeable impact, given how much time is spent inside the solver?

[cortner]

The only concern is far away - and it is around software distribution. Circuitscape is distributed as an executable, and having a python dependency means all of julia and python has to be bundled into the executable, for Windows, Mac and Linux.

I see.

I use PyAMG as a preconditioner for CG. Will passing objects by reference make a noticeable impact, given how much time is spent inside the solver?

My best guesses, but I'd need to test this carefully:

• no
• maybe, if you use PyAMG as a preconditioner rather than solver, then there is a little overhead in Base.A_ldiv_B!(x, amg::AMGPreconditioner, b) = copy!(x,amg.po[:matvec](b))
• possibly in the construction: the sparse matrix is currently copied twice during AMG construction (to Python, then transpose); at least one of those copies could be avoided, both if the matrix is symmetric or if CSR is implemented in Julia.

[ViralBShah]

In my case, the matrix is indeed symmetric.

[cortner]

Ok I will test this and make suitable changes if it turns out to be useful

[cortner]

@lukeolson Sorry for pinging you, but I thought rather than me digging through the internals of pyamg, you'd be able to tell within seconds whether Viral's suggestion to directly wrap C++ code underlying pyamg from Julia would be relatively straightforward or a major undertaking?

[lukeolson]

This is a good idea -- I think the C++ should be easy to wrap since each kernel is fairly independent and since each is simply a function template. For example take a look at classical strength of connection:

https://github.com/pyamg/pyamg/blob/master/pyamg/amg_core/ruge_stuben.h#L46

Keep me posted -- I'm very interested in how this turns out.

[ViralBShah]

We are likely to overhaul circuitscape to be in Julia, and would love to leverage this if it were possible. Cc @bmcrae

[cortner]

We probably only need the AMG as preconditioner functionality and use IterativeSolvers.jl.

I'll start having a look at the codes, but not being an AMG expert myself (and time-constraints) I can't make any promises yet.

[cortner]

@ViralBShah I understand you are not in a hurry, but still if you know somebody who'd be interested in taking this on, I'd be happy to give push access to this repository, or even transfer ownership. (or alternatively an independent PyAMG2.jl can be created that could eventually replace this one)

[ViralBShah]

I will see if I find someone who is interested. This is already a great starting point, and having more contributors is always better.

[cortner]

since there is now AlgebraicMultigrid.jl I assume this is no longer relevant so I'll close this, but anybody should feel free to reopen if there is still interest.