vadere issueshttps://gitlab.lrz.de/vadere/vadere/-/issues2024-02-05T12:57:46+01:00https://gitlab.lrz.de/vadere/vadere/-/issues/375Convex Hull attribute Editors are broken2024-02-05T12:57:46+01:00Jonas SchindlerConvex Hull attribute Editors are brokenFirst, choose a meaningful and short title and mention context in square brackets. E.g., [GUI] Agents overlap if radius greater than 0.2 m
### Summary
So if you create a convex hull or a polygon and then want to change the values manua...First, choose a meaningful and short title and mention context in square brackets. E.g., [GUI] Agents overlap if radius greater than 0.2 m
### Summary
So if you create a convex hull or a polygon and then want to change the values manually in the attribute tab, it gets distorted.
### What is the current *bug* behavior?
So after creating a convex hull or a polygon, the object gets distorted due to the manipulated point getting moved towards the respective zero axis.
### What is the expected *correct* behavior?
A proper polygon that applied the changes correctly.
### Steps to reproduce
Just create a polygon or convex hull go to the Attribute Table tab and modify a coordinate of the point list.
### Relevant data
Took the latest pre-compiled version from the website
### Starting point
I think that the value change hook is probably not implemented correctly and therefore drops the newly inserted value replacing it by zero.https://gitlab.lrz.de/vadere/vadere/-/issues/374[GUI] Render all Icons as SVG2023-09-26T16:16:25+02:00Jaeck, Ludwig[GUI] Render all Icons as SVGOn different Screen resolutions, with different Pixel density, scaled up icons do not look pretty, because of always being scaled up from 16x16 pixel. Since users can also change the icon size in the vadere.conf file, it would be good to...On different Screen resolutions, with different Pixel density, scaled up icons do not look pretty, because of always being scaled up from 16x16 pixel. Since users can also change the icon size in the vadere.conf file, it would be good to change all Icons from a rasterized format to .svghttps://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/368Buffered Writer for DataProcessors2023-07-28T12:54:05+02:00Schuhbaeck, StefanBuffered Writer for DataProcessorsDataProcessors (DP's) keep the data in memory over the whole simulation time and only dump the data to files at the end of the simulation.
Some, but not all DP's, do need all data at the end to merge or calculated the their values. All ...DataProcessors (DP's) keep the data in memory over the whole simulation time and only dump the data to files at the end of the simulation.
Some, but not all DP's, do need all data at the end to merge or calculated the their values. All other can dump their data directly to disk
at the moment they get the data.
### Problem to solve
* Large memory footprint for long/large simulation
* At least some data when simulation fails at some point
### Further details
* Use Buffered writer provided by Java is possible to minimze I/O access. Meaning, only write date at junks of 1-4 kB and not for each
double value.
* provide read-back feature for other DP's that need the data at the endhttps://gitlab.lrz.de/vadere/vadere/-/issues/367[Simulator/GUI] Allow polygons as measurement areas2023-05-25T10:43:14+02:00Mayr, Christina Maria[Simulator/GUI] Allow polygons as measurement areasCurrently measurement areas are rectangular.
- Enable polygons
- rotations > introduce a VRectangleRotated classCurrently measurement areas are rectangular.
- Enable polygons
- rotations > introduce a VRectangleRotated classhttps://gitlab.lrz.de/vadere/vadere/-/issues/366[Simulator] Make numerical adjustable2023-05-17T17:09:26+02:00Schuhbaeck, Stefan[Simulator] Make numerical adjustableTBD: where to put these parameters as they should not belong to a specific model-json.
See:
- #6
- Neldermead thresholdTBD: where to put these parameters as they should not belong to a specific model-json.
See:
- #6
- Neldermead thresholdhttps://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/363[Git] Introduce pre-commit hook for formating (only changed files)2023-05-17T15:36:00+02:00Schuhbaeck, Stefan[Git] Introduce pre-commit hook for formating (only changed files)https://gitlab.lrz.de/vadere/vadere/-/issues/361[The Farm]: They have a good time here... Promise.2023-04-27T16:15:53+02:00Schuhbaeck, Stefan[The Farm]: They have a good time here... Promise.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/344[TEST] BonnMotionTrajectoryProcessorTest fails2023-04-27T15:28:31+02:00Mayr, Christina Maria[TEST] BonnMotionTrajectoryProcessorTest failsThe BonnMotionTrajectoryProcessorTest fails, see e.g. master 899fffc323944765bac02d8556dcd517ccc67b85
Note: the CI is successful, since the test is ignored (see @Ignore annotation![test_not_running](/uploads/76958bed4172971c56139f8f93f...The BonnMotionTrajectoryProcessorTest fails, see e.g. master 899fffc323944765bac02d8556dcd517ccc67b85
Note: the CI is successful, since the test is ignored (see @Ignore annotation![test_not_running](/uploads/76958bed4172971c56139f8f93fec36e/test_not_running.png))Schuhbaeck, StefanSchuhbaeck, Stefanhttps://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/326Zombi Addon2023-04-27T15:31:17+02:00Schuhbaeck, StefanZombi Addon2022-04-01https://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/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/295Use tablesaw in data processors2023-04-27T15:50:24+02:00Ghost UserUse tablesaw in data processors### Problem to solve
As discussed with @stsc and @BZoennchen
We noticed that writing out csv data (at the end of a simulation) can be **very** slow in Vadere (depending on how much data is written). The main reason seems to be the desi...### Problem to solve
As discussed with @stsc and @BZoennchen
We noticed that writing out csv data (at the end of a simulation) can be **very** slow in Vadere (depending on how much data is written). The main reason seems to be the design of how the csv data is written. In short, this involves collecting each row in a LinkedList and casting it to a csv-line). Currently, each DataProcessor fills a Map with objects (key and value).
We decided:
* replace the Map and fill a tablesaw's data frames (tables)
* each table consists of index columns and data columns, all columns have a native data format (usually int or double)
* the DataKey (e.g. PedestrianIdKey) classes are still used and required (to be able to merge processors, in the GUI, and for information about data format of indices)
* The value (generics V in DataProcessors) are removed and handled by the table's columns
* the merging of DataProcessor and writing (merged) tables to csv is still handled in `OutputWriter`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/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.java