JPScore issueshttps://gitlab.jsc.fz-juelich.de/jupedsim/jpscore/-/issues2018-06-13T16:41:46+02:00https://gitlab.jsc.fz-juelich.de/jupedsim/jpscore/-/issues/150JPSrunTest2018-06-13T16:41:46+02:00Mohcine Chraibim.chraibi@fz-juelich.deJPSrunTestshould look for jpsreport in the system directory. Important for jenkins.should look for jpsreport in the system directory. Important for jenkins.Mohcine Chraibim.chraibi@fz-juelich.deMohcine Chraibim.chraibi@fz-juelich.dehttps://gitlab.jsc.fz-juelich.de/jupedsim/jpscore/-/issues/156ORCA Model Exit strategy sensitivity2018-06-13T16:41:48+02:00Mohcine Chraibim.chraibi@fz-juelich.deORCA Model Exit strategy sensitivityThe ORCA model seems to be sensitive to the exit strategy as the preferred velocity is obtained from the exit point. At the moment the code works fine only for exit strategy 1 (tested using turning at corner model). It fails for other ex...The ORCA model seems to be sensitive to the exit strategy as the preferred velocity is obtained from the exit point. At the moment the code works fine only for exit strategy 1 (tested using turning at corner model). It fails for other exit strategies. Has anyone faced a similar issue in other models? @OSchmidts @chraibi @ArneMohcine Chraibim.chraibi@fz-juelich.deMohcine Chraibim.chraibi@fz-juelich.dehttps://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/164LC is 2D!!2018-06-13T16:41:30+02:00Mohcine Chraibim.chraibi@fz-juelich.deLC is 2D!!In 3D rooms pedestrians in different levels, which are obviously not neighbors will be recognized as such.
Example: Ped1 (0, 0, 10), ped2 (0, 1, 0) are considered by the LC-Algorithm as neighbors.
(but they are not).
See also screensho...In 3D rooms pedestrians in different levels, which are obviously not neighbors will be recognized as such.
Example: Ped1 (0, 0, 10), ped2 (0, 1, 0) are considered by the LC-Algorithm as neighbors.
(but they are not).
See also screenshot in #161https://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/170Pedestrian left room/subroom in an unusual way2018-06-13T16:41:49+02:00Mohcine Chraibim.chraibi@fz-juelich.dePedestrian left room/subroom in an unusual wayThis is not an error, but it might happen, that a pedestrian can change its room/subroom from
an intended door.
Hier an example:
- Pedestrians have door 1225 (right) as a goal, because this is the global_shortest way.
- However sinc...This is not an error, but it might happen, that a pedestrian can change its room/subroom from
an intended door.
Hier an example:
- Pedestrians have door 1225 (right) as a goal, because this is the global_shortest way.
- However since door 1224 (left) does no effect pedestrians, they may cross this door, which leads to the *error*..
`How can we solve this?`
- Ignore the error?
- Close all doors other than my door?
- ....
![animated](/uploads/dcadd8891434eb746d27b9bf6f2b1c28/animated.gif)
@OSchmidts @kemloh @Arne @robhttps://gitlab.jsc.fz-juelich.de/jupedsim/jpscore/-/issues/172Quickest Path - circling agents - no path to exit2018-06-13T16:41:30+02:00Mohcine Chraibim.chraibi@fz-juelich.deQuickest Path - circling agents - no path to exitstrange agent behavior by using quickest path.
will try to fix it with Hlines.
- [cyrcling_agents_m1.mp4](/uploads/90337eefd1e2488f2400d5f3109a7036/cyrcling_agents_m1.mp4)
- [cyrcling_agents_m2.mp4](/uploads/ca1558fbdf550e50634e868fd4...strange agent behavior by using quickest path.
will try to fix it with Hlines.
- [cyrcling_agents_m1.mp4](/uploads/90337eefd1e2488f2400d5f3109a7036/cyrcling_agents_m1.mp4)
- [cyrcling_agents_m2.mp4](/uploads/ca1558fbdf550e50634e868fd40e478d/cyrcling_agents_m2.mp4)
- [circling_agents_files.rar](/uploads/1f95a6845bde8b134df50f309f44eb90/circling_agents_files.rar)Arne GrafArne Grafhttps://gitlab.jsc.fz-juelich.de/jupedsim/jpscore/-/issues/173Pedestrians are too near to each other - simulation stopped - Quickest Path2018-06-13T16:41:30+02:00Mohcine Chraibim.chraibi@fz-juelich.dePedestrians are too near to each other - simulation stopped - Quickest PathWarning: in velocityModel
pedestrians are to near to ech other.
room "9" ; subroom "10"
[Ped_to_near.mp4](/uploads/94dad243a57b1e81082a5fa60a4e9599/Ped_to_near.mp4)
[sim_stop_quickest.rar](/uploads/781fd950a542c6d94d430917c2b59a68/sim_...Warning: in velocityModel
pedestrians are to near to ech other.
room "9" ; subroom "10"
[Ped_to_near.mp4](/uploads/94dad243a57b1e81082a5fa60a4e9599/Ped_to_near.mp4)
[sim_stop_quickest.rar](/uploads/781fd950a542c6d94d430917c2b59a68/sim_stop_quickest.rar)
![sim_stop_quickest](/uploads/14285ad61dbb6ebc0b5df4ddef20517b/sim_stop_quickest.jpg)Mohcine Chraibim.chraibi@fz-juelich.deMohcine Chraibim.chraibi@fz-juelich.dehttps://gitlab.jsc.fz-juelich.de/jupedsim/jpscore/-/issues/182Discussion: Should we put all asserts, outputs and robustness-checks in #ifde...2018-03-16T15:00:26+01:00Mohcine Chraibim.chraibi@fz-juelich.deDiscussion: Should we put all asserts, outputs and robustness-checks in #ifdef DEBUG ... #endif blocksHey everyone,
I was thinking about the complexity of jpscore and all the stuff that is logged, bound-checked and stuff:
Some of that is done because of **good** defensive programming style, some is done to track the program or to find ...Hey everyone,
I was thinking about the complexity of jpscore and all the stuff that is logged, bound-checked and stuff:
Some of that is done because of **good** defensive programming style, some is done to track the program or to find bugs, etc..
I would like to ask you all, if we want to define one or two macros for conditional compilation (like **DEBUG** and/or **VERBOSE**, **ASSERT**) to but those checks, outputs and stuff in additional compilations and have a raw, fast compilation without all of them, once we verified the correctness of the program.
Example: While programming the ffRouter, I deal with several floor-fields (one for each room). If I query a direction and one of the two arguments (pedestrian, goal) is outside the floor-field, the result will be devastating (most likely a segfault).
So I do check in each query, if both arguments are valid. This will slow down the program. Once I know, the program-logic is correct, I could remove most of the checks - (at least most of the debug-output).
It is a (controversial) technique, to put those parts of a program in conditional blocks (``#ifdef KEYWORD``). What do you think about that?https://gitlab.jsc.fz-juelich.de/jupedsim/jpscore/-/issues/183GOALS are not 3d proof2018-03-16T15:00:26+01:00Mohcine Chraibim.chraibi@fz-juelich.deGOALS are not 3d proofgoals are defined without a z-coordinate.
As long as they are outside, we can assume, they are well-defined. Are goals allowed to be inside a building? (I think, they are. At least the program checks, if a pedestrian reached its goal ev...goals are defined without a z-coordinate.
As long as they are outside, we can assume, they are well-defined. Are goals allowed to be inside a building? (I think, they are. At least the program checks, if a pedestrian reached its goal even if he is inside.)
If so, we need to talk about that.https://gitlab.jsc.fz-juelich.de/jupedsim/jpscore/-/issues/184Quickest - Router: Suggestions on how to tackle problem2018-03-16T15:00:26+01:00Mohcine Chraibim.chraibi@fz-juelich.deQuickest - Router: Suggestions on how to tackle problem## Task ##
Inside of a room: Estimated Time of Arrival to a door, based on traffic/queues
## Current Solution (rough) ##
- searching for alternate routes
- searching for pedestrians in that room in front of alternate doors
- calc ETA
- ...## Task ##
Inside of a room: Estimated Time of Arrival to a door, based on traffic/queues
## Current Solution (rough) ##
- searching for alternate routes
- searching for pedestrians in that room in front of alternate doors
- calc ETA
- calc if current agent can break out of queue or is stuck inside
- change destination if possible
## Suggestion ##
- create a temp polygon of (ped-Pos, Door-Point-a, Door-Point-b)
- find other pedestrian that are inside polygon
- calc ETA from mean speed
### Pro ###
- using existing functions
- length of possible queue is respected
- similar to current solution
### Con ###
- calculation time grows with n^2+ (peds)
- similar to current solution
## Suggestion ##
- pedestrian have a counter
- pedestrian counter is reset when spawning or entering a new room
- while passing a door, the current counter (time-in-old-room) is stored as door-member
- estimate ETA by asking the door for last value of (time-in-old-room) of the ped that exited last
### Pro ###
- calculation does not grow with n^2
### Con ###
- last in queue will give door a bad rating, although queue is not there anymore.. (could be solved via door-member being a "soft"-state, that will reset after a few seconds)
**Please comment and/or post other Suggestions**https://gitlab.jsc.fz-juelich.de/jupedsim/jpscore/-/issues/185height of obstacles2018-03-16T15:00:26+01:00Mohcine Chraibim.chraibi@fz-juelich.deheight of obstaclesI am asking me the question if we could not define a height of obstacles.
Suppose we have an obstacle with a height of 1m (table). The obstacle will have an influence on the motion but not on the routing of an agent.
Maybe we could skip...I am asking me the question if we could not define a height of obstacles.
Suppose we have an obstacle with a height of 1m (table). The obstacle will have an influence on the motion but not on the routing of an agent.
Maybe we could skip these obstacles (up to a specific height) when the graph is set up?
This would avoid a lot of trouble with stuck agents in the most cases...Mohcine Chraibim.chraibi@fz-juelich.deMohcine Chraibim.chraibi@fz-juelich.dehttps://gitlab.jsc.fz-juelich.de/jupedsim/jpscore/-/issues/189CppCheck2018-06-13T16:41:31+02:00Mohcine Chraibim.chraibi@fz-juelich.deCppCheckSomehow the trend is going in the wrong direction
![Screen_Shot_2016-05-03_at_14.45.15](/uploads/108cc6ea60f691a96d16b760fd0a37bf/Screen_Shot_2016-05-03_at_14.45.15.png)
Can somebody try to inverse this trend? :confused:Somehow the trend is going in the wrong direction
![Screen_Shot_2016-05-03_at_14.45.15](/uploads/108cc6ea60f691a96d16b760fd0a37bf/Screen_Shot_2016-05-03_at_14.45.15.png)
Can somebody try to inverse this trend? :confused:https://gitlab.jsc.fz-juelich.de/jupedsim/jpscore/-/issues/206Reduce execution time of tests2019-03-23T05:00:38+01:00Mohcine Chraibim.chraibi@fz-juelich.deReduce execution time of tests- juelich 11 (136.13 s)
- juelich 13 (1321.74 s)
- juelich_14 (1493 s)
- juelich 6 (372 s)
- juelich 8 (147 s)
- Rimea 9 (192 s)
- Rimea 13 (1570 s)- juelich 11 (136.13 s)
- juelich 13 (1321.74 s)
- juelich_14 (1493 s)
- juelich 6 (372 s)
- juelich 8 (147 s)
- Rimea 9 (192 s)
- Rimea 13 (1570 s)guido bastenguido basten2016-12-24https://gitlab.jsc.fz-juelich.de/jupedsim/jpscore/-/issues/210Cleanup the used random generators2018-03-16T15:00:26+01:00Mohcine Chraibim.chraibi@fz-juelich.deCleanup the used random generatorsThe random engine should be initialized once (with seed).
prefer `std::mersenne_twister_engine`.The random engine should be initialized once (with seed).
prefer `std::mersenne_twister_engine`.https://gitlab.jsc.fz-juelich.de/jupedsim/jpscore/-/issues/213Name omp critical constructs2017-08-31T17:24:32+02:00Mohcine Chraibim.chraibi@fz-juelich.deName omp critical constructshttps://gitlab.jsc.fz-juelich.de/jupedsim/jpscore/-/issues/214Use enums instead of bare integers2017-08-31T17:24:32+02:00Mohcine Chraibim.chraibi@fz-juelich.deUse enums instead of bare integersThis should make the code easier to read. Add to the list if you find any.
flags used in the floorfieldThis should make the code easier to read. Add to the list if you find any.
flags used in the floorfieldhttps://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/216Agents with different models2018-06-13T16:41:32+02:00Mohcine Chraibim.chraibi@fz-juelich.deAgents with different modelsSupply different pedestrian `groups` with different (operational) models, in order to compare within one single simulation different models.Supply different pedestrian `groups` with different (operational) models, in order to compare within one single simulation different models.https://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).