[gmx-developers] Developer videoconference notes

[Erik Lindahl]

Hi,

Here are some brief notes I took at the meeting. We agreed at the meeting that we would prefer not too repeat all discussions twice (first at the meeting, and then on the list), so I would suggest to save most follow-up questions for next meeting.


Gromacs developer meeting 2016-08-03

Meta development/meeting stuff:
	- As part of BioExcel we are organizing a Gromacs Hackaton in Barcelona october 16-18. No lectures/tutorials or anything, just people sitting and working/helping with code and reviews.
	- We might have an opportunity to arrange an event at University of Virginia (since we have a little bit of travel funding on a joint grant left) if we can do it by late November this year. Follow up with Peter Kasson.
	- Christian Blau will try to arrange another developer event in Göttingen in May 2017. We’re happy to use other places too, but it saves a lot of time & money to use locations where we have good local collaborators and travel funding.

We might try a weekly post on gmx-developers (gmx-weekly?)
	- 1-line summary of things happening
	- New bugs/Redmine issues
	- Things that need some love

	However, this is yet another item that will take time from Mark, so we’ll only keep doing it if has a positive result on involvement and people helping with stuff.
	We should make a habit of participating in Redmine/Gerrit without somebody having to tell us each time.

Release plans for 2017:
	- 2017 release frozen ~April 1, release in ~June.
	- Compress the beta cycle by closing master for ~ 1 month => focus all love on release branch, release, then get back to development (instead of being in development mode for ~4 months)?
	- We all need to spend more time doing bugfixes and addressing Redmine issues during the year rather than waiting until last-minute before the release. 

	Response: Not popular, but the issue is that we all want the release to happen (but prefer somebody else to do the boring work). The question is then how we will distribute the work required over the entire team (and volunteer) to be able to keep sustaining multiple branches?
	There were suggestions that we can do better by spreading the bugfixing over the entire development cycle, rather than beta. However, remember that this cycle starts *now* given that Mark just release 2016, so now is the time to prove that we get this voluntary engagement - not April next year :-)

Regressiontests:
	- Lot of extra work in syncing regressiontest reference values with the repo for 3 different branches (stable, release, and master).
	- Gradually move away from a separate repo (with the large binary objects) and start using small tests based in the normal repo (using google test framework).

Documentation:
	- RST or wiki/wordpress?
	   We’re starting to have lots of more docs in RST (Restructured text) in the repo, while our webpages are still old/bad. We should avoid having things in two places.
	   Maybe a good split is to have anything related to versioning (e.g. changed user options) in RST in the repo, and general tutorials/stuff on normal webpages?
	   (note that we’ll still generate webpages from the RST documentation, but that won’t be fully integrated in a wordpress-style website)

Code things happening:
	- Implement complete verlet kernel generator, and then get rid of all group kernels (Erik/Mark).
	- Look into our own FFT routines (Erik, Roland, maybe others) for better performance with SIMD, get rid of FFTW dependency
	- Start using JSON for settings & data input files 
	- Lots of GPU work happening with PME and kernels (Szilard, Aleksei). From next year we’ll only do the integration on the CPU, which will boost performance a lot.
	- Task scheduling. We’re looking into both STS (John Eblen) and Argobots.
	- Roland looking more into vectorization. Updates; it can get messy to use SIMD for all the possible branches we have right now. Can we come up with a smart idea to do it?
	- Bump compiler requirements to gcc-4.8.1 for next release seems to make sense.
	- We need to give some serious love to the user-facing parts (cleaning up tools, etc) before the 2017 release.
	

Cheers,

Erik



	





-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://maillist.sys.kth.se/pipermail/gromacs.org_gmx-developers/attachments/20160804/ee669dda/attachment.html>