[Debichem-devel] RFS: libchemps2/1.4-1 -- spin-adapted DMRG for ab initio quantum chemistry

Sebastian Wouters sebastianwouters at gmail.com
Sun Jun 14 19:34:37 UTC 2015

Hi Michael,

Thank you for your feedback!

Regarding your questions:

1. I created a new repository and will delete the old one:


This new repository has a tagged version upstream/1.5 without the debian
folder, as requested. I've also changed the general package name from
libchemps2 to chemps2 in the new repo.

2. In the new rules file, the option "-D html_theme=default" is passed to
sphinx-build, which uses the default theme instead of the classic theme:


3. libpython-dev was added to the control file:


4. I have currently used a work-around to make debuild work for sid:


According to HDF5's specifications, one should include <hdf5.h>, see
section 5 on


In sid's packaged hdf5 version, this file is installed in


I think it is therefore CMake's task to correctly set the variable
with FindHDF5.cmake. They will probably do so at one point in a new
version. So maybe this needs to be patched to sid's cmake version, because
else many programs will have this problem?

5. Already resolved:


6. The idea of the chemps2 library is that it should be a lightweight and
efficient library providing core functionality. Additional features,
outside of this core functionality, make use of the classes and
functionality in the core library without touching them. After some debate
with Sandeep Sharma (who rewrote the Block code for Garnet Chan) and Garnet
himself, we agreed that this is most likely the optimal balance between
speed and stability on the one hand, and ease-of-use and recycling code for
future development on the other hand.

>From the tests, it seems that with ~ 30 functions, all API is provided. But
for psi4 for example, all classes in DMRGSCF*.h are required as well, see
https://github.com/psi4/psi4public/blob/master/src/bin/dmrg/dmrgscf.cc. And
for generic purpose classes such as Davidson or DIIS, it might be useful
for other programs to use them for a different purpose. The classes which
initially seem least useful, the Tensor*.h will then again be used to
construct intermediary contracted objects for dynamic correlation theories
such as DMRG-NEVPT2.

That being said, I'm well aware that any API change will break user space
and will require a version number increase. The API in the version in this
new repo is adjusted to MPI (although I don't officially support it yet --
still need to do scaling tests and write a paper). The only major feature
which will be added before the end of 2016 in the core package is the
calculation of the 3-RDM. This will only require additional functionality
and I will take care that it doesn't break the current API. All further
developments of CheMPS2 will be split into a separate library making use of
the core library, as said above.

Due to the combination of all class functions in one header file (per
class), currently the header files mutually call each other in a cascaded
way. So either all or none are included (in practice). If you would like to
have a minimal closed set of functions, I can make one specific header file
with all relevant functions. As an alternative I could write C-wrappers
around the CheMPS2 class, an option which I contemplated about for the
python interface, but which I abandoned in favour of Cythonizing the

Let me know what you think, and if you want, I can make specific
installation headers for debian.

7. I've adjusted all your comments regarding the library description.

Best wishes,

2015-06-13 13:24 GMT-04:00 Michael Banck <mbanck at debian.org>:

> Hi Sebastian,
> On Thu, May 14, 2015 at 04:39:55PM -0400, Sebastian Wouters wrote:
> > Hi Michael,
> >
> > I have now also added the python package: python-chemps2:
> > http://anonscm.debian.org/cgit/debichem/packages/libchemps2.git/
> >
> > Is there anything else I can do?
> I had a further look, sorry for the delay.  My comments:
> 1. Is there a good reason the source package is called "libchemps2"
> while the github project and release tarballs are called just "chemps2"
> (modulo capitalization)?  I agree it would be awkward to switch the git
> repo basename and all, but maybe better now than after the package is in
> the archive?  In general, the source package name should be called
> similar to the tarballs.
> 2. A build on Debian unstable fails when running sphinx, cause it cannot
> find a 'classic' theme:
> |PYTHONPATH=. http_proxy='' sphinx-build -N -b html -c
> obj-x86_64-linux-gnu/sphinx/ sphinx/ build/html
> |Making output directory...
> |Running Sphinx v1.2.3
> |loading pickled environment... not yet created
> |
> |Theme error:
> |no theme named 'classic' found (missing theme.conf?)
> |make[1]: *** [override_dh_auto_build] Error 1
> That's a bit weird, but indeed I don't have a
> /usr/share/sphinx/themes/classic/theme.conf
> Maybe it needs to be changed to "default"?  That one is available and
> changing it to that makes the documentation build fine for me.
> 3. The following Build-Depends is missing:
>  - libpython-dev
> 4. The include for HDF5 in CheMPS2/include/chemps2/MyHDF5.h is not
> working for me, there's no /usr/include/hdf5.h (anymore?). If I replace
> that with '#include <hdf5/serial/hdf5.h>', it builds fine.
> 5. I was a bit surprised that there is only libchemps2.so.1 and not
> libchemps2.so.1.x.y as is usual for libtool projects, but I guess that
> is from CMake?
> 6. As a general (targetted at upstream) comment, it seems to me that
> there are really a lot of files shipped in /usr/include/chemps2.  Be
> aware that removing any function signature from any of those will
> require you to bump the library version.  Is that really the external
> API in there or are some/most meant to be internal and should not be
> shipped?
> 7. About the description in debian/control, I would advise the following
> changes.  But those are not required before upload:
>  - I would remove the first sentence of the 'design philosophy'
>    paragraph, as implementation details or designs are usually
>    discouraged in the description.  Maybe to make it more readable, you
>    could break it down into a list of bullet-points as well, introduced
>    with something like "Further Features include: [...]".
>  - remove the "In the future" paragraph - the description should be
>    about the current state of affairs (though I agree we are sometimes
>    bad at updating it when new upstream version implement new features).
>  - personally I would drop the last paragraph as well.  The homepage is
>    already mentioned in the Homepage: field and in upstream-metadata,
>    and the additional references are also mentioned in upstream-metadata
>    (though I am not sure that information is exposed elsewhere yet).
>    Finally, the documentation is shipped in the libchemps2-doc package,
>    or is the documentation on your website different to it?  That said,
>    if you prefer to leave that paragraph in, I'm fine with it.
>  - maybe expand 2-RDM as (I guess?) "second order reduced density
>    matrix (2-RDM)" on first mention, though then again if users don't
>    know what 2-RDM means they might not get a lot out of the package
>    anyway.  You are expanding most of the other acronyms (like FCI,
>    CASCI, CASSCF) already, though.
>  - Possibly add something like "CheMPS2 is parallelized via OpenMP." at
>    the end, or am I mistaken about OpenMP?
> Cheers,
> Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/debichem-devel/attachments/20150614/1f68103a/attachment.html>

More information about the Debichem-devel mailing list