JPScore issueshttps://gitlab.jsc.fz-juelich.de/jupedsim/jpscore/-/issues2019-05-10T15:35:32+02:00https://gitlab.jsc.fz-juelich.de/jupedsim/jpscore/-/issues/317Logger2019-05-10T15:35:32+02:00tobias schroedterLoggerIssue for collecting ideas for logging librariesIssue for collecting ideas for logging librarieshttps://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/236Curve in Voronoi diagram2017-08-31T17:24:31+02:00Yao XiaoCurve in Voronoi diagramIn library boost Voronoi, how to get the curve of Voronoi edge in a Voronoi diagram including segments. And how to cut off the curve by geometry.
![issue](/uploads/7fd710ff9d6bbcd74b5a96d7705cf527/issue.png)In library boost Voronoi, how to get the curve of Voronoi edge in a Voronoi diagram including segments. And how to cut off the curve by geometry.
![issue](/uploads/7fd710ff9d6bbcd74b5a96d7705cf527/issue.png)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/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/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/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/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/92Check for negative inputs for (unsigned) parameters2018-03-16T15:00:26+01:00Mohcine Chraibim.chraibi@fz-juelich.deCheck for negative inputs for (unsigned) parametersShould we assume the user gives correct input or should there be an exception thrown for negative input for variables like height?
// Obstacle.cpp
void Obstacle::SetHeight(double height)
{
_height = height;
}Should we assume the user gives correct input or should there be an exception thrown for negative input for variables like height?
// Obstacle.cpp
void Obstacle::SetHeight(double height)
{
_height = height;
}https://gitlab.jsc.fz-juelich.de/jupedsim/jpscore/-/issues/90Tolerance setting for creating a Geometry2018-06-13T16:41:45+02:00Mohcine Chraibim.chraibi@fz-juelich.deTolerance setting for creating a GeometryWhile creating a Line (which is used in many places like exit line, wall etc), there is no check for the minimum distance between two points. There can be situations where Point P1(0,10) & Point P2(1E-5, 10). Would this create an issue f...While creating a Line (which is used in many places like exit line, wall etc), there is no check for the minimum distance between two points. There can be situations where Point P1(0,10) & Point P2(1E-5, 10). Would this create an issue for future/current implementations? In commercial CAD tools they use a minimum eps value below which any distance is considered as zero. Should there be a tolerance level check implemented for the Geometry creation?https://gitlab.jsc.fz-juelich.de/jupedsim/jpscore/-/issues/50Merge crossing and transitions2018-06-13T16:41:45+02:00Mohcine Chraibim.chraibi@fz-juelich.deMerge crossing and transitionsMerge crossing and transitions as a geometry simplification step.Merge crossing and transitions as a geometry simplification step.