Skip to content

Latest commit

 

History

History
112 lines (90 loc) · 7.02 KB

CONTRIBUTING.md

File metadata and controls

112 lines (90 loc) · 7.02 KB

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

  • fork the OpenRadioss repository

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

    On Rhel,CentOS

      sudo yum 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 user name 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 [email protected]: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: 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 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 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

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 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 )