Research software development =========== ###### tags: `meeting`, `minutes`, `survey`, `RSE`, `research software engineering` Public brainstorming on research software development at PGI-1/IAS-1. Date of first meeting: 2021-06-15. - [Research software development - Meeting 2021-06-15 - Meeting minutes](https://iffmd.fz-juelich.de/s/JsOYpZGuk) - For further discussion: [iffChat > PGI-1/IAS-1 > Scientific software development](https://iffchat.fz-juelich.de/pgi-1/channels/scientific-software-development) - [iffWiki > PGI-1/IAS-1 > Scientific software development](https://iffwiki.fz-juelich.de/Scientific_software_development) ## Table of Contents [TOC] ## The two opposing viewpoints a) as we are scientists we want to solve a specific problem with our software. Hence, we sit down code something and if it works we achieved our goal. Sucess means that the software we develop can be used to finish a project/PhD. b) software development is human labour intensive. Our development process should therefore lead to a high level of documentation, general applicability, modularization and re-usability and not concentrate on a specific short term solutions. ## Aspects influencing our software development approaches - Our field becomes more "mature", i.e. it is increasingly difficult to make progress by simple developments in software. - Scientific papers are the way to be recognized for your work, software development has no "reward". - Funding situation, most funding for specific scientific projects not for software development. - To be seen as "computational scientists" we have to be able to work on new generation supercomputers. - Understanding of "Good scientific practise" becomes more strict and focused on reproducability and documentation of software. - HGF/FZJ are issuing/working on software policies for research software. ## Survey results [Survey](https://docs.google.com/forms/d/1N2xorn7eEgvi0WhA8aVcRIGnfN61Uwrh7f9iVTUh_DY) [Survey results](https://docs.google.com/forms/d/1N2xorn7eEgvi0WhA8aVcRIGnfN61Uwrh7f9iVTUh_DY/viewanalytics) ## 1. Development as a team: how to communicate, report and make decisions - Fleur meetings in particular sometimes come without an agenda and without a clear directive for everyone what to do. Sometimes, a more focused meeting adressing specific problems, breaking them down and having people specifically target them would maybe be sensible (c.f. workshop yesterday; "sprints"). Then there's also input for the next meeting. - (Comment by Gregor): The Fleur meeting is meant to be informal. We don't need another seminar. - Issue tracker is often left ignored. Concentrated work and clean assignment of tasks would be helpful. - What good practices are there for knowledge transfer (e.g. from/to Master/PhD students)? - Best practises and guidelines should be clearly communicated to have a consistent structure of the code - Knowledge transfer on the codes is problematic. Possible approaches: - Maybe from time to time we should have internal workshops / seminar series for such knowledge transfer. - For the development of some code parts pair programming may be beneficial. - the talk on Monday touched several different approaches to software development (e.g. Scrum, test-driven development, knowledge transfer techniques), which all have advantages and disadvantages. What practices are currently used? Do we have experience/experts on these methologies? - We could consider, that junior programmers get their commits code-reviewed by more senior people. This is pretty common standard in companies and it would quickly improve the coding standard of junior people. - While major codes (fleur, kkr) are probably well organized, smaller activities (wannier, post-processing tools) are lacking a forum. Maybe it would be good to set this up on an institute level. - (Comment by Gregor): I agree that people should have a clear guide on where they find information and where to ask questions on specific topics. - Recruting project member by posting "Wanted" poster (probably to the iffchat??) or project outline and take kickoff gatherings with those "founders" for a new/existing project. Maybe some regular brainstorming meeting without any topic restrictions.. ## 2. Tools for software development - While we have quite an extensive *user* documentation by now, there is nearly no *developer* documentation and very few overhead comments in the code (Fleur). That means if you wanna work on it, you first have to parse through all the files in question to see what they do and do not do. - some metrics came up (e.g. "how much time is spent on throw-away projects", "what reusable scripts are redundantly created"). which metrics should perhaps and can be quantitatively gathered? (e.g. a central list of "reusable scripts") (if everything is under verison control and can be found under several known places, than we could automatically analyse the all git histories and check new/old code, how many people work on what, ...etc) - Maybe we should evaluate from time to time whether certain IDEs are useful.(Do you want to start a war? - No, just explore options.) - We should have a modern way of collecting user feedback and staying in contact with users. For Fleur we now have a user forum hosted by an external service provider. It is a shame that we don't have such an infrastructure from the research center. Mailing lists are not a good option. Note that contact to users (i.e. support) may also be (and for some projects is) tracked by funding agencies. One may have to quantify such efforts. If you start to build a user community only once such a requirement is coming from the top down, you have nothing to start with. - With respect to tools someone gave that link: https://digital.ai/periodic-table-of-devops-tools It may be a good idea to browse that resource to see whether there is something we should use. ### Documentation tools - documentation tools? - python: readthedocs, sphinx - fortran: mkdocs (fleur uses that) - fortran: Is there a possibility to have something similar to the standardized docstrings in python for fortran? (Yes there are some tools eg. Doxygen, FORD) - A comment on documentation tools for code documentation (Doxygen, ...): These tools have their strengths when the API of a library has to be documented and external developers just want to use the library as a black box. They are not meant for making code more understandable. Our code documentation does not necessarily need to be formalized in such a way. ### Git/Version control - there is an introduction of Ingo: https://pgi-jcns.fz-juelich.de/portal/pages/git-talk.html https://pgi-jcns.fz-juelich.de/portal/pages/fleur-git.html or how to use iffgit: https://pgi-jcns.fz-juelich.de/portal/pages/git-server.html ### CI tools - On iffgit there is the internal gitlab CI. not very powerfull running on a single machine. (as example see: Fleur CI: https://iffgit.fz-juelich.de/fleur/fleur/-/pipelines) other example kkr: https://iffgit.fz-juelich.de/kkr/jukkr/-/blob/master/.gitlab-ci.yml , https://iffgit.fz-juelich.de/kkr/jukkr/-/pipelines - _I can't see this (fleur), maybe it's because I'm not a member. I can see the pipelines of KKR though_ - on github easy to add, actions have templates. And for open source porject github provides quite some CI time ### CD tools - example: for masci-tools, aiida-fleur, aiida-kkr look at https://github.com/JuDFTteam/masci-tools/actions/workflows/cd.yml (for python this is easy) - For Fleur releases are every half a year, on requirement. But there is a stable branch (Comment by Gregor: The stable branch is dead and actually never was alive. There is the release branch and the develop branch and some individual branches.) ## 3. Training ourself and new developers - as was mentioned in the questionnaire: training or more info on debuggers, also easier usability for these -> would increase the quality of the simulation codes - Training for the software architecture which might help to think good sofware development in terms of long time usages. Such kind of traning may help member of team to think on the same way. - Do people actually find time for their own training or is their agenda full of milestones for their projects with no time left for training? - (also see video documenation below) - Peer programming, observe how an 'experienced' person does things ## 4. Software Policy, do we need one? - yes, but different for different 'software types' - github: pro: - easier accessible - well indexed by google con: - not completely exportable, therefore migration hard - maybe hard to keep track of what is going on? easier in iffgit? - If we have own infrastructure (iffgit) we should prefer that. - iffgit: Can this be better indexed by google? - Documentation on the naming convention for a specific domain. If it is possible the same naming convention for all domain that’s might be more nice. - follow-up question (wasmer): with 'domain', do you mean code hosting location (URL), or code namespaces? - (Comment by Gregor): I think formalization is only useful and needed if there is no reasonable common sense, also best practice often is a matter of zeitgeist. - keeping legacy as possible when the new version comes out, unless it hurts the performance - How is the authority would be? Who take the maintaning job when responsible person or first developer depart the institute? - a minimal set of guidelines in combination with code review (at least whenever something is merged) this will be very helpful - in principle it is very easy to assign a doi to different code releases (zenodo) which make features/version or libraries citable - There is a discussion on whether we should make software available in containers (e.g. Docker images). This would simplify the usage for new users. ### Interface design - try to rarely if not at all to change interfaces (example input output files), provide versions of interfaces and if possible how to migrate ### Documentation guidelines - code documentation: (absolutely required), i.e every method, subroutine, module has to have a meaningful docstring - user documentation: (this gets outdated fast and takes quite some time to write) - developer documentation: - video documenations (templates?): short tutorials (<5min) on different topics, on youtube? or somewhere where poeple find it