vadere issueshttps://gitlab.lrz.de/vadere/vadere/-/issues2023-08-22T12:55:20+02:00https://gitlab.lrz.de/vadere/vadere/-/issues/373[Doc] Description of columns in postvis.traj2023-08-22T12:55:20+02:00Rahn, Simon[Doc] Description of columns in postvis.trajMany users ask the same questions about the postvis.traj files: What’s the meaning of each column?
Add a description for that at a helpful place (maybe adapt GUI/data output tab or add info to the Vadere Wiki). Maybe you also need to exp...Many users ask the same questions about the postvis.traj files: What’s the meaning of each column?
Add a description for that at a helpful place (maybe adapt GUI/data output tab or add info to the Vadere Wiki). Maybe you also need to explain the event queue in that context.Jaeck, LudwigJaeck, Ludwighttps://gitlab.lrz.de/vadere/vadere/-/issues/355[Post-visualization] Accelarate video recording2023-04-27T14:58:49+02:00Mayr, Christina Maria[Post-visualization] Accelarate video recordingVideo recording is slow, sometimes the post-vis is not updated and seems to be stuck, although the recording is still running in the background.Video recording is slow, sometimes the post-vis is not updated and seems to be stuck, although the recording is still running in the background.https://gitlab.lrz.de/vadere/vadere/-/issues/342[BHM] Pedestrians ignore thin obstacles2023-04-27T15:15:16+02:00Rahn, Simon[BHM] Pedestrians ignore thin obstaclesBehavioral Heuristics Model: Pedestrian ignores thin obstacles
### Summary
A pedestrian's evasion strategy (after an agent-agent collision) can yield a 'nextPosition' that lies behind a thin obstacle, e.g., topography bounds.
### What...Behavioral Heuristics Model: Pedestrian ignores thin obstacles
### Summary
A pedestrian's evasion strategy (after an agent-agent collision) can yield a 'nextPosition' that lies behind a thin obstacle, e.g., topography bounds.
### What is the current *bug* behavior?
The following behavior was observed for the pedestrian with id 12 in the scenario Corridor-BHM-Defaults-WithFloorField-CounterflowCognitionModel (cd4f5cc8), but this may also occur in other scenarios with dense crowds that are guided by thin (roughly 0.5m) obstacles:
The agent seems to teleport outside the topography after an agent-agent collision test followed by an evasion move. One of the two calculated evasion spots lies outside of the topography and gets chosen as the destination. This behavior probably occurs because NavigationEvation.getNavigationPosition() yields an evasion strategy that does not collide with the bounding box (obstacle). Since the evasion step or the step length > bounding box width, the next position is outside the topography. Once outside the topography, the agent does not get back easily. At t=31.737..., the agent re-enters the topography because the evasion strategy yields a next position that does not collide with the bounding box VPoint(x=4.443..., y=0.502...).
### What is the expected *correct* behavior?
The evasion strategy should not yield destinations behind obstacles (and/or outside the topography).
### Steps to reproduce
- Checkout 340-target-waiting/cd4f5cc8
- Run the BHM test scenario `Corridor-BHM-Defaults-WithFloorField-CounterflowCognitionModel.scenario`
### Related
Issue https://gitlab.lrz.de/vadere/vadere/-/issues/266 may be related, but here we even employ a floor field.
### Starting point
A quick fix could be:
* to increase the bounding box width such that the BHM evasion strategy can never skip the bounding box.
* to decrease the stepLength of the evasion strategy (this is probably not a good idea because this affects the BHM in general)
A better solution could be:
* Adapt evasion strategy such that the line segment from the current position to the next position does not collide with obstacles (and pedestrians, unless cooperative behavior is expected).
* If the pedestrians respect relatively 'thin' walls, the second problem of pedestrians outside the topography bounds is solved automatically. If we want to treat this separately, a better solution prohibits any position outside the topography, i.e. introduce a check if the next position is outside the bounds.https://gitlab.lrz.de/vadere/vadere/-/issues/337[Simulator] TargetChangerController wrong index for non-absorbing targets2023-04-27T15:18:45+02:00Mayr, Christina Maria[Simulator] TargetChangerController wrong index for non-absorbing targets### Summary
### What is the current *bug* behavior?
If the target is changed by a `TargetChanger`, the nextTargetListIndex > 0.
In this case, the next target id is returned over the targetIds.get(nextTargetListIndex) in `Agent`
```
...### Summary
### What is the current *bug* behavior?
If the target is changed by a `TargetChanger`, the nextTargetListIndex > 0.
In this case, the next target id is returned over the targetIds.get(nextTargetListIndex) in `Agent`
```
public int getNextTargetId() {
// Deprecated target list usage
if (nextTargetListIndex == -1) {
return targetIds.getFirst();
}
// The right way:
**return targetIds.get(nextTargetListIndex);**
}
```
If agents steps on non-observing targets, the list index is incremented. See `TargetController`:
```
if (nextTargetListIndex != -1) {
if (nextTargetListIndex < agent.getTargets().size()) {
agent.incrementNextTargetListIndex();
}
}
```
In the next simulation step, a null pointer is thrown if the index is out of bound.
### What is the expected *correct* behavior?
Use the next available target in an agent's `targetIds`https://gitlab.lrz.de/vadere/vadere/-/issues/297List of things to consider when using triangular meshes2023-04-27T15:49:26+02:00Ghost UserList of things to consider when using triangular meshes@BZoennchen
1. sharp angles (walkable area) can lead to non-determinism of background
* [ ] TODO: can this go into the ScenarioChecker?
2. merge overlapping obstacles
* [ ] TODO: in OpenStreetMap based scenarios points are ofte...@BZoennchen
1. sharp angles (walkable area) can lead to non-determinism of background
* [ ] TODO: can this go into the ScenarioChecker?
2. merge overlapping obstacles
* [ ] TODO: in OpenStreetMap based scenarios points are often *exactly* the same (so that the obstacles do not overlap)
3. fill holes (i.e. not reachable areas) with obstacles
* [ ] TODO: algorithm to do this?
4. (optional): remove co-linear points to decrease number of required faces in mesh
* [ ] TODO: algorithm to do this?
5. (optional): user should remove unnecessary obstacles or parts
* [ ] TODO: (optional) making decisions easier: visual feedback for user of mesh and mesh quality (e.g. red=problematic parts of scenario, white=good quality)
* [ ] TODO use cache mechanism using the scenario hash
* [ ] TODO make Wiki entryhttps://gitlab.lrz.de/vadere/vadere/-/issues/281Algorithm to sample from TruncatedNormalDistribution2023-04-27T16:07:37+02:00Ghost UserAlgorithm to sample from TruncatedNormalDistribution ### Summary
Currently, the (default) algorithm to compute the truncated normal distribution is likely incorrect (implemented in `TruncatedNormalDistribution.java`).
```
@Override
public double sample() {
for (int i = 0; i < maxIte... ### Summary
Currently, the (default) algorithm to compute the truncated normal distribution is likely incorrect (implemented in `TruncatedNormalDistribution.java`).
```
@Override
public double sample() {
for (int i = 0; i < maxIterations; i++) {
double sample = super.sample();
if (sample >= min && sample <= max)
return sample;
}
throw new IllegalArgumentException("Max iteration count reached on sampling for truncated distribution. Parameters bound and min are not suitable.");
```
So the logic is simple: re-sample if the current sample is out of bounds. And error if no sample is found.
Does anybody know if there is any theory or anything behind it to do it this way (or is it a hack-ish implementation)? It is certainly not the best, as it requires the max_iterations parameter which is definitely not required for a "true distribution". I mark it as a bug because the class name suggests something else -- even though it is probably not too far away, it could be a potential source of error, especially when doing uncertainty quantification (Valentina asked me to get the proper distribution in Vadere).
In case there is no guarantee, that this algorithms mimics the truncated distribution without error (actually, that it can raise an IllegalArgumentException with a random factor is already a bug...), in my opinion it is better to change this. So I think changing is better than creating a new "TheRealTruncatedNormatDistribution.java". This way, we can eliminate the potential source of error and we can save some performance drawbacks (if the bounds are very close, a lot of re-sampling is required -- we eliminate the max_iterations parameter then).
@hm-mgoedel @hm-kleinmei @BZoennchen @stsc
Because it is a much used code-piece, I want to ask: Are there any objections?
Here is a Java implementation which uses only Apache Common Math as a dependency:
https://github.com/mizzao/libmao/blob/master/src/main/java/net/andrewmao/probability/TruncatedNormal.javahttps://gitlab.lrz.de/vadere/vadere/-/issues/261AreaDensityVoronoiProcessor - Attributes not clear2023-04-27T16:20:53+02:00Marion GoedelAreaDensityVoronoiProcessor - Attributes not clearIt is not clear how to assign the two attributes ``measurementAreaId`` and ``voronoiMeasurementAreaId`` of the AreaDensityVoronoiProcessor.
### Summary
Apparently, the ``voronoiMeasurementAreaId`` is the area in which the density is c...It is not clear how to assign the two attributes ``measurementAreaId`` and ``voronoiMeasurementAreaId`` of the AreaDensityVoronoiProcessor.
### Summary
Apparently, the ``voronoiMeasurementAreaId`` is the area in which the density is calculated while ``measurementAreaId`` is the area in which the Voronoi Diagram is drawn for the calculation of the density.
### What is the current *bug* behavior?
It seems counter-intuitive that the voronoiMeasurementAreaId is the area that should be smaller. Also, there is no check if the ``measurementAreaId`` is larger or equal to the ``voronoiMeasurementAreaId`` to assure that it's properly used.
### What is the expected *correct* behavior?
It would be better to rename the attributes to e.g. ``measurementAreaId`` (for the **small** area) and ``voronoiDiagramArea`` for the larger area (up for discussion).
At the moment, I understand that the attribute ``measurementAreaId`` comes from the extension of the AreaDensityProcessor or AttributesProcessor, respectively.
In my opinion, this inherited attribute should be the area in which we are interested in so that it is consistent with all other density processor. This is currently **not** the case.
Careful: Most probably, the renaming of the attributes has to be handled by the MigrationAssistant (@hm-schuhba1)! Otherwise, I think old scenarios will not be compatible anymore.
### Steps to reproduce
Use any *.scenario file, add the AreaDensityVoronoiProcessor and two measurementAreas that you want to use. Change the ids for the attributes in the AreaDensityVoronoiProcessor and look at the results to observe the differences in the results. Sidenote: If you have used the processors in the wrong way, you will most likely see discrete levels of densities in the output file.
### Relevant data
Correctly assigned area ids:
* [densities.txt](/uploads/a7602af5d77558b3d9db8fbcae45a772/densities.txt)
* [Liddle_bhm_v2_clone_1.scenario](/uploads/fb245f0fa4f894bf60e7420b4f8d68e3/Liddle_bhm_v2_clone_1.scenario)
Incorrect assignment:
* [Liddle_bhm_v2_clone_1.scenario](/uploads/475902f130e8d73cbabe5a4836c0d67c/Liddle_bhm_v2_clone_1.scenario)
* [densities.txt](/uploads/04b47a42be65399decd9f485696b2f20/densities.txt)
### Starting point
- ``AttributesAreaDensityVoronoiProcessor`` for renaming the attribute
- ``AreaDensityVoronoiProcessor`` init method to interchange the use of the two processors
- MigrationAssistant to assure that we stay compatible with old versionsSchuhbaeck, StefanSchuhbaeck, Stefanhttps://gitlab.lrz.de/vadere/vadere/-/issues/204[Feature] Remove preset for data output in json mode.2023-05-17T15:45:24+02:00Ghost User[Feature] Remove preset for data output in json mode.
https://gitlab.lrz.de/vadere/vadere/blob/master/VadereGui/src/org/vadere/gui/projectview/view/DataProcessingView.java#L141
Remove this json template. New scenarios will always get a default set of processors.
https://gitlab.lrz.de/vadere/vadere/blob/master/VadereGui/src/org/vadere/gui/projectview/view/DataProcessingView.java#L141
Remove this json template. New scenarios will always get a default set of processors.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.https://gitlab.lrz.de/vadere/vadere/-/issues/131Scenario is valid but output files are moved to 'corrupted' because trajector...2023-05-17T16:35:35+02:00Ghost UserScenario is valid but output files are moved to 'corrupted' because trajectory file is missingWhat is the meaning of the "corrupted" folder? I think simulation runs that are valid and all outputs are correctly written out (just without the trajectories file) should not get in this folder. Because the name indicates that something...What is the meaning of the "corrupted" folder? I think simulation runs that are valid and all outputs are correctly written out (just without the trajectories file) should not get in this folder. Because the name indicates that something went wrong with the output.
Reason: in the suq-controller I am generally not interested in the trajectory file and it only generates data.