gf library

[shinaoka]

Hello,
Do you have any plans to implement a Python interface of the gf library?
I am asking this because we're planning to implement a Python DMFT framework based on ALPSCore.

[galexv]

It is surely possible to implement. We plan to introduce features to the python interface on a per-request basis at this time, so that the interface matches user requirement.

What kind of interface would you like to see --- what would you like to do with a GF via Python?

[shinaoka]

I am thinking about (i) implementing a self-consistent DMFT loop and (ii) IO to a HDF5 file.
For the latter, we need to invert a GF as a matrix at each Matsubara frequency,
add two GF's, and broadcast a GF over nodes, etc.

At this time, we are using numpy tensors, scipy for matrix operators, and h5py for IO.
I am now wondering if it makes sense to switch to ALPSCore/gf.

[egull]

Hiroshi, I will assign this to you, in addition to Alex. When you're visiting we should discuss this more and make a concrete plan.

[shinaoka]

For sure. I want to implement a Python interface of the ALPSCore/CT-HYB solver.

[shinaoka]

Let us discuss bit about how to proceed.
There seems to be several options.
Since I am still new to writing python-C++ interfaces, I need your suggestions!

1. Using the wapping scheme of TRIQS.
   Pros: based on libclang (which is a very accurate implementation of the latest C++ standard). This c++2py also enables semi-automated generation of wapping codes. The tool may be modified for ALPSCore.
   Cos: The tool is not documented.

2. Using third-party tool like SWIG.
   Pros: well documented.
   Cons: For SWIG, we need to write an interface file by hand.

[galexv]

For completeness (and depending on what exactly we want to achieve):

3. In-Python ctypes
   Pros: Part of a standard Python library, no additional dependencies. Loads a shared library and calls functions directly.
   Cons: Can only call unmangled (extern "C" ) function names, and passes around only primitive C types, pointers, structures and arrays. Essentially, we would need to expose a pure-C ALPSCore interface.
4. CFFI.
   Pros: Claims to be simpler to use than SWIG (no separate interface-description language) and cleaner than ctypes.
   Cons: As ctypes, essentially interfaces with C, not C++.
5. Boost's boost::python
   Pros: We already have dependency on Boost. Parts of existing ALPSCore-Python code uses boost::python.
   Cons: Rumored to be not actively supported lately. Class interface descriptions are still C++ and parsed by a C++ compiler: it's arguably better to parse them using Python+Clang, as TRIQS does. As boost::python is not a "header-only" library, there is a possibility of version mismatch between the "current" version of Python and the version Boost was compiled with.
6. Babel
   Pros: Claims to be universal solution, interfacing any of the supporting languages (e.g. C++) to any other supporting language (e.g. Python), allowing call chains like "Python application --- C++ implementation --- Python callback". I worked with Babel some time ago.
   Cons: An overkill to our purposes. Needs its runtime shipped with the application. Like in the case of SWIG, interfaces must be described in a special language (SIDL). Support status is unclear.

[shinaoka]

Thank you for the clarification!
I need C++ interface rather than C interface.
Did you already study how the TRIQS c++2py tool works?
I once used that tool to built a Python interface for our CT-HYB code.

[galexv]

One more Python-C++ interfacing tool:

7. Djinni, the Python branch.
   Pros (arguable): Similar to Babel, requires writing an interface definition from which it generates both Python and C++ glue code. The people behind this tool are DropBox developers.
   Cons: Still experimental, future support is unclear.

[shinaoka]

I have been using SWIG for writing my own private bindings of gf library for the last few months.

How should we proceed?
First, we may need to choose either boost::python or SWIG.
Using two different bindings schemes will lead to unpleasant results...
Let us settle this issue before Markus's visit to my place.

[galexv]

I vote for SWIG.

[shinaoka]

I vote for SWIG because boost::python is not header-file-only libraries.
Alex, could you assign Markus to this issue?