[ase-users] [ase-developers] ASE meeting at psi-K

[Ondrej Certik]

On Fri, Sep 17, 2010 at 1:53 PM,  <Janne.Blomqvist at tkk.fi> wrote:
> Quoting Felix Hanke <F.Hanke at liverpool.ac.uk>:
>
>>   Hi all,
>> this is the follow-up message for those of you who are coming to psi-K
>> next week and who would like to join an informal ASE-meeting.
>
> A short report about the meeting. I'll try to be objective and not
> inject too much of my own biases, but if anyone feels I'm
> misrepresenting opinions or if I forgot some topic, feel free to
> correct.
>
> Present (ordered counter-clockwise around the table, for the morbidly
> curious): Jens-Jørgen Mortensen, Christian Glinsvad, Hugo Strand,
> yours truly, Karri Saloriutta, Ondrej Marsalek, Jussi Enkovaara, Jonas
> Björk, Felix Hanke.
>
> Topics discussed, in no particular order:
>
> - It would be nice if DFT calculators would be consistent with each
> other as far as reasonable, and also to, if possible, reuse
> implementation work among calculators. E.g. common parameters such as
> xc='LDA' for setting the XC functional, kpts=(N1, N2, N3) for
> k-points. Also the calculator.set(keyword=value) style method as found
> in GPAW was considered useful.
>
> - How calculators should behave wrt restarts/relaxations/independent
> jobs/ should be specified and documented, and again, calculators
> should ideally be consistent with each other.
>
> - More tests, especially for calculators, would be desirable. Common
> tests that are run for all calculators, if possible, would be nice.
> Mock calculators that "emulate" a real calculator might be useful so
> that people who don't have a particular calculator installed could
> still run tests for that calculator.
>
> - scipy was considered useful, however since installing scipy can be
> difficult especially for exotic architectures like Blue Gene or Cray,
> scipy should not be a hard requirement for the core functionality.
> It's fine as long as it's optional and/or used by e.g. analysis
> functionality that is typically run on PC's.
>
> - There has been some informal discussion at DTU about moving from
> subversion to a more modern distributed version control system (DVCS).
> This news was well received. A brief discussion about the merits of
> various DVCS'es did, unsurprisingly, not result in agreement about
> which is the One True DVCS. It was asked whether DTU should continue
> to host the project infrastructure, or if one should make use of a
> free service like github/bitbucket/launchpad that provides repo
> hosting, issue tracker, source and changeset browsing, ssh key
> management etc. The consensus answer was that this is up to the DTU
> project admins; as long as it works nobody else cares. sphinx is very
> nice though so the project website and documentation will continue to
> be hosted at DTU.

Btw, you can continue using svn, but host it at github:

http://github.com/blog/644-subversion-write-support

that way people can use git, but you can continue using svn (assuming
you prefer svn over git) and push using svn.

>
> - In conjunction with the move to a DVCS, there was discussion about
> the project workflow. Should the current system with a largish group
> of committers be maintained, or should move to a system with fewer
> committers that review patches/pull requests?

We recently switched to use github pull requests with sympy:

http://help.github.com/pull-requests/

you can see our current (review in progress) pull requests here:

http://github.com/sympy/sympy/pulls

We have about 10 people with push access and every patch needs to be
reviewed (preferably using the pull request) and then anyone of the 10
people has to push it in.

I think that this model could work for you as well, you simply give a
push access to all your current svn people with push access, and start
reviewing all code going in.

Ondrej