search

PedestrianDynamics / jupedsim

JuPedSim is an open source pedestrian dynamics simulator
http://jupedsim.org
Other
39 stars 27 forks source link

Profiles in Method I #772

Closed mirakuepper closed 3 years ago

mirakuepper commented 4 years ago

In the current version of JPSreport the output of profile data in Method I by including the line <profiles enabled="true" grid_size_x="0.20" grid_size_y="0.20"/> is no longer possible. This used to work in the previous versions. (Methods D and J still offer the profile output)

As I use it quite often with Method I, there is the question if it can be included again.

As the output of profile data is slow for huge trajectory-files (Issue #576 ), also the possibilty of an "external script" that can be run after the analysis with JPSreport would be fine, if including the option in Method I does not work anymore.

chraibi commented 4 years ago

As the output of profile data is slow for huge trajectory-files (Issue #576 ), also the possibilty of an "external script" that can be run after the analysis with JPSreport would be fine, if including the option in Method I does not work anymore.

@mirakuepper did you try to use this script? https://github.com/JuPedSim/jpscore/blob/master/jpsreport/scripts/_Plot_profiles.py

mirakuepper commented 4 years ago

_Plot_profiles.py is used for Plotting.

My Problem is not plotting, but generating the files that can be plotted by the script you mentioned.

chraibi commented 4 years ago

Sorry, I misunderstand your comment ("an external script that can be run after the analysis")

This issue is about including the profiles back in Method I. I think that can be done.

However, the other problem, which is faster calculation of the profiles, may be addressed in another issue.

JetteSchumann commented 4 years ago

I talked to @gjaeger and checked the code. The profiles option is not available/considered in Method I. Since the whole geometry is the MA creating this output is very time consuming.

Should it be enabled anyway? @gjaeger proposed a more efficient implementation before doing so.

@chraibi was faster than me ;)

chraibi commented 4 years ago

@JetteSchumann When I quickly have a look in the Method_D::GetProfiles() it seems that it does not depend on any measurement area.

Maybe there is some hack, butI think this should be done for method I.

@gjaeger proposed a more efficient implementation before doing so.

🤔

JetteSchumann commented 4 years ago

@chraibi you are right. Seems that it only depends on the geometry. But it is using GetVoronoiDensityVelocity() which is not used in Method I anymore. I think Method I was supposed to calculate individual data only?

gjaeger commented 4 years ago

I suggest that we discuss this issue in a user meeting. How about May 25th? Mira and I could prepare something.

mirakuepper commented 4 years ago

Following our discussion I tested three differrent measurement areas for profile calculation with Method D:

1) no measurement area <area_B id="1" type="BoundingBox" zPos="None"> </area_B> (ini_corridor_D_BBfree.xml)

2) fix measurement area; as values for the bounding box I used the same values as 1) provides, namely the min/max values of the geometry extended by 10 meter in all directions (ini_corridor_D_BBfix.xml)

3) fix bounding box that only includes half of the x-range (ini_corridor_BBsmall.xml)

Result: The profile files for all three cases are the same.

For testing I used the demo files for the corridor. The traj-, geo-, ini- and log-files are attached. upload.zip

gjaeger commented 4 years ago

Interesting, the profiles seem to be independent of the measurement area. I didn't expect that.

----
JuPedSim - JPSreport

Version        : 0.8.4
Compiler       : clang++ (11.0.3)
Commit hash    : v0.8.4-976-ge189246b
Commit date    : Tue May 19 22:00:07 2020
Branch         : master

I made the following changes in all ini-files (enabled=true instead of enabled=false):

<cut_by_circle enabled="true" radius="1.0" edges="10"/>

ini_corridor_D_BBfree.xml

measurement area

    <measurement_areas unit="m">
        <area_B id="1" type="BoundingBox" zPos="None">
        </area_B>
    </measurement_areas>

density

profile_rho_free

velocity

profile_vel_free

ini_corridor_D_fix.xml

measurement area

    <measurement_areas unit="m">
        <area_B id="1" type="BoundingBox" zPos="None">
            <vertex x=" -10.0" y="-10.0" />
            <vertex x=" -10.0" y="12.0" />
            <vertex x=" 20.0" y="12.00" />
            <vertex x=" 20.0" y="-10.0" />
            <length_in_movement_direction distance="4.0" />
        </area_B>
    </measurement_areas>

density

profile_rho_fix

velocity

profile_vel_fix

ini_corridor_D_fix_small.xml

measurement area

    <measurement_areas unit="m">
        <area_B id="1" type="BoundingBox" zPos="None">
            <vertex x=" 5.0" y="0.0" />
            <vertex x=" 5.0" y="2.0" />
            <vertex x=" 10.0" y="2.00" />
            <vertex x=" 10.0" y="0.0" />
            <length_in_movement_direction distance="4.0" />
        </area_B>
    </measurement_areas>

density

profile_rho_fix_small

velocity

profile_vel_fix_small

mirakuepper commented 4 years ago

Should we leave this issue open or discuss further steps concerning this in #792 ?

chraibi commented 4 years ago

That the profiles are produced for the whole geometry is clear. See https://github.com/JuPedSim/jpscore/blob/master/jpsreport/methods/Method_D.cpp#L357

Is this a problem? Now, I'm not clear about this issue.

@mirakuepper Is the problem in method I? If yes, then I would say the solution should come from #792.

mirakuepper commented 4 years ago

The problem is that I would need a mixture of features of method I and D. Profiles are only possible with method D, but I also need the data of frames where less than 3 persons are present, which is, as far I understood, only possible in method I.

Therewith, implementing features of method I in D (#792) would solve this issue.