JPScore issueshttps://gitlab.jsc.fz-juelich.de/jupedsim/jpscore/-/issues2018-03-22T17:31:39+01:00https://gitlab.jsc.fz-juelich.de/jupedsim/jpscore/-/issues/248Removing Dependencies on the directory-tree parsing (JPSfire)2018-03-22T17:31:39+01:00Arne GrafRemoving Dependencies on the directory-tree parsing (JPSfire)## Short description of suggestion
The directory-tree is parsed but when reading the files, the different paths get build with small paths-parts ("Z_") being hardcoded. Yet the shell script for creating these directories from JPSfire-Rep...## Short description of suggestion
The directory-tree is parsed but when reading the files, the different paths get build with small paths-parts ("Z_") being hardcoded. Yet the shell script for creating these directories from JPSfire-Repository ( https://gitlab.version.fz-juelich.de/jupedsim/jpsfire/blob/master/A_smoke_sensor/FDS/A_smoke_sensor/A_smoke_sensor.sh ) opens the possibility to have other prefixes.
## Why would the enhancement be useful to most users
There is no use-case in the demo-files, but it's likely to happen, once the smoke sensors get used more often.Arne GrafArne Grafhttps://gitlab.jsc.fz-juelich.de/jupedsim/jpscore/-/issues/301Restarting a simulation2019-04-12T13:14:52+02:00Ghost UserRestarting a simulationIt could be necessary to restart/continue a simulation after it has been finished or canceled.
Here is a idea which parameters are needed to restart the simulation:
* group id
* agent id
* location x, y, z
* velocity vx, vy
* fre...It could be necessary to restart/continue a simulation after it has been finished or canceled.
Here is a idea which parameters are needed to restart the simulation:
* group id
* agent id
* location x, y, z
* velocity vx, vy
* frequency (source)
* last frame = start frame
There can be a new trajectory file or the old one can be continued (maybe better).0.8.5https://gitlab.jsc.fz-juelich.de/jupedsim/jpscore/-/issues/312Restructure routing and direction strategy2019-04-12T15:25:28+02:00tobias schroedterRestructure routing and direction strategyRestructure routing and direction strategy:
* [ ] Allow each router with each direction strategy
* [ ] Add waiting behaviour (see #313 )Restructure routing and direction strategy:
* [ ] Allow each router with each direction strategy
* [ ] Add waiting behaviour (see #313 )0.8.6tobias schroedtertobias schroedterhttps://gitlab.jsc.fz-juelich.de/jupedsim/jpscore/-/issues/246Rimeatest 4 not working2018-06-13T16:41:29+02:00Tao ZhongRimeatest 4 not working## Relevant logs, files (inifile and geometry) and/or screenshots
```python
Traceback (most recent call last):
File "runtest_rimea_4.py", line 221, in <module>
test.run_test(testfunction=run_rimea_test4)
File "/Users/sainho93/Do...## Relevant logs, files (inifile and geometry) and/or screenshots
```python
Traceback (most recent call last):
File "runtest_rimea_4.py", line 221, in <module>
test.run_test(testfunction=run_rimea_test4)
File "/Users/sainho93/Documents/Repos/jpscore/Utest/JPSRunTest.py", line 77, in run_test
res = self.__execute_test(jpscore_exe, inifile, testfunction, *args)
File "/Users/sainho93/Documents/Repos/jpscore/Utest/JPSRunTest.py", line 228, in __execute_test
res = testfunction(inifile, trajfile, *args)
TypeError: run_rimea_test4() takes no arguments (2 given)
```Mohcine Chraibim.chraibi@fz-juelich.deMohcine Chraibim.chraibi@fz-juelich.dehttps://gitlab.jsc.fz-juelich.de/jupedsim/jpscore/-/issues/169Router behavior by "equivalent" doors2018-06-13T16:41:30+02:00Mohcine Chraibim.chraibi@fz-juelich.deRouter behavior by "equivalent" doors@all When we have two doors near each other the router delivers the nearest door. The other one is constantly ignored.
Sometimes this choice does not seem to be correct. See:
![](https://cst.version.fz-juelich.de/jupedsim/jpscore/upl...@all When we have two doors near each other the router delivers the nearest door. The other one is constantly ignored.
Sometimes this choice does not seem to be correct. See:
![](https://cst.version.fz-juelich.de/jupedsim/jpscore/uploads/1ce94146b7ca84c54b2d045ba224b1c6/Screen_Shot_2016-01-28_at_15.53.09.png)
-------------------------------
Now we can change the Hline before the two exits so that we can influence this behavior. That is the result
![animated](/uploads/5f39dc37736ac7b4ba1c8ad11f4186ff/animated.gif)https://gitlab.jsc.fz-juelich.de/jupedsim/jpscore/-/issues/235Router Test Suite2018-06-13T16:41:29+02:00Arne GrafRouter Test SuitePlease upload for every test:
- the inifile
- the geometry file
- a file describing the result in the following format
| Router *id* | Test *id* | Comments |
| ----------- | --------- | -------------|
---
## Test 1:
- Author: Ke...Please upload for every test:
- the inifile
- the geometry file
- a file describing the result in the following format
| Router *id* | Test *id* | Comments |
| ----------- | --------- | -------------|
---
## Test 1:
- Author: Kemloh und Löhner
- Inifile:
- geometry:[test1.zip](/uploads/72304756c14a816f2c6fe9568cf0ad64/test1.zip)
---
## Test 2:
- Author: Löhner
- Inifile:
- geometry:[test2.zip](/uploads/ebb317f5bfdad6d3f25d0c0b849c90e3/test2.zip)
---
## Test 3:
- Author: @gutt1
- Inifile: [ini_Test3.xml](/uploads/20a6f62d1e6b302d48467eb671a71aa2/ini_Test3.xml)
- geometry:[geo_Test3.xml](/uploads/1633894e52aa62bd48d7ac867d5f5b3e/geo_Test3.xml)
- results:[res_Test3.ods](/uploads/b63b83177290ebd2c7bab26bd35f39dd/res_Test3.ods)
---
## Test 4:
- Author: @zhong1
- Inifile: [ini_Test4.xml](/uploads/0e90f5ac6423d7ac777e5490d30ebeca/ini_Test4.xml)
- geometry: [geo_Test4.xml](/uploads/b59056b6d4cec267093c33254c1f959d/geo_Test4.xml)
- results: [router_test_results_Test4.md](/uploads/39cff571f5368da97477f2b213e88b8f/router_test_results_Test4.md)
---
## Test 5:
- Author: @zhong1
- Inifile: [ini_Test5.xml](/uploads/749244f0927c8af82afad54667263784/ini_Test5.xml)
- geometry: [geo_Test5.xml](/uploads/413b0ce2056f903f3c9c98f3b4c655b6/geo_Test5.xml)
- results: [router_test_results_Test5.md](/uploads/ee3fc5671e14c7228f4f68ebe731b115/router_test_results_Test5.md)
---
## Test 6:
- Author: Crociani
- Inifile:
- geometry:[test6.zip](/uploads/8891322ba46264555cdd35f920e5d428/test6.zip)
---
## Test 7:
- Author: von Sivers
- Inifile:
- geometry:[test7.zip](/uploads/f9536e77164b44ca657ee42dba89275c/test7.zip)
---
## Test 8:
- Author: @gutt1
- Inifile:[ini_Test8.xml](/uploads/59616e0083924e68904a05b3da04ed71/ini_Test8.xml)
- geometry:[geo_Test8.xml](/uploads/bde779483ec145d29452b617fff6f1e8/geo_Test8.xml)
- results:[res_Test8.ods](/uploads/eecdfe87ed686297af82d60201dc19fa/res_Test8.ods)
---Mohcine Chraibim.chraibi@fz-juelich.deMohcine Chraibim.chraibi@fz-juelich.de2017-03-04https://gitlab.jsc.fz-juelich.de/jupedsim/jpscore/-/issues/278Routing improvements2018-08-28T22:25:08+02:00benjamin moehringRouting improvements## include the z-component
#127 discusses different routers. Currently `global_shortest` seems to be state of the art. Heights aren't considered in the algorithm though which leads to unexpected behaviors like in the image below. Pedest...## include the z-component
#127 discusses different routers. Currently `global_shortest` seems to be state of the art. Heights aren't considered in the algorithm though which leads to unexpected behaviors like in the image below. Pedestrians inside the Alexanderplatz metro station take up to 14.4 additional meters in altitude and several stairs to save a few meters in xy-dimensions.
![image](/uploads/13407e13a82afa9e2c2347889201adf4/image.png)
This minimum example demonstrates the issue:
[jps_ini.xml](/uploads/fa122045c58c926f80f4493509458db2/jps_ini.xml)
[jps_traj.xml](/uploads/038941a1fc927b7679118323208a629c/jps_traj.xml)
[jps_geo.xml](/uploads/8ae6d162b0706102a0222f8324aa9d6d/jps_geo.xml)
Including z-dimensions when calculating the distance matrix would be a first step towards a more realistic representation of the tactical level.
## attribute-based factors
Additionally there are studies on route choices of pedestrians, which conclude in relative cost factors for rooms according to their attributes. https://www.witpress.com/Secure/elibrary/papers/CR06/CR06001FU1.pdf
I think it would make sense to take advantage of such studies and allow their usage. As a basic idea one could define factors related to the class attribute of subrooms like in the suggested inifile snippet below:
```xml
` <route_choice_models>
<router router_id="1" description="ff_global_shortest">
<parameters>
<factor class="stair" factor="1.5">
<factor class="escalator_up" factor="1.3">
<factor class="roofed" factor="0.9">
</parameters>-->
</router>
</route_choice_models>
```
## Why would the enhancement be useful to most users
More realistic representation of the tactical level. Local characteristics could be considered.https://gitlab.jsc.fz-juelich.de/jupedsim/jpscore/-/issues/163Runtime Bottleneck2018-03-16T15:00:26+01:00Mohcine Chraibim.chraibi@fz-juelich.deRuntime Bottleneck@chraibi @Arne
It seems we have in every model a method called
~~~.cpp
::ComputeNextTimeStep(double current, double deltaT, Building* building, int periodic)
~~~
What happens inside this method is:
~~~.cpp
for (int p = start; p <= end...@chraibi @Arne
It seems we have in every model a method called
~~~.cpp
::ComputeNextTimeStep(double current, double deltaT, Building* building, int periodic)
~~~
What happens inside this method is:
~~~.cpp
for (int p = start; p <= end; ++p) {
Pedestrian* ped = allPeds[p];
Room* room = building->GetRoom(ped->GetRoomID());
SubRoom* subroom = room->GetSubRoom(ped->GetSubRoomID());
...
for (int i = 0; i < size; i++) {
Pedestrian* ped1 = neighbours[i];
//if they are in the same subroom
...
bool isVisible = building->IsVisible(p1, p2, emptyVector, false);
if (!isVisible)
continue;
if (ped->GetUniqueRoomID() == ped1->GetUniqueRoomID()) {
repPed = repPed + ForceRepPed(ped, ped1);
} else {
// or in neighbour subrooms
SubRoom* sb2=building->GetRoom(ped1->GetRoomID())->GetSubRoom(ped1->GetSubRoomID());
if(subroom->IsDirectlyConnectedWith(sb2)) {
repPed = repPed + ForceRepPed(ped, ped1);
}
}
}
...
~~~
This basically means: First we calculate if a pedestrian is visible, which is pretty expensive (enormous expensive) and then we do the simple check if they are in the same room/subroom or neighbour subroom and if not we don't do any calculation.
This is wrong way round... we should first check if these Pedestrians need a force update because they influence each other than calculating if they can see each other through the sub roomhttps://gitlab.jsc.fz-juelich.de/jupedsim/jpscore/-/issues/306Schedule (for WAs)2019-07-01T11:01:01+02:00Ghost UserSchedule (for WAs)For reopening the waiting areas we need a schedule:
**schedule.xml***
```
<?xml version="1.0" encoding="UTF-8" ...?>
<JPScore project="JPS-Project" version="0.6" ...>
<groups>
<group id="1">
<member wa_id="1"/>
...For reopening the waiting areas we need a schedule:
**schedule.xml***
```
<?xml version="1.0" encoding="UTF-8" ...?>
<JPScore project="JPS-Project" version="0.6" ...>
<groups>
<group id="1">
<member wa_id="1"/>
<member wa_id="2"/>
<member wa_id="3"/>
</group>
<group id="2">
<member wa_id="4"/>
<member wa_id="5"/>
<member wa_id="6"/>
</group>
</groups>
<times>
<time group_id="1">
<t="60"/>
<t="120"/>
<t="350"/>
<t="800"/>
</time>
<time group_id="2">
<t="20"/>
<t="80"/>
<t="310"/>
<t="760"/>
<time/>
</times>
</JPScore>
```tobias schroedtertobias schroedterhttps://gitlab.jsc.fz-juelich.de/jupedsim/jpscore/-/issues/305Segmentation fault when using overlapping sources2019-04-15T15:11:32+02:00tobias schroedterSegmentation fault when using overlapping sources## Summary
When using overlapping sources in larger geometries the program fails with a Segmentation fault in the VelocityModel when accessing the position of the neighbors.
## Inifile + Geometry file to reproduce bug
[Personen_ini.xml...## Summary
When using overlapping sources in larger geometries the program fails with a Segmentation fault in the VelocityModel when accessing the position of the neighbors.
## Inifile + Geometry file to reproduce bug
[Personen_ini.xml](/uploads/a92b2f4f9efcd5e5af081dd82a0ba96f/Personen_ini.xml)
[Bahnsteige.xml](/uploads/8a9c8bfc24ae68bf3d264379216a6129/Bahnsteige.xml)https://gitlab.jsc.fz-juelich.de/jupedsim/jpscore/-/issues/219Segmentation Fault with router with defined Goals2018-06-13T16:41:32+02:00Mohcine Chraibim.chraibi@fz-juelich.deSegmentation Fault with router with defined GoalsUsing the following geometry
![Screen_Shot_2016-09-22_at_13.33.39](/uploads/696b032b2f8439a48a8dad809598bba5/Screen_Shot_2016-09-22_at_13.33.39.png)
with the following [inifile](/uploads/6359b037f90fe249989e9f9bb38cf739/inifile.xml) a...Using the following geometry
![Screen_Shot_2016-09-22_at_13.33.39](/uploads/696b032b2f8439a48a8dad809598bba5/Screen_Shot_2016-09-22_at_13.33.39.png)
with the following [inifile](/uploads/6359b037f90fe249989e9f9bb38cf739/inifile.xml) and [geometry](/uploads/1c882c4c28a7346afdc0ecc5bbcabeeb/xiao_geometry.xml) files with **the global router**
lead to "no route to destination" errors
![Screen_Shot_2016-09-22_at_13.36.48](/uploads/31f7c49502ced40d873f54c4e7e7a1c7/Screen_Shot_2016-09-22_at_13.36.48.png)
With the combo **FFrouter+ Strategy 9** leads to "out of bound error" + sporadic SegFaults.
![Screen_Shot_2016-09-22_at_13.38.18](/uploads/94feb6fbba0c612cd6f0fcc469d0b187/Screen_Shot_2016-09-22_at_13.38.18.png)
**Note** without specifying the attribute `goal_id` the simulation runs without problems. For the FF-router some oscillations are visible, though.Arne GrafArne Grafhttps://gitlab.jsc.fz-juelich.de/jupedsim/jpscore/-/issues/315Separation of pedestrian flows2019-05-11T00:40:21+02:00Ghost UserSeparation of pedestrian flowsFor our lecture "Evakuierungssimulation" we have an exercise to investigate the separation of pedestrian flows.
The result should be: evacuation-time variation a > evacuation-time variation b.
In the last lectures (SoSe 2018) the resu...For our lecture "Evakuierungssimulation" we have an exercise to investigate the separation of pedestrian flows.
The result should be: evacuation-time variation a > evacuation-time variation b.
In the last lectures (SoSe 2018) the results were as expected. When I rerunned the simulations for the current lectures (SoSe 2019) the result was totally different (with the same ini-file)! See the attached plots.
[Raum_2_a.xml](/uploads/165c5c314ffd73724dc32cbeb75a8f2f/Raum_2_a.xml)
[Raum_2_b.xml](/uploads/e26e39a7e2a69ccf4592c7cc597a4d4a/Raum_2_b.xml)
[Aufgabe4a_ini.xml](/uploads/e9b1edc57fbaee75fa1874429a0fc0eb/Aufgabe4a_ini.xml)
[Aufgabe4b_ini.xml](/uploads/47e8d7612162be80331d42389a69dd61/Aufgabe4b_ini.xml)
![Plot_Aufgabe4-alt](/uploads/fd276025b018d54994c98969223ab336/Plot_Aufgabe4-alt.png)
![Plot_Aufgabe4-neu](/uploads/52a615a20b75eaf14f5c4085cb70b7fc/Plot_Aufgabe4-neu.png)Mohcine Chraibim.chraibi@fz-juelich.deMohcine Chraibim.chraibi@fz-juelich.dehttps://gitlab.jsc.fz-juelich.de/jupedsim/jpscore/-/issues/256Simulation with different groups2017-11-02T16:41:18+01:00Ghost UserSimulation with different groupsSimulation with disabled peoples on stairs, which couldn't go downstairs.
* Group1 - non disabled people can go downstairs -> shortest way, so they go down
* Group2 - disabled people can't go downstairs -> wait on stairs until timeoutSimulation with disabled peoples on stairs, which couldn't go downstairs.
* Group1 - non disabled people can go downstairs -> shortest way, so they go down
* Group2 - disabled people can't go downstairs -> wait on stairs until timeouthttps://gitlab.jsc.fz-juelich.de/jupedsim/jpscore/-/issues/259Smoke Cue Model2018-06-13T16:41:34+02:00Mohcine Chraibim.chraibi@fz-juelich.deSmoke Cue Model## Short description of suggestion
- User defines a pre-movement time (e.g. 120 s)
- + detection time (e.g. 60s)
That means: the occupant remains in that position for 180 s regardless the occurrence of smoke or temperature.
It would b...## Short description of suggestion
- User defines a pre-movement time (e.g. 120 s)
- + detection time (e.g. 60s)
That means: the occupant remains in that position for 180 s regardless the occurrence of smoke or temperature.
It would be good if we can implement a function in the model that changes the pre-movement time of the occupant to 0 when the visibility drops to 10 m.
## Why would the enhancement be useful to most users
In this way, no weird results are obtained regarding people waiting in the smokeBen HeinBen Heinhttps://gitlab.jsc.fz-juelich.de/jupedsim/jpscore/-/issues/283Stair in the middle of a (sub)room -> hole for stairs2019-05-10T20:11:52+02:00Ghost UserStair in the middle of a (sub)room -> hole for stairsDefining a (sub)room or a hole in the middle of an other (sub)room for a stair, without subdividing the second (sub)room in more (sub)rooms.
![Grundriss+Treppe](/uploads/58e4fa02fb331410c991954851531040/Grundriss+Treppe.png)
![Schnitt_...Defining a (sub)room or a hole in the middle of an other (sub)room for a stair, without subdividing the second (sub)room in more (sub)rooms.
![Grundriss+Treppe](/uploads/58e4fa02fb331410c991954851531040/Grundriss+Treppe.png)
![Schnitt_Treppe](/uploads/54fccbe897a47b57bee9cd46613ad004/Schnitt_Treppe.png)0.8.5Tao ZhongTao Zhonghttps://gitlab.jsc.fz-juelich.de/jupedsim/jpscore/-/issues/42Static route assignement2018-06-13T16:41:45+02:00Mohcine Chraibim.chraibi@fz-juelich.deStatic route assignementDefine a static route (escape route) pedestrians should follow.Define a static route (escape route) pedestrians should follow.https://gitlab.jsc.fz-juelich.de/jupedsim/jpscore/-/issues/331statistical distributions2019-06-24T19:37:53+02:00Ghost Userstatistical distributionsAt the moment, the pre-movement time is Gauss-distributed. The agent parameters are also.
I suggest that we implement more statistical distributions (for agent velocity and pre-movement time):
- no distribution
- uniform (min and max)...At the moment, the pre-movement time is Gauss-distributed. The agent parameters are also.
I suggest that we implement more statistical distributions (for agent velocity and pre-movement time):
- no distribution
- uniform (min and max)
- truncated normal (min, max, mean, sigma)
- normal (mean, sigma) - already exists
- triangular (min, max, mean)
- log-normal (min, max, mean, sigma, sigma_2)https://gitlab.jsc.fz-juelich.de/jupedsim/jpscore/-/issues/215Store the result of dynamic_cast, if it is needed again2017-08-31T17:24:32+02:00Mohcine Chraibim.chraibi@fz-juelich.deStore the result of dynamic_cast, if it is needed againhttps://gitlab.jsc.fz-juelich.de/jupedsim/jpscore/-/issues/218Thread safety of Router::FindExit()2017-08-31T17:24:32+02:00Mohcine Chraibim.chraibi@fz-juelich.deThread safety of Router::FindExit()In `Simulation::UpdateRoutesAndLocations()` (which calls `Pedestrian::FindRoute()`), `Router::FindExit()` is called without an `omp critical` construct, implying it is thread safe.
However, in `Pedestrian::Relocate()`, the call to `Rout...In `Simulation::UpdateRoutesAndLocations()` (which calls `Pedestrian::FindRoute()`), `Router::FindExit()` is called without an `omp critical` construct, implying it is thread safe.
However, in `Pedestrian::Relocate()`, the call to `Router::FindExit()` is inside a critical construct.
Either the critical construct is unnecessary (if all routers are thread safe) or it is missing in `Pedestrain::FindRoute()`.
This holds for the latest version at the time of writing (e9aeb106, I believe).https://gitlab.jsc.fz-juelich.de/jupedsim/jpscore/-/issues/114time out for the grpc calls2018-06-13T16:41:46+02:00Mohcine Chraibim.chraibi@fz-juelich.detime out for the grpc callsThe programm should restart itself after a timeout during the grpc call when runnign in server modeThe programm should restart itself after a timeout during the grpc call when runnign in server mode