The best way to familiarise yourself with the internals of OpenCOR is by having a look at its source code.
All of the source code is and must be made available under the
OpenCOR namespace (e.g.
There are only two exceptions to this rule:
[OpenCOR]/src/windows/main.cpp (i.e. OpenCOR’s two main
All changes to the source code must be referenced in the list of issues using labels to:
Request a for or an to a future version of OpenCOR.
Report a or a issue with the current official version of OpenCOR.
Specify a that needs to be carried out for the next official version of OpenCOR.
Specify the binding () associated with a , or issue.
Specify the platform(s) (, and/or ) associated with a , or issue.
Whenever something is pushed to the Git repository, OpenCOR gets automatically built and tested on Windows, Linux and macOS, through Jenkins at the Auckland Bioengineering Institute.
Although it can technically be done, no work should be carried out on the master branch.
Instead, anyone wanting to contribute to OpenCOR should first fork the Git repository.
Work for issue
#XXX should then be done in a branch called
The work done, a pull request should be created.
This will trigger OpenCOR to be built and tested on Jenkins.
Assuming everything goes well, the project manager will decide whether to merge the pull request.
More specific information can be found in the following pages: