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

[Sebastian Wouters]

Hi Michael,

A little update:
I released v1.5 for psi4. chemps2 is going to be part of their alpha
release.

Now that Jessie is released, would you or one of your colleagues have some
time to help me with the packaging?

Best wishes,
Sebastian



2014-11-30 0:02 GMT-05:00 Sebastian Wouters <sebastianwouters at gmail.com>:

> 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
>>
>>
>


-- 
****************************************************

  dr. ir. Sebastian Wouters
  Fellow of the Belgian American Educational Foundation
  Princeton University
  (address) Department of Chemistry
            Frick Laboratory 351
            Princeton, NJ 08544, USA
  (e-mail)  sebastianwouters at gmail.com

****************************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/debichem-devel/attachments/20150504/58047331/attachment.html>