How to contribute

Welcome! You can report issues here or ask questions there.

Contributing code to OpenRadioss

Please first discuss the changes you wish to make via the issue or the discussion tabs. You must be aware of the license. We will ask you to sign a Contributor License Agreement (CLA).

Settings

Windows users may want to use git bash or WSL

• Create and a GitHub account
  • Add an SSH key.
  • Review your account settings, in particular: email, 2FA
• Fork the OpenRadioss repository

• Install git-lfs. On Linux, you may need to install some packages first:

  On RHEL, Rocky Linux, CentOS

    sudo dnf install git-lfs
  

  On Ubuntu, Debian

    sudo apt-get install git-lfs
  

  Then, activate LFS:

   git lfs install
  

• Clone your fork and go into the newly created OpenRadioss directory.
• From your local OpenRadioss directory, review your git username and email. If you don't want to expose your email address:
  • Check the boxes Keep my email addresses private and Block command line pushes that expose my email here
  • Find your ID+username here
  • Type the following:

git config --global user.email "<ID+username>@users.noreply.github.com"

• Add the official repository as a remote:

git remote add upstream git@github.com:OpenRadioss/OpenRadioss.git

• Now origin points to your fork, and upstream points to the official OpenRadioss repository

Contribution workflow

The typical workflow is described in this picture: It is not recommended to push commits directly into your main branch. This branch should be a copy of the official repository.

• git checkout main to go to the main branch of your local directory
• git pull upstream main to get the latest revision of the official main branch
• git checkout -b <devel_branch_name> to create and go to a development branch
• Development, loop over:
  
  • Open and edit files
    
  • git status to see which files have been edited
    
  • git add <filename> each file
  • git commit -m “<message>” with a good message.
• Review your history: squash your commits, write a meaningful commit message
  • git rebase -i main provided that your current branch is derived from the main branch.
  • To squash all your commits into your first one: replace pick with squash for all your commits except your first one. Do not squash your commits into someone else's commit. Do not embed someone else's commit into your squashed commit.
• Rebase your work on the latest version of OpenRadioss (you can also follow this)
  • git pull --rebase upstream main
    
  • Solve conflicts, loop over:
    
    • Edit conflicting files and resolve conflicts
    • git add <filename> to mark files as resolved (do not commit)
    • git rebase --continue
• Push to the devel branch of your fork:
  • git push -f origin <devel_branch_name>
• Fill a pull request. Note that new commits pushed on that branch will be automatically added to the pull request.
• Once the merge is accepted, it is recommended to delete the branch from your fork and your local repository
  

Guidelines and coding style

Fortran coding style

See template/template.F90

DOS	DONTS
Use Fortran 90	Runtime polymorphism, type-bound procedures
*.F Fixed length (132), uppercase for legacy files
*.F90 free format for new files
Filenames: <subroutine_name>.F, <module_name>_mod.F	*.f, *.F90
Indent using 2 spaces	use tabs
Modules and derived type	COMMON, EQUIVALENCE, SAVE
Pass variables (built-in and derived types) as dummy arguments	use global variables
Look for clarity	GOTO, multiple RETURN
Explicit size of dummy argument arrays INTEGER, INTENT(IN) :: A(LEN)	INTEGER, INTENT(IN) :: A(*)
Use bounds for arrays operations	A = B + C when A,B,C are arrays
Use the MY_REAL type for real numbers	use DOUBLE PRECISION systematically
Use ALLOCATABLE arrays	use pointers when allocatable is possible
use `MY_ALLOC or check the status of the allocation	use large automatic arrays
Deallocate arrays as soon as possible	use automatic deallocation

Fortran Performance

• vectorization
  • Use #include <vectorize.inc> that contains the IVDEP directive
  • When possible, work on arrays of size MVSIZ
  • when possible, avoid using IF / THEN / ELSE inside DO loops
  • Avoid using EXIT and CYCLE inside computationally intensive loops
  • Avoid calling function or subroutine inside computationally intensive loops
• Rule of thumb for data locality of 2D arrays:
  • largest dimension should be last if it is >= MVSIZ, or 128 (X(3,NUMNOD))
  • largest dimension should be first if it is <= MVSIZ or 128 (C(MVSIZ,5))
• Do not use aliasing of dummy arguments: different arguments must point to different memory locations
• Avoid large arrays of small datatype: prefer POINTX(1:NBPOINT) to POINT(1:NBOINT)X
• Initializing large array can be costly, avoid flushing to zeros entire arrays when it is not needed
• Use integer exponent instead of real exponent ( A**2 instead of A**2.0 )