Code Repositories

Clone from Github

Tested versions of DAMASK are mirrored at GitHub/Eisenforschung/DAMASK.

DAMASK GitLab-Server for Developers

The full DAMASK repository is hosted at the DAMASK GitLab-Server at MPIE. You need an account to clone!

Request an Account

  • If you want to contribute code, you need to approve the Contributor License Agreement, which you can download here.
  • Please write an email with the CLA attached to damask-CLA@mpie.de stating your approval to request developer status in GitLab.
  • Access via SSH and password does not work (a keyfile is required)

Contribute

Set up git on your computer such that GitLab can recognize you:

 

git config user.name "FIRSTNAME LASTNAME"
git config user.email "A@B.DE"

 

in the DAMASK repository or

 

git config --global user.name "FIRSTNAME LASTNAME"
git config --global user.email "A@B.DE"

 

for a system-wide setup. development is the branch that should always work (and release / master of course as well). For any changes, create a new branch named after the feature you’re working on (or, contribute to an existing branch). For new features, create tests.
After finishing working on a branch, test the code. If it is working, request to merge it into development. Assign the merge request to one of the developers (other than you!). For a small bugfix to the latest commit, use
git commit --amend

Workflow model

In contrast to centralized version control systems such as SVN, their distributed counterparts offer a lot of flexibility in selecting a workflow model. https://www.atlassian.com/git/tutorials/comparing-workflows/forking-workflow presents some possible workflows. A detailed discussion, including many links, can be found at http://stackoverflow.com/questions/2621610/what-git-branching-models-work-for-you

  • DAMASK work flow
    • Create a new branch for features and improvements.
    • Once all changes are done, request to merge them into the development branch.
    • After a successful test, development is automatically merged into master.
    • Releases are manually created from the master branch and constitute the release branch.

Tags

Tags are used to mark certain revisions. Releases are marked by tags. Read this German text or check out semver.org

DAMASK G MM.mm.ff.pppp
^^^^^^--------------------------- Name
       ^------------------------- Generation (skip for the moment)
         ^^---------------------- Major (not backward compatible, old input files will not work)
            ^^------------------- Minor (new features)
               ^^---------------- Bugfix
                  ^^^^----------- Patch

Correctness Checks

For a fast feedback on any changes pushed to the http://magit1.mpie.de, modified files are checked before a push is accepted. This is done via a pre-receive hook. Python files are checked for invalid code, unused variables etc. using prospector. Prospector is a tool to analyze Python code and reports information about errors, potential problems, convention violations, and complexity and combines the functionality of other Python analysis tools. The configuration file DAMASK.yaml is designed to ensure compatibility with Python 2.x and Python 3.x. Any change in the src subdirectory triggers a syntax check with gfortran -fsyntax-only for the grid solver; Any change in the src subdirectory triggers a syntax check with ifort -fsyntax-only for MSC.Marc. To skip this check, add ‘[skip sc]’ to the final commit message, e.g. via
git commit -a --amend
in the case that all your changes are locally committed already.

Testing

Extended testing is performed on each push using the GitLab Continuous Integration. All tests specified in a configuration file in the main repository are run on the test server (nohup, using Damask_user). The pipelines give a feedback on which tests failed. To skip the tests, add ‘[skip ci]’ to the final commit message, e.g. via

 

git commit -a --amend

 

in the case that all your changes are locally committed already. If the test suite needs to be modified for a certain branch, the submodules feature of git allows to couple the status of the branch with a fitting commit in the PRIVATE repository. Initialize (i.e. clone) the PRIVATE repository via

 

git submodule update --init

 

Any change in PRIVATE needs to be committed/pushed as usual. As submodules are linked as commit IDs (hashes) and not as branches, after initialization you are in ‘detached head’ mode and need to check out the branch of interest (typically ‘master’). Additionally, commit the current commit ID of the PRIVATE repository in the DAMASK repository:

 

git commit PRIVATE

 

By that, the status (i.e. the current commit ID) is stored in the current branch of the DAMASK repository and will be used by the test facility. https://docs.gitlab.com/ce/ci/git_submodules.html