Skip to content

Latest commit

 

History

History
117 lines (82 loc) · 6.81 KB

Contributing.md

File metadata and controls

117 lines (82 loc) · 6.81 KB
Raw

How to contribute in the Tools repository

Welcome! You can report issues here for questions, you can use OpenRadioss Git Forum there.

Contributing code to OpenRadioss Tools

You must be aware of the license.

Settings

On GitHub Website

  • Check Howto.md files in different directories for build instructions and git installation.

  • Create your github account

    • Review your account setting, in particular: email, 2FA
    • Setup your git user name and email.
    • If you don't want to expose your email address: Check Email Settings boxes Keep my email addresses private and Block command line pushes that expose my email here
    • Add your ssh key SSH key.

  • fork the OpenRadioss/Tools repository

On your computer

  • Find your GitHub ID+username here

  • Set gitHub Email to your Git configuration :

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

  • clone your fork and go into the newly created openRadioss/Tools directory.

     git clone git@github.com:OpenRadioss/Tools

  • Add the official repository as a remote:

     git remote add upstream git@github.com:OpenRadioss/Tools.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:

image

It is not recommended to push commits directly into your main branch. This branch should be a copy of the official repository.

  • git checkout -b <devel_branch_name> to create and go to a development branch

  • 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

  • For your Developments: loop over

    • Open and edit files
    • git status to see which files has 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 by squash on 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

DOS DONTS
Use Fortran 90 Runtime polymorphism, type-bound procedures
Fixed length (132), uppercase free format, lowercase
Filenames: <subroutine_name>.F, <module_name>_mod.F *.f, *.F90
Indent using spaces use tabs
Modules and derived type COMMON, EQUIVALENCE, SAVE
Look for clarity GOTO, multiple RETURN
#include "implicit_f.inc" that contains IMPLICIT NONE use implicit declaration
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_ALLOCATE 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 POINT%X(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 )