JPScore issueshttps://gitlab.jsc.fz-juelich.de/jupedsim/jpscore/-/issues2019-06-25T16:54:45+02:00https://gitlab.jsc.fz-juelich.de/jupedsim/jpscore/-/issues/287Waiting areas2019-06-25T16:54:45+02:00Ghost UserWaiting areasIn order to simulate the transition from a platform edge to a train, waiting areas should be defined in front of the doors (transitions), for example, areas where only a certain number of people can stand.In order to simulate the transition from a platform edge to a train, waiting areas should be defined in front of the doors (transitions), for example, areas where only a certain number of people can stand.tobias schroedtertobias schroedterhttps://gitlab.jsc.fz-juelich.de/jupedsim/jpscore/-/issues/280Clipping2018-09-18T14:21:21+02:00Mohcine Chraibim.chraibi@fz-juelich.deClippingClipping
(more later..)Clipping
(more later..)https://gitlab.jsc.fz-juelich.de/jupedsim/jpscore/-/issues/332JURECA | header, logfile2019-07-04T08:06:58+02:00Ghost UserJURECA | header, logfile**jpscore**:
```
JuPedSim - JPScore
Current date : Jul 2 2019 19:07:41
Version : 0.8.4
Commit hash : v0.8.4-68-ga33375a
Commit date : Mon Jul 1 15:21:05 2019
Branch : develop
----
```
**inifile** in `/data`:
...**jpscore**:
```
JuPedSim - JPScore
Current date : Jul 2 2019 19:07:41
Version : 0.8.4
Commit hash : v0.8.4-68-ga33375a
Commit date : Mon Jul 1 15:21:05 2019
Branch : develop
----
```
**inifile** in `/data`:
```xml
<header>
<seed>4313</seed>
<max_sim_time>80</max_sim_time>
<num_threads>48</num_threads>
<show_statistics>true</show_statistics>
<logfile>log_RiMEA_Test_04_7-0_om_2</logfile>
<!--<progressbar/>-->
<trajectories format="plain" fps="2">
<file location="traj_RiMEA_Test_04_7-0_om_2.txt" />
</trajectories>
<geometry>geo_RiMEA_Test_04.xml</geometry>
</header>
...
```
**batch_script** in `$HOME`:
```batch
#!/bin/bash -x
#SBATCH -J R70
#SBATCH --account=ias-7
#SBATCH --nodes=1
#SBATCH --ntasks=1
#SBATCH --cpus-per-task=48
#SBATCH --output=data/out_%j.txt
#SBATCH --error=data/err_%j.txt
#SBATCH --time=6:00:00
#SBATCH --mail-user=g.jaeger@fz-juelich.de
#SBATCH --mail-type=ALL
export OMP_NUM_THREADS=${SLURM_CPUS_PER_TASK}
srun ./jpscore/bin/jpscore data/ini_RiMEA_Test_04_7-0_om_2.xml
```
The logfile is stored in the root directory (`$HOME`) as `datalog_RiMEA_Test_04_7-0_om_2.txt`. Also the statistic files are stored there.
Both files should be stored in the directory `data` (like the trajectory files).
**Note**:
The function `<progressbar/>` creates a very large file (5-15 GB) and should be disabled.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/325inifile, header2019-06-24T09:30:40+02:00Ghost Userinifile, headerThe simulation *RiMEA_Test_04_0-5* does not run with `<header>` as described in the [documentation](http://www.jupedsim.org/jpscore/2016-11-01-inifile).
[ini_RiMEA_Test_04_0-5.xml](/uploads/34bb482701018f085dfb6f803c49eeb1/ini_RiMEA_Tes...The simulation *RiMEA_Test_04_0-5* does not run with `<header>` as described in the [documentation](http://www.jupedsim.org/jpscore/2016-11-01-inifile).
[ini_RiMEA_Test_04_0-5.xml](/uploads/34bb482701018f085dfb6f803c49eeb1/ini_RiMEA_Test_04_0-5.xml)
[geo_RiMEA_Test_04.xml](/uploads/4fd1cb5dc22914899a3045e653a28593/geo_RiMEA_Test_04.xml)https://gitlab.jsc.fz-juelich.de/jupedsim/jpscore/-/issues/324Print Statistics2019-07-17T06:19:29+02:00Ghost UserPrint Statisticsfrom [Simulation.cpp, line 417 ff](https://gitlab.version.fz-juelich.de/jupedsim/jpscore/blob/develop/Simulation.cpp):
```c++
void Simulation::PrintStatistics(double simTime)
for (const auto& itr : _building->GetAllTransitions()) {
...from [Simulation.cpp, line 417 ff](https://gitlab.version.fz-juelich.de/jupedsim/jpscore/blob/develop/Simulation.cpp):
```c++
void Simulation::PrintStatistics(double simTime)
for (const auto& itr : _building->GetAllTransitions()) {
Transition* goal = itr.second;
if (goal->GetDoorUsage()) {
Log->Write(
"\nExit ID [%d] used by [%d] pedestrians. Last passing time [%0.2f] s",
goal->GetID(), goal->GetDoorUsage(),
goal->GetLastPassingTime());
string statsfile = "flow_exit_id_"+to_string(goal->GetID())+".txt";
if(goal->GetOutflowRate() < (std::numeric_limits<double>::max)())
{
char tmp[50];
sprintf(tmp, "%.2f", goal->GetOutflowRate());
statsfile = "flow_exit_id_"+to_string(goal->GetID())+"_rate_"+tmp+".txt";
}
Log->Write("More Information in the file: %s", statsfile.c_str());
{
auto statOutput = new FileHandler(statsfile.c_str());
statOutput->Write("#Simulation time: %.2f", simTime);
statOutput->Write("#Flow at exit "+goal->GetCaption()+"( ID "+to_string(goal->GetID())+" )");
statOutput->Write("#Time (s) cummulative number of agents \n");
statOutput->Write(goal->GetFlowCurve());
statOutput->FileHandler::~FileHandler();
}
}
}
```
Can we change the filename `flow_exit_id_` in line [430](https://gitlab.version.fz-juelich.de/jupedsim/jpscore/blob/develop/Simulation.cpp#L430) like the trajectory filename (e.g. `flow_exit_id_filename.txt`?https://gitlab.jsc.fz-juelich.de/jupedsim/jpscore/-/issues/320One-sided closed doors2019-05-19T10:50:03+02:00tobias schroedterOne-sided closed doorsAllows to pedestrian to go through in one direction but is (temp) closed from the other direction.Allows to pedestrian to go through in one direction but is (temp) closed from the other direction.tobias schroedtertobias schroedterhttps://gitlab.jsc.fz-juelich.de/jupedsim/jpscore/-/issues/319malloc_error_break2019-05-11T18:02:05+02:00Ghost Usermalloc_error_breakThe error of issue #316 is gone, but there is another error, now...
![Bildschirmfoto_2019-05-11_um_17.39.04](/uploads/a715b6ac39de47efd527de0aaef42db4/Bildschirmfoto_2019-05-11_um_17.39.04.png)
[correct_Bahnsteige.xml](/uploads/bfb68e5...The error of issue #316 is gone, but there is another error, now...
![Bildschirmfoto_2019-05-11_um_17.39.04](/uploads/a715b6ac39de47efd527de0aaef42db4/Bildschirmfoto_2019-05-11_um_17.39.04.png)
[correct_Bahnsteige.xml](/uploads/bfb68e52ecd861ba2ea16efd02a2e33b/correct_Bahnsteige.xml)
[log-goal.txt](/uploads/2e71bfd86980ea60c03f89cda3d96d45/log-goal.txt)
[Personen_ini.xml](/uploads/26c7559ed1e1b4e2695fcad5685ec12b/Personen_ini.xml)
I do another simulation to see if the error occurs again.
For the small setup (Aufgabe6 - #316) there is no problem anymore.Mohcine Chraibim.chraibi@fz-juelich.deMohcine Chraibim.chraibi@fz-juelich.dehttps://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/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/279wall makes goal unreachable2018-08-28T23:08:27+02:00benjamin moehringwall makes goal unreachable## Summary
I produced a basic example of two almost similar geometries with subrooms on two levels. The only difference is that in geometry A, a wall is placed between an exit transition and the goal on a different level of the building...## Summary
I produced a basic example of two almost similar geometries with subrooms on two levels. The only difference is that in geometry A, a wall is placed between an exit transition and the goal on a different level of the building. In geometry B this wall was moved elsewhere.
It seems that because of this wall pedestrians can't reach their goal in geometry A, where as they do find a route in geometry B.
## Steps to reproduce
Run or visualize the provided examples.
## Expected behavior
Pedestrian leaves the building in both geometries.
## Actual behavior
pedestrian leaves the building in geometry B.
pedestrian doesn't find a route in geometry A.
> ERROR: ffRouter: unknown/unreachable goalID: 2 in FindExit(Ped)
> ERROR: VelocityModel::Init() cannot initialise route. ped 1 is deleted in Room 1 4.
## Inifile + Geometry + logs file to reproduce bug
Example A (not working):
[jps_traj.xml](/uploads/929d8acea156c9522a54b38b45bf0e7e/jps_traj.xml)
[jps_log.txt](/uploads/76bb932d56621b456a1825c876a6aad4/jps_log.txt)
[jps_ini.xml](/uploads/8f71afa7be16a5c0070c9999ab34bb86/jps_ini.xml)
[jps_geo.xml](/uploads/cb21d1b0ec28ed41f498e60008723f24/jps_geo.xml)
Example B (working)
[jps_log.txt](/uploads/2433af95a0047f7f786df0c3d9920346/jps_log.txt)
[jps_traj.xml](/uploads/5d2189b81a30f61671065e6eb8a33714/jps_traj.xml)
[jps_ini.xml](/uploads/e0005dcdc4484e778668ad3da49af928/jps_ini.xml)
[jps_geo.xml](/uploads/6cff9b78492d26d01689fe3631534a28/jps_geo.xml)https://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/274malloc(): smallbin double linked list corrupted2018-05-10T12:16:34+02:00benjamin moehringmalloc(): smallbin double linked list corrupted## Summary
Dear all, I am receiving an error in jpscore running the large Alexanderplatz simulation on branch escalator. It happens after 1980 seconds (33 Minutes) of evac_time. Any ideas about this?
## Backtrace
*** Error in `./jpsco...## Summary
Dear all, I am receiving an error in jpscore running the large Alexanderplatz simulation on branch escalator. It happens after 1980 seconds (33 Minutes) of evac_time. Any ideas about this?
## Backtrace
*** Error in `./jpscore': malloc(): smallbin double linked list corrupted: 0x0000000003244f00 ***
[backtrace.txt](/uploads/0c1c581e15136877645e4adadffa545e/backtrace.txt)
## Inifile + Geometry file to reproduce bug
[jps_geo.xml](/uploads/44c7db6cdcfc8eeb139722df2ae2c903/jps_geo.xml)
[jps_ini.xml](/uploads/cd47f5cdc6779ef93dd5f502bba75ded/jps_ini.xml)
## Relevant logs, files (inifile and geometry) and/or screenshots
[jps_log.P0.dat](/uploads/b4f43897806e544664d3a8ac31143a6d/jps_log.P0.dat)https://gitlab.jsc.fz-juelich.de/jupedsim/jpscore/-/issues/267Pedestrians get in shapes2018-06-13T16:41:34+02:00Mohcine Chraibim.chraibi@fz-juelich.dePedestrians get in shapes## Short description of suggestion
The default shape of agents is `ellipse`.
In some models, the ellipse' semi-axes are chosen in a way, that we can even simulate *indirectly* `circles`.
It should be important to make proper (distan...## Short description of suggestion
The default shape of agents is `ellipse`.
In some models, the ellipse' semi-axes are chosen in a way, that we can even simulate *indirectly* `circles`.
It should be important to make proper (distance)calculations based on the agent's shape.
## Why would the enhancement be useful
The "hack" explained above comes at cost: Ellipse-calculations are expensive. So even, if the agents are circles, still expensive ellipse-functions e.g. for distance calculations are called.
Besides, it is important to be able to compare in a reproducible way the different possible shapes.
## How?
I suggest to introduce a class `shape`. Every agent *has* a `shape`. From this class derive two classes:
- `ellipse`
- `circles`
Other sub-classes can follow.tobias schroedtertobias schroedterhttps://gitlab.jsc.fz-juelich.de/jupedsim/jpscore/-/issues/261osm-convert: creating geometries from open data2018-01-19T15:00:01+01:00benjamin moehringosm-convert: creating geometries from open data## Short description of suggestion
Hello, I am currently developing a tool to convert openstreetmap data into jps-readable geometry.xml files.
You can check out the current version of my python code from https://github.com/bsmoehring/jps...## Short description of suggestion
Hello, I am currently developing a tool to convert openstreetmap data into jps-readable geometry.xml files.
You can check out the current version of my python code from https://github.com/bsmoehring/jpsTools
To be honest the code might still be unhandy for someone who didn't write it. But I provided some example datasets in https://github.com/bsmoehring/jpsTools/tree/master/jpsTools/osmImport/resources
## Why would the enhancement be useful to most users
I believe that the power of jps will be accessible for way more users as soon as required data such as the geometry file can be easily converted from third party data sources. In addition the JOSM-Editor, which I find quite useful, provides well maintained and user-friendly editing tools based on vertices, just like jps.
If anyone is interested in what I#m doing, fell free to contact me. I'd be honored if it might someday help some users creating geometry files. Since my usecase are train stations, the code and especially the input parameters are very likely not well supporting other areas for now. If you're facing problems, let me know.https://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/257ellipse size of wheelchair user2017-11-23T12:51:19+01:00Ghost Userellipse size of wheelchair user## Question
Who can I resize the ellipse size of people?
In case of wheelchair user is it necessary.
In the documentation I could find nothing about this topic.
## Screenshots
## Branch
JPScore Version 0.8
## OS
Mac 10.13.1 (17B48)...## Question
Who can I resize the ellipse size of people?
In case of wheelchair user is it necessary.
In the documentation I could find nothing about this topic.
## Screenshots
## Branch
JPScore Version 0.8
## OS
Mac 10.13.1 (17B48)
## Compiler and versionhttps://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/252relocate agents, if they have invalid room-/subroom information Refactor2017-10-06T09:23:03+02:00Arne Grafrelocate agents, if they have invalid room-/subroom information Refactor## What should be done
In ```Simulation::UpdateRoutesAndLocations()``` there is the following code:
```
std::function<void(const Pedestrian&)> f = std::bind(&Simulation::UpdateFlowAtDoors, this, std::placeholders::_1);
assigned = ped->R...## What should be done
In ```Simulation::UpdateRoutesAndLocations()``` there is the following code:
```
std::function<void(const Pedestrian&)> f = std::bind(&Simulation::UpdateFlowAtDoors, this, std::placeholders::_1);
assigned = ped->Relocate(f);
```
which is working with the part in the ```Pedestrian``` class:
```
for (auto&it_room : allRooms)
{
auto& room = it_room.second;
auto subrooms = room->GetAllSubRooms();
map<int, std::shared_ptr<SubRoom> >::iterator sub =
std::find_if(subrooms.begin(), subrooms.end(), [&] (std::pair<int, std::shared_ptr<SubRoom>> iterator) {
return ((iterator.second->IsDirectlyConnectedWith(allRooms[_roomID]->GetSubRoom(_subRoomID))) && iterator.second->IsInSubRoom(this));
});
if(sub != subrooms.end()) {
flowupdater(*this); //@todo: ar.graf : this call should move into a critical region? check plz
ClearMentalMap(); // reset the destination
const int oldRoomID = _roomID;
SetRoomID(room->GetID(), room->GetCaption());
SetSubRoomID(sub->second->GetSubRoomID());
SetSubRoomUID(sub->second->GetUID());
_router->FindExit(this);
if(oldRoomID != room->GetID()){
//the agent left the old room
//actualize the egress time for that room
#pragma omp critical(SetEgressTime)
allRooms.at(GetRoomID())->SetEgressTime(GetGlobalTime()); //set Egresstime to old room //@todo: ar.graf : GetRoomID() yields NEW room
}
status = true;
break;
}
}
```
It seems to me, that the correction of the room-information somehow does not work. In the following call to the router, there are still pedestrian objects, that hold wrong room-subroom information.
I think it's worth to refactor this part of the code and make it easier and functional.
## Why?
Right now, it is not working and we want to change this part anyway. The call to the router every timestep seems to much. If we find a mechanic, that will only call the router once in a while __or__ the router will be called every timestep, but only executes once in a while, will be up for discussion.Mohcine Chraibim.chraibi@fz-juelich.deMohcine Chraibim.chraibi@fz-juelich.dehttps://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 Graf