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

[Sebastian Wouters]

Hi Michael,

The git repository is online:
http://anonscm.debian.org/cgit/debichem/packages/libchemps2.git

I discovered this afternoon that CMake provides an easy way to create a
"make test" target (with CTest). I've added it upstream and to the debichem
libchemps git repo.

And it's also possible now to use an entry in DEB_BUILD_OPTIONS {nocheck,
partialcheck (actually anything that doesn't contain nocheck or fullcheck),
fullcheck} to switch between test sets:
http://anonscm.debian.org/cgit/debichem/packages/libchemps2.git/tree/debian/rules
The fullcheck takes 913 seconds on two cores, and the partialcheck 56
seconds.

Who do I best contact to inform about the python interface?

Thank you for your help so far!

Best regards,
Sebastian


2014-11-29 16:23 GMT-05:00 Sebastian Wouters <sebastianwouters at gmail.com>:

> Hi Michael,
>
> 2014-11-29 14:25 GMT-05:00 Michael Banck <mbanck at debian.org>:
>
>> Hi Sebastian,
>>
>> On Sat, Nov 29, 2014 at 12:12:49AM -0500, Sebastian Wouters wrote:
>> > In my last mail I forgot to CC the mailing list, so that's why part of
>> > the mail will seem familiar.
>> >
>> >  - My freshly created account on alioth is "sebwouters-guest".
>>
>> Ok, I've added you to the project now, welcome!
>>
>> >  - Do I just need to provide the modified libchemps2-1.4 source (with
>> > patches) and the debian/ folder (with patches) on the debichem git repo?
>>
>> I have to admit I haven't been using git for packaging yet, so I hope
>> somebody else can answer this.  I think most people are using
>> pristine-tar for the handling of upstream code in git.
>>
>
> I'll try to get the things for the C++ library uploaded today.
>
>
>>
>> >  - Thus far, I have only worked out the C++ shared library and
>> development
>> > files, but there's in fact also a python interface (PyCheMPS2) which
>> would
>> > be nice to have as a third library in the package.
>>
>> Which one is used by the external packages you mentioned in your first
>> mail?  In any case, exposing the python package does not make sense at
>> some point IMO.  If you don't have a lot of experience with python
>> packages, somebody else from the team can take a look at some point if
>> you want.
>>
>
> psi4 uses the C++ library directly, pyscf uses the python interface to the
> library, and I don't know about horton at this point, although I assume
> they also want to use the python interface.
> I think it would be good to have the python bindings as a third part of
> the libchemps2 package.
>
>
>>
>> >  - A second thing which I still need to figure out is how to run the
>> tests
>> > of the shared C++ / Python library. They're not intended for users to
>> > install as an executable, but it might be good to run these tests after
>> the
>> > buildd deamon has finished.
>>
>> In general (and I haven't looked at your package yet), there's two ways
>> to runs tests: (i) as part of the package building process and (ii)
>> after package installation using the autopkgtest framework[1].
>>
>> We have not done a lot with autopkgtest so far (but this is an important
>> topic we should tackle after the jessie release), but we try to run
>> testsuites during build whenever possible.
>>
>> I try to keep the following in mind when doing (i):
>>
>> 1. If debhelper's dh is used, dh_auto_test should run tests
>> automatically, but this is seldom the case for chemistry software. So we
>> usually add an override_dh_auto_test target, which runs the testsuite.
>>
>> 2. I honor DEB_BUILD_OPTIONS=nocheck - if that is set, tests are not
>> run, see e.g. the mpqc package.
>>
>> 3. In general, I make test suite failures non-fatal for the build, and
>> review the build logs for problems instead, also done in the mpqc
>> package.
>>
>> 4. depending on how long the testsuite takes (some take a very long
>> time, especially on lower-powered autobuilders), I only enable a couple
>> of tests which cover the functionality users are most likely to require.
>> This is either done via patch to upstream, or some Debian-specific
>> test-configuration from debian/.
>>
>> 5. If I do 4., then I try to add an option so that passing
>> DEB_BUILD_OPTIONS=fullcheck runs the full testsuite optionally.  See
>> the libint2 package (only in subversion so far) for that.
>>
>> Does that answer your question?
>>
>> That answers my question. I'll take a look at mpqc. Thanks!
>
>
>>
>> Michael
>>
>> [1]
>> http://anonscm.debian.org/gitweb/?p=autopkgtest/autopkgtest.git;a=blob_plain;f=doc/README.package-tests.rst;hb=HEAD
>>
>
> Sebastian
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/debichem-devel/attachments/20141130/131c5e82/attachment-0001.html>