[QE-developers] Notes for developers' meeting (was Re: Developers' meeting?)

[Stefano Baroni]

Much appreciated. Thanks. S.

___
Stefano Baroni, Trieste -- http://stefano.baroni.me

> On 5 Jan 2019, at 14:25, Nicola Marzari <nicola.marzari at epfl.ch> wrote:
> 
>> On 21/12/2018 18:12, Paolo Giannozzi wrote:
>> Makes sense to me as well. I have updated the tentative agenda accordingly (same link as before: http://www.quantum-espresso.org/news-events/news/qe-developers-meeting-2019).
> 
> 
> 
> Dear All,
> 
> 
> I've collected a few of the desiderata from here and from other groups,
> about some of the more pressing needs for QE (maybe something to keep in mind also for MaX, given that the funding is meant to support a user
> community?).
> 
> As you can see from the list below, they have a lot to do with using
> the code(s) in reliable ways, minimizing the external changes from one release to the other.
> 
> Also, note that it's very difficult for groups outside Trieste
> to have a sense of what will/will not happen to the codes, and this
> doesn't help the broader developer community (gitlab has improved things
> a lot, but there is still the sense that changes and developments aren't
> coming from bottom-up requests, or even a broader discussion - having regular meetings of the QEF foundation, or pre-planned developers' meetings where people can connect in remore, or public hackatons on certain goals, would all help - especially if adveertised/planned
> early).
> 
> Here is the list:
> 
> -----
> 1) XML output - it would be great to have some public reference document
> or roadmap (e.g. on gitlab) that could summarize
> 
> - current status of XML output, open issues, and which will be
>   addressed in the following release
> 
> - which PP tools do/do not support the new XML
> 
> 2) roadmap for pw and for other codes: what are the planned
> developments, especially for what concerns the input and output
> (this is e.g. essential for us, to make sure we do not lose
> functionality of all the workflows developed)
> 
> 3) hdf5 file format (with documented schema): what is the status?
> it would be great to have it for all binary data, in particular for
> wavefunctions, density and potential, encoding all auxiliary data needed
> for interoperability and reproducibility (e.g. g-vector ordering, cell
> vectors, etc..).
> 
> 4) k-point generation (and symmetries): standardize generation, for
> example by adopting spglib, which is increasingly becoming a de facto
> standard and has wide functionality.
> 
> 5) pseudopotentials (less of an issue): which format to use upf, json,
> xml ? upf is a poor approximation of xml.
> -----
> 
> Thanks a lot,
> 
>                nicola
> 
> 
> 
> ----------------------------------------------------------------------
> Prof Nicola Marzari, Chair of Theory and Simulation of Materials, EPFL
> Director, National Centre for Competence in Research NCCR MARVEL, EPFL
> http://theossrv1.epfl.ch/Main/Contact http://nccr-marvel.ch/en/project