vadere issueshttps://gitlab.lrz.de/vadere/vadere/-/issues2023-05-17T15:57:20+02:00https://gitlab.lrz.de/vadere/vadere/-/issues/187[Readme] How to contribute code2023-05-17T15:57:20+02:00Ghost User[Readme] How to contribute code**The aim is to always maintain a working `master` branch. "Working" means that all tests in the continuous integration (CI) pass.**
The tests do not guarantee a bug-free state, but everything that is tested works.
The main reasons to...**The aim is to always maintain a working `master` branch. "Working" means that all tests in the continuous integration (CI) pass.**
The tests do not guarantee a bug-free state, but everything that is tested works.
The main reasons to maintain this state on `master` are:
* "Release quick and often", i.e. whenever required, and without spending weeks of debugging to get the tests running again.
* Isolate bugs faster, which means reduced debug time. When the `master` passes all tests and your new feature does not, you only have to look for the code changes of your new feature, which is a pretty good starting point for debugging.
# Ways to contribute code are:
Optimally, there is already an existing issue that you want to solve. If there is, link the issue in your commit messages (i.e. `#[ISSUE_ID]`) or your merge request description. Gitlab automatically links all commits/merge requests with this issue and it is easier to find issue related code.
## Standard work-flow
* branch from `master` (or any other branch if applicable)
* Make this branch a merge request in gitlab https://gitlab.lrz.de/vadere/vadere/merge_requests .
* When you push to a new branch, gitlab immediately suggests to you to make this branch you pushed at to create a merge request.
* You can create a branch and merge request with one click from an existing issues directly with "Create merge request".
* For an example, there is a merge request attached at the bottom of this issue.
* Optionally, if you intend to work for longer, mark the branch name with "WIP:" (Work in progress), so everyone is aware to not merge until the WIP status is resolved. Gitlab offers a button to add/remove this status.
* Push all new code (refactoring, bugfix or new feature) to this branch.
* After your implementation is complete, wait until the continuous integration passes. You get usually an email if it does not.
* Solve all merge conflicts in your branch/merge request (and **not** on `master`). Gitlab checks for you if there are conflicts in the merge request.
* After your work is done, all potential merge conflicts are resolved and your merge request passes the CI, then you can merge to `master`. Click the option "remove branch", which removes the underlying branch you pushed your code to after successful merge. For a new code contribution you can create a new branch. Note: you may also want to remove the branch locally.
* You can also use the option "Merge when pipeline passes" in your merge request. Then you do not have to wait for the CI.
* Optionally: If there are a lot of commits that were just work in progress for a single issue, you may choose to **squash** the commits when merging, i.e. all commits are grouped into one on `master` which keeps the history clean.
## "Small commits"
If you just commit something you are very sure it doesn't break anything, go ahead and push directly on `master`.
## I wrote a new test that would fail on `master`
The `master` is not bug-free then. But we still need it to pass all tests. There may be other merge requests relying on a working `master`. Therefore, proceed with the standard way: Create a merge request and first fix the bug, then add the test (both in a merge request). The concept is that the `master` always fulfils the **current** set of tests.
# What to do when the `master` fails?
If the CI happens to fail on `master` after you committed/merged new code and it is certain that this the cause, then **undo your commit on master and proceed the standard way** (i.e. create merge request with your commits). Compare your code to the (now running again) master, and look out on what is causing troubles.https://gitlab.lrz.de/vadere/vadere/-/issues/184[Readme] How to work on an issue2023-05-17T17:09:08+02:00Ghost User[Readme] How to work on an issue1. **Assign yourself to the issue** (to show other developers that you are working on this issue).
2. **Assign the label ~"Doing".**
3. **Close the issue if the implementation is finished** (this includes unit tests, documentation and po...1. **Assign yourself to the issue** (to show other developers that you are working on this issue).
2. **Assign the label ~"Doing".**
3. **Close the issue if the implementation is finished** (this includes unit tests, documentation and possible adaptions in [CHANGELOG.md](https://gitlab.lrz.de/vadere/vadere/blob/master/CHANGELOG.md)).
Following figure visualizes this workflow:
![GitLab-Issue-Workflow](/uploads/1bcf8b603d3a23e7ffa8207af8b37b96/GitLab-Issue-Workflow.png)https://gitlab.lrz.de/vadere/vadere/-/issues/179[Readme] How to write new issues2023-05-17T17:08:38+02:00Marion Goedel[Readme] How to write new issues1. **Use templates when creating new issues.**
* The templates contain common questions which are relevant for new issues.
* The templates can be selected from the drop down menu next to the title bar.
![GitLab-TemplatesDropDo...1. **Use templates when creating new issues.**
* The templates contain common questions which are relevant for new issues.
* The templates can be selected from the drop down menu next to the title bar.
![GitLab-TemplatesDropDown](/uploads/7f5b7426b1285692770abe205ade1a3e/GitLab-TemplatesDropDown.png)
2. **Use the [existing labels](https://gitlab.lrz.de/vadere/vadere/labels) and respect their use cases which are described in the label description (at least, use one of the priority labels: ~"High priority", ~"Medium priority" or ~"Low priority").**https://gitlab.lrz.de/vadere/vadere/-/issues/140Scenario Checker - wishlist2023-05-17T17:07:24+02:00Marion GoedelScenario Checker - wishlistSince the topography checker is extended to the other tabs, here is a place to add in your ideas / wishes on what the Scenario Checker could do:
#### Simulation
* [x] ERROR: Bounds for `simTimeStepLength` - Suggestion: [0.01 - 1]
* [...Since the topography checker is extended to the other tabs, here is a place to add in your ideas / wishes on what the Scenario Checker could do:
#### Simulation
* [x] ERROR: Bounds for `simTimeStepLength` - Suggestion: [0.01 - 1]
* [ ] WARNING: realTimeSimRatio != 0 - only if started from console
(Maybe this could also be realized by visualizationEnabled = false -> then automically realTimeSimRatio is set to 0)
#### Model
* [ ] WARNING: OSM + optimizationType = DISCRETE AND varyStepDirection = False -> Background: Pedestrians might not be able to walk through small passages
* [ ] WARNING: `loadingType` "CONSTANT_RESPECT_TARGETS" and "DYNAMIC" because they are deprecated
(compare: https://conwiki1.cc.private.hm.edu/confluence/display/FK07PD/VADERE+Input+Parameters)
* [ ] WARNING if the parameters deviate from the default configuration - to avoid accidental "mis-"settings
* [x] WARNING if groupSizeDistribution of any source is different from [1.0] but AttributesCGM is not present in Model tab (no groups will be simulated)
#### Topography
* [x] WARNING: No target that has `absorbing` = true (that means pedestrians will never leave the simulation)
* [x] WARNING: if a list of targets is defined but one (which is not the last one) has the attribute `absorbing` = true
-> pedestrians won't reach their final target
* [x] WARNING: if `radius` != 0.2 (because at the moment all potentials are calibrated for this radius)
* [x] ERROR: If in a source a group distribution is given where something other then groups of 1 are produced and the group submodel is not given throw an error.
* [ ] ERROR: If a pedestrian has no target (separate pedestrian)
* [ ] ERROR: If distributionParameter of the source is 0.0 - leads to Exception (Exception in thread "AWT-EventQueue-0" java.lang.NullPointerException)
* [ ] WARNING: if the source is too small for the amount of agents spawning. Some formula to estimate the pedestrian density required here, e.g. sourceArea / spawnNumberInSeconds < alpha => warning!
* [ ] WARNING: if `footStepsToStore` is zero (position interpolation and computing speed does not work then properly)
* [ ] WARNING: if `lineCrossProcessor` is within obstacle (flow will not be calculated correctly!)
-> maybe also, `LineCrossProcessor` attribute `Line line` can be defined as `Measurement Area`
* [ ] ERROR: agents might stop suddenly in front of non-absorbing targets if agent's `minStepLength` and target's `deletionDistance` are in conflict. Therefore, check `minStepLength < deletionDistance` or `minStepLength + eps < deletionDistance`. See #140.
* [ ] ERROR: if area of obstacle == 0
* [ ] NO WARNING: check for the targets if they are used by a dynamic element
##### TargetChangers
* [x] NO WARNING: If a ``TargetChanger`` is present, some targets might be used only by it. In this case, a warning is currently displayed that the target is unused.
* [ ] WARNING: If a ``TargetChanger``is present but ``useMinimumStepLength`` is ´´true``. Recommend to set to ´´false´´.
##### Free-flow speed
* [ ] ERROR: In attributesPedestrians: When the `speedDistributionMean` is set larger or smaller than the `minimumSpeed` and `maximumSpeed` (NOTE: same as in Topography checker for single placed peds)
* [ ] ERROR: Negative (maybe even non-positive?) `minimumSpeed` && The `maximumSpeed` set larger than 12 m/s (12.4 m/s is the world record by Usain Bolt) (NOTE: same as in Topography checker for single placed peds)
* [ ] ERROR: `minimumSpeed` is larger than `maximumSpeed`
* [ ] WARNING: If the free-flow std is larger than the limits for `minimumSpeed` and `maximumSpeed` allow.
#### Data processing
* [ ] WARNING if `writeSimulationData` = false even though output processors are added and files are defined in which their output should be saved
* [ ] ERROR if group model is active groupId Processor must be selected
* [ ] ERROR if `PedestrianPositionProcessor` is set and `footStepsToStore` is 0. Bachground: The pedestrian position processor uses the latest foot step for interpolation, so it always needs the latest footstep and therefore a capacity of minimum 1.