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.

Check Howto.md files in different directories for build instructions and git installation.
- Userlib_sdk : How to Build OpenRadioss userlib_sdk.
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

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

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

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

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 )