New coding practices for LSDALTON

Transcription

1 New coding practices for LSDALTON Simen Reine Centre for Theoretical and Computational Chemistry (CTCC), Department of Chemistry, University of Oslo, Norway November 20th, 2015 Simen Reine (CTCC, University of Oslo) November 20th, / 14

2 Outline DFT - MP2 difference in electro DFT - MP2 difference in electrostatic potential CAMB3LYP - MP2 B3LYP - MP2 (includes long-range correction) (no long-range correction) CA B3LYP - MP2 (includ (no long-range correction) LSDALTON Code Environment Gitlab Getting started Rebase and Squash Blue/red regions correspond to increased/decreased electrostatic potential for DFT compared to MP2 Merge Request See Frank Jensen, J. Chem Theory Comput. 6, 2726 (2010) for related discussion on electron affinity Coding Practices Blue/red regions correspond to increa electrostatic potential for DFT comp See Frank Jensen, J. Chem Theory Comput. 6, 2726 (2010) for related Open Source Simen Reine (CTCC, University of Oslo) November 20th, / 14

3 LSDALTON Electronic-structure software tool originated from DALTON (1999) 3 releases: 2011, 2013, licenses upcoming release in January developed in Norway and Denmark roughly 35 developers core code 520k lines external modules 210k lines fortran 90 (72%) and c/c++ (28%) MPI/OMP parallelized GPU developments Functionality linear-scaling DFT (and HF) linear-scaling DEC MP2/CC linear and quadratic response properties geometry optimization dynamics Goals own research training tool for other researchers visibility and impact funding Simen Reine (CTCC, University of Oslo) Require long term strategies code environment testing coding practices maintenance documentation releases user support collaboration November 20th, / 14

4 Code environment Version control system revision: state of a project history code changes branches git Build automation software build compilation linking testing setup cmake Automated testing nightly builds different compilers MPI/OMP/GPU testboard.org Simen Reine (CTCC, University of Oslo) November 20th, / 14

5 Gitlab Gitlab Features code hosting system free community edition enterprise edition used by 100k+ organizations 700 open source contributors 27 employees web-based git repository wiki issue tracking activities continuous integration (CI) merge request/code review Simen Reine (CTCC, University of Oslo) November 20th, / 14

6 Getting started 1/2 New developer supervisor introduces you to the forum register to gitlab in dalton group owner adds you to the dalton group register to the forum members Radovan Bast adds you to the forum add public ssh key to gitlab under Profile Settings SSH Keys cd /.ssh ssh-keygen -t dsa Build the code clone the repository (always use the --recursive option) git clone --recursive my_repository run the setup cd my_repository./setup my_build build the code cd my_build make run tests ctest consult for assistance Simen Reine (CTCC, University of Oslo) November 20th, / 14

7 Getting started 2/2 Start coding create a feature branch git checkout -b my_name/my_feature code and commit git status git diff git commit <files> always look at the status and the diff - is this what I want to commit? do several commits and merges with master until the code works When you are ready to push to master rebase squash push to origin (automatic CI) file a merge request review (and merge) delete branch (if not done by the reviewer): git push origin --delete my_branch Simen Reine (CTCC, University of Oslo) November 20th, / 14

8 Rebase and squash Rebase the branch on top of master: $ git checkout master $ git pull $ git checkout my_name/my_feature f3 $ git rebase master f2 Then squash it into one commit: $ git reset --soft master $ git status $ git commit f1 m4 m3 m2 m1 f3 f2 f1 m4 m3 m2 m1 Rebase s1 m4 m3 m2 m1 Squash rebase puts your local commits on top of the commits on master changes the commits (different hash) do not rebase commits that are outside your repository! ie. either when others have branched off your branch, or cherry-picked one of your commits reset --soft changes the pointer to a different commit, but keeps the code changes by all subsequent commits a new commit then combine all the code changes into one commit Simen Reine (CTCC, University of Oslo) November 20th, / 14

9 Merge request and review Push to origin: git push origin my name/my feature this will initiate the CI testing checks out, builds and tests the code File a merge request a gitlab feature under dalton/lsdalton and Merge requests press +NEW MERGE REQUEST select Source branch my name/my feature and Target branch master press COMPARE BRANCHES write a proper title and description add an assignee to review your changes press SUBMIT NEW MERGE REQUEST Code review - typically takes 1-2 minutes CI builds successful? one commit? clear commit message? does the code look reasonable? if new keyword also added/modified test? documentation? updated change log? if bugfix also close issue? Check that the merge has not broken any tests/builds on testboard.org the next day! Simen Reine (CTCC, University of Oslo) November 20th, / 14

10 Coding practices 1/3 General rule In general Do not publish anything with unreleased code without explicit permission of the authors of that code (i.e. typically through a collaboration) document your code - Doxygen update manual - doc/keywords.tex report problems and bugs - file a ticket on gitlab test your code properly! update CHANGELOG.rst avoid code duplication! keep it short, keep it simple! keep default printing to a minimum modularity, modularity, modularity!!! new developers encouraged to develop submodules Modular code independent code specific functionality modular code is long lived components can easily be replaced code can easily be ported minimizes inter dependencies today: external submodules Ideally self contained define a clear external interface may depend on other modules make sure these modules can easily be replaced provide code environment (version control, build automation, testing) Simen Reine (CTCC, University of Oslo) November 20th, / 14

11 Coding practices 2/3 Branching and commit policy master main development line release/1 current release branch avoid long-lived branches! create one branch for each specific feature or bug fix ideal life time a few days or weeks keep new features as modular as possible delete branch after merge back to master Long-lived branches cannot fully be avoided, e.g. for new PhD students supervisor responsibility: ensure modularity and merge to master make interface early on and in master branch Release branch semantic version control: release X.x one release branch for each major release X major release number x minor release number - bugfixes and minor feature updates never merge master into release branch fix on release then merge back to master or cherry-pick commit to the release branch policy - support current release branch until new release Simen Reine (CTCC, University of Oslo) November 20th, / 14

12 Coding practices 3/3 Fortran 90 always use implicit none always make your module private separate declaration of input and local variables intent(in/out/inout) for all arguments - use intent(inout) for derived types always use the inquire function present for optional arguments never initialize a variable upon declaration remember to update documentation when changing already documented code! keep all variables as local as possible (exceptions in some time critical parts) avoid global dependencies - breaks modularity avoid redundant input arguments data structures should represent a natural unity - avoid adding data to a structure that does not belong there! code object oriented as much as possible - through use of private/public code hierarchically: level 0 routines are self contained, level 1 depend on level 0 and 1, etc. Simen Reine (CTCC, University of Oslo) November 20th, / 14

13 Open source Open source license... to study, change, and distribute software to anyone and for any purpose (wikipedia) Intent to go open source dalton meeting 2015 provided all developers agree! Why open source? hosting infrastructure for free minimize release effort immediate availability of patches scientific reproducibility more developers more users higher impact code review more funding opportunities enhance collaboration Missing need to choose a license policy to treat external developments consent from contributors Simen Reine (CTCC, University of Oslo) November 20th, / 14

14 The End Simen Reine (CTCC, University of Oslo) November 20th, / 14