Repository navigation
start2code
Mirror Bot edited this page Aug 31, 2026
·
2 revisions
- Basic understanding of programming (ideally C++) helps a lot
- Active openCFS user: Use openCFS before implementing something – the simulation workflow itself is already important to understand
- Set up development environment
- User docu https://opencfs.gitlab.io/userdocu/
- Testsuite https://gitlab.com/openCFS/Testsuite
- Application examples https://opencfs.gitlab.io/userdocu/Applications/Singlefield/Acoustics/SoundBarrier/
- XSD https://github.com/openCFS/cfs/tree/master/share/xml/CFS-Simulation/Schemas
- Youtube channel https://www.youtube.com/@openCFS
- Source code https://github.com/openCFS/cfs/tree/master
- In-person meetings / talks with experienced colleagues
- Contributing guide https://github.com/openCFS/cfs/blob/master/CONTRIBUTING.md
- User docu https://opencfs.gitlab.io/userdocu/
- Wiki/Devel Wiki https://github.com/openCFS/cfs/wiki/home
- In-person meetings / talks with experienced colleagues Videos from previous workshops: https://www.youtube.com/playlist?list=PL3J3fxoRSG__FAP-wXZ4dA3vyIvLSd7CZ
- Before starting to implement: Open merge request / issue to discuss/get hints
- Testsuite https://gitlab.com/openCFS/Testsuite
- Source code https://github.com/openCFS/cfs/tree/master/source
- Doxygen https://opencfs.gitlab.io/cfs/doxygen/index.html
- Style guide https://github.com/openCFS/cfs/wiki/StyleGuide
Code navigation and search are a key part of understanding the code. Navigation in VSCode is documented here.
With debugging, you can get deeper insights into the code and find possible problems. Debugging in VSCode is explained here.
Logging helps writing out messeges, that often also contain data, in files or stdout. openCFS comes with logging functionality as documented here
Also try greping the line number or initial characters of your log message.
This can be really helpful when dealing with complex logs.
- Bug fix
- New feature
- Create a branch
- Discuss what the actual problem is (e.g. issue)
- Set up a minimal example (ideally <400 elements, the lower the number of elements the better)
- Depending on the type of bug: Narrow it down with different setups
- If we know the line already
- Jump into the code and analyze it to see what causes the problem
- Set a break point and debug
- If it results in an error
- Debug the example and check where the error occours
- Call stack:
- Your new best friend when it comes to seeing the nested function calls that led to the problem
- Your „starting point“
- Navigate through the code with step by step to see what is the problem, where does it occour and what causes the problem
- Fix the bug and add comments
- Create a branch
- Create an issue / merge request as soon as possible to discuss the feature and show others what is the plan
- Have a clear plan what the feature will do and try to find out which files/functions need additions
- Outline your structure with comments
- Start implementing the feature (you can try to reuse code snippets)
- Comment stuff
- Creat at least one testcase that covers all functionalities and combinations
- Each testcase shall not have a h5ref file larger than 1 MB and take longer than 1 second on the optimized build
- If you implement something in general but do not finish it (e.g. feature only available in 2D but not 3D) --> a meaningful exception has to be thrown (a warning is usually not good enough)
- Log file accessing log commands (only use this for very small problems!!) (needs a separate log file and is called with -l)
- System matrix export (within linear systems)
- Adhere to the style guide
- Check the Git workflow
- When you are done, assign a reviewer
- A reviewer reviews your code and might ask you to implement changes
- The reviewer is the final instance deciding what is being done
- Other people can join in and comment, but the reviewer has to choose what shall be carried out and in which manner
- Be happy that you contributed!