vadere issueshttps://gitlab.lrz.de/vadere/vadere/-/issues2023-04-27T15:15:16+02:00https://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/318Dynamic Elements Attributes are ignored2023-04-27T15:36:10+02:00Marion GoedelDynamic Elements Attributes are ignored### Summary
Attributes of Dynamic Elements are ignored in the simulation.
### What is the current *bug* behavior?
For the simulation instead of the attributes in the dynamic element (see Topography), the ``attributesPedestrian`` are ...### Summary
Attributes of Dynamic Elements are ignored in the simulation.
### What is the current *bug* behavior?
For the simulation instead of the attributes in the dynamic element (see Topography), the ``attributesPedestrian`` are used. When you click on the agent in the simulation, the information from ``dynamicElements`` is displayed, but it is not used. (Try setting the speed-mean to 0.0 and you'll still see the agent moving - of course you have to adapt the minimumSpeed for this extreme example).
### What is the expected *correct* behavior?
The dynamic element agent should use it's defined properties
### Relevant data
[problem_dynamic_elements.scenario](/uploads/9df51646d4954dcfbd1c2312de18cfd9/problem_dynamic_elements.scenario)
### Starting point
from @stsc : addInitialElements (Topography) might be a good starting point.
### Workaround
Instead of using dynamic elements, we recommend using sources. If you want to position a single element, use the ``Pedestrian`` type of source.https://gitlab.lrz.de/vadere/vadere/-/issues/292Vector3D's getX() and getY() methods cause confusion2023-04-27T15:56:04+02:00Ghost UserVector3D's getX() and getY() methods cause confusion### Problem to solve
The snippet
```
Vector3D vec3d = new Vector3D(1.0, 1.5, 2.0);
VPoint vpoint2d = new VPoint(vec3d.getX(), vec3d.getY();
```
does not produce the expected VPoint (1.0, 1.5) but (0.0, 0.0), because getX() and getY() ...### Problem to solve
The snippet
```
Vector3D vec3d = new Vector3D(1.0, 1.5, 2.0);
VPoint vpoint2d = new VPoint(vec3d.getX(), vec3d.getY();
```
does not produce the expected VPoint (1.0, 1.5) but (0.0, 0.0), because getX() and getY() are inherited from the super class, which is Point. Point itself has the fields
```
public int x;
public int y;
```
and getX() and getY() return them as Doubles. During runtime, a Vector3D holds a point with x=y=0.
I think that it would be less confusing if vpoint2d.getX() and vpoint2d.getY() would return x and y of vpoint2d, not the default values of Point.Schuhbaeck, StefanSchuhbaeck, Stefanhttps://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/255Nelder Mead: some valid configurations throw error2023-04-27T16:22:22+02:00Ghost UserNelder Mead: some valid configurations throw error### Steps to reproduce
Set the Nelder Mead with
```
"stepCircleResolution" : 4,
"numberOfCircles" : 2
```
then Nelder Mead throws an error (not catched) because of an invalid simplex configuration.
It is not clear why this error is ...### Steps to reproduce
Set the Nelder Mead with
```
"stepCircleResolution" : 4,
"numberOfCircles" : 2
```
then Nelder Mead throws an error (not catched) because of an invalid simplex configuration.
It is not clear why this error is raised (the Apache hints, that the same point occurs twice, i.e. probably there is no triangle, but a line).
As a side note: the two parameters are not very intuitive for configurating the Nelder Mead (taken from the discrete case). Maybe it is worth it to have own Nelder Mead parameters.
xref #229 #226 #221 #108 #183https://gitlab.lrz.de/vadere/vadere/-/issues/249Evacuation processors return *always* positive time2023-04-27T16:25:17+02:00Ghost UserEvacuation processors return *always* positive timeThey also have a positive value when:
* No agent reached the target
* Some agents are still in the scenario
* A source still spawns agents into the scenario
If a user is not aware of this property, then a wrong evacuation time (too sm...They also have a positive value when:
* No agent reached the target
* Some agents are still in the scenario
* A source still spawns agents into the scenario
If a user is not aware of this property, then a wrong evacuation time (too small) is used. So it is extremely important that a the simulation time is set large enough. It is also not possible to detect whether all agents made it to the target.
See files:
* TestPedestrianEvacuationTimeProcessor
* TestEvacuationTimeProcessor
* EvacuationTimeProcessor
* PedestrianEvacuationTimeProcessor
* PedestrianEndTimeProcessor
When solving this issue also consider to add a check in `TestOptimizationMetricNelderMeadProcessor` whether all agents reached the target.https://gitlab.lrz.de/vadere/vadere/-/issues/245[MigrationAssistant] reads from output folder2023-04-27T16:25:56+02:00Ghost User[MigrationAssistant] reads from output folder### Summary
The MigrationAssistant tries to migrate scenarios from the output folder. After a checkout to another branch, the output folder can consist of scenarios that are not compatible, which ends up in an error.
Additional (minor...### Summary
The MigrationAssistant tries to migrate scenarios from the output folder. After a checkout to another branch, the output folder can consist of scenarios that are not compatible, which ends up in an error.
Additional (minor) problems:
* The error message on the GUI is empty.
* The error leads to a complete blank GUI, however, the "normal" scenario files are completely valid
* It would be nice if there is a list of files (full filepath) that failed.
### What is the current *bug* behavior?
MigrationAssistant reads scenarios from output folder. Workaround is to remove the output folder.
### Steps to reproduce
Currently:
1. Go to master and run the attached scenario file. (Output should be generated)
2. Checkout to branch salient_behaviour and compile and start, then the error should appear.
[basic_2_density_discrete_ca.scenario](/uploads/d3e55f04244d349e287b65a5428087bd/basic_2_density_discrete_ca.scenario)Schuhbaeck, StefanSchuhbaeck, Stefanhttps://gitlab.lrz.de/vadere/vadere/-/issues/144The first step on the stairs gives an illegal position on the stairs2023-05-17T16:29:06+02:00Ghost UserThe first step on the stairs gives an illegal position on the stairsThe easiest and straightforward fix is to correct the first step on the stairs. This can be done by projecting the first illegal position onto the first or last tread (depending on where the pedestrian entered the stairs).The easiest and straightforward fix is to correct the first step on the stairs. This can be done by projecting the first illegal position onto the first or last tread (depending on where the pedestrian entered the stairs).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.https://gitlab.lrz.de/vadere/vadere/-/issues/11Teleporter-Potentialfeld hat falsche Position2023-05-17T16:59:49+02:00Zoennchen, BenediktTeleporter-Potentialfeld hat falsche PositionVon @dietrich vor etwa 3 Jahren hinzugefügt.
Kommentar von @dietrich: Einfacher Ring-test (rimea 4 mit breite 0.1m) zeigt, dass Peds zu spät teleportiert werden / zu früh das Potential eines vorangehenden Peds spüren.Von @dietrich vor etwa 3 Jahren hinzugefügt.
Kommentar von @dietrich: Einfacher Ring-test (rimea 4 mit breite 0.1m) zeigt, dass Peds zu spät teleportiert werden / zu früh das Potential eines vorangehenden Peds spüren.