vadere issueshttps://gitlab.lrz.de/vadere/vadere/-/issues2023-05-17T16:04:42+02:00https://gitlab.lrz.de/vadere/vadere/-/issues/365[Simulator]: Check TimeCostFunctionType Enum for dead items.2023-05-17T16:04:42+02:00Schuhbaeck, Stefan[Simulator]: Check TimeCostFunctionType Enum for dead items.Queueing is not dead.Queueing is not dead.https://gitlab.lrz.de/vadere/vadere/-/issues/357[Test/Scenario] Add model tests from ISO 204142023-05-17T16:39:10+02:00Mayr, Christina Maria[Test/Scenario] Add model tests from ISO 2041413 tests for model validation are defined in the ISO 20414.
![iso20414](/uploads/899046475c447b8ab4a5674f886214c5/iso20414.png)
Add a scenario for each test.
For the setup the tests marked in green (Table), the Vadere simulator does no...13 tests for model validation are defined in the ISO 20414.
![iso20414](/uploads/899046475c447b8ab4a5674f886214c5/iso20414.png)
Add a scenario for each test.
For the setup the tests marked in green (Table), the Vadere simulator does not need to be adjusted.
For the other tests, adaptions might be necessary.https://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/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/274Move "add FootStep" to Pedestrian internals2023-04-27T16:12:59+02:00Ghost UserMove "add FootStep" to Pedestrian internalsDependency: solve #272 first
Currently, the FootSteps have to be added by the UpdateScheme. However, it may be better that this is handled internally (e.g. when calling `updateNextPosition` is called).Dependency: solve #272 first
Currently, the FootSteps have to be added by the UpdateScheme. However, it may be better that this is handled internally (e.g. when calling `updateNextPosition` is called).https://gitlab.lrz.de/vadere/vadere/-/issues/264Remove (deprecated) Topography.clone() or undeprecate it2023-04-27T16:19:24+02:00Ghost UserRemove (deprecated) Topography.clone() or undeprecate itText from `Topography.clone()` in `Topography.java`:
```
Creates a deep copy of the scenario.
@deprecated This manual implementation is error-prone. Remove this method
and use the standard clone instead.
```
added in year 2...Text from `Topography.clone()` in `Topography.java`:
```
Creates a deep copy of the scenario.
@deprecated This manual implementation is error-prone. Remove this method
and use the standard clone instead.
```
added in year 2016. However, there are more recent changes in the method.
So either remove the deprecation and allow to use it or remove the method.
Another point is, that pedestrians and cars are added via reference (i.e. shallow copy) -- not sure what the wanted behaviour is here?https://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/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/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/108NelderMead - Toleranz als Attribut herausziehen2023-05-17T16:49:30+02:00Schuhbaeck, StefanNelderMead - Toleranz als Attribut herausziehenhttps://gitlab.lrz.de/vadere/vadere/blob/develop/VadereSimulator/src/org/vadere/simulator/models/osm/optimization/StepCircleOptimizerNelderMead.java#L66
The tolerance of the solver might need to be even smaller to avoid all overlaps. Un...https://gitlab.lrz.de/vadere/vadere/blob/develop/VadereSimulator/src/org/vadere/simulator/models/osm/optimization/StepCircleOptimizerNelderMead.java#L66
The tolerance of the solver might need to be even smaller to avoid all overlaps. Unless they're only related with the pedestrians which are considered for the calculation. xref #90.https://gitlab.lrz.de/vadere/vadere/-/issues/69In simulator, create packages for (mandatory) "main models" and (optional) "s...2023-05-17T16:52:51+02:00Ghost UserIn simulator, create packages for (mandatory) "main models" and (optional) "sub models"A simulation requires a "main model" (e.g., OSM) and has optional sub models (e.g., a group model). This should also be reflected on package level.
**But watch out:** this change would break current simulator code (because package names...A simulation requires a "main model" (e.g., OSM) and has optional sub models (e.g., a group model). This should also be reflected on package level.
**But watch out:** this change would break current simulator code (because package names are hard-coded in source code somewhere). Therefore, extend VADERE migration assistant.https://gitlab.lrz.de/vadere/vadere/-/issues/27Ugly classes JsonConverter & StateJsonConverter2023-05-17T16:56:19+02:00Zoennchen, BenediktUgly classes JsonConverter & StateJsonConverterJsonConverter and StateJsonConverter contain only static methods which is not OO. The code could be more elegant. Refactoring required.JsonConverter and StateJsonConverter contain only static methods which is not OO. The code could be more elegant. Refactoring required.https://gitlab.lrz.de/vadere/vadere/-/issues/20JSON save to file and load from file should remember last location2023-05-17T16:56:41+02:00Ghost UserJSON save to file and load from file should remember last locationIt would be great, if the JFileChooser dialogs in the GUI's tabs "Simulation", "Model", "Pedestrians", and "Topography" would remember their last location.
Common use case: Load a generated test topography from a separate file in a dire...It would be great, if the JFileChooser dialogs in the GUI's tabs "Simulation", "Model", "Pedestrians", and "Topography" would remember their last location.
Common use case: Load a generated test topography from a separate file in a directory other than the project directory.
Save and Load dialogs of one tab should maybe share one location. Dialogs from different tabs should probably not share the same location, since they are for different "file types".
Default can be the project directory. Or store it in something like an ini file to restore it in the next session.