Issue with reading trajectory files

[chraibi]

In Gitlab by @rummeny1 on Feb 22, 2018, 10:08 [origin]

Hi,

i have an issue with reading in a trajectory file with JPSReport. Somehow JPSReport thinks, that the trajectories are not continuous because there is one frame more than expected. Changing the trajectory file didn't help, since JPSReport simply adjusts the "actual_totalfame" (by the way: typo :) ) still with one frame more than expected.

Please see the trajectory file and the log from JPSReport here

Could you please help me once again? Thanks in advance!

David

[chraibi]

In Gitlab by @chraibi on Feb 22, 2018, 10:20

assigned to @gjaeger

[chraibi]

In Gitlab by @chraibi on Feb 22, 2018, 10:21

changed the description

[chraibi]

In Gitlab by @gjaeger on Feb 22, 2018, 22:20

Thanks, I will take a look

[chraibi]

In Gitlab by @gjaeger on Feb 23, 2018, 13:51

Problem solved. The negative time was not removed in the function prt5_savetxt_batch.

Now it should work with prt5parser.py:

import prt5parser as p

# prt5_savetxt_batch(CHID,N_meshes,T_BEGIN,T_END,DT_PART,TARGETS)
# CHID     = vharacter ID to tag the output file
# N_meshes = number of FDS+Evac meshs
# T_BEGIN  = first time step
# T_END    = last time step
# DT_PART  = time step (default: 0.5 s)
# TARGETS  = number of DOORS and EXITS
p.prt5_savetxt_batch('A01',5,0,900,0.5,18)

[chraibi]

In Gitlab by @chraibi on Feb 23, 2018, 13:52

Can we have this ptr5parser in the script-folder? Or as in a separate repository..

[chraibi]

In Gitlab by @gjaeger on Feb 23, 2018, 13:54

not yet. I want to clean up.

[chraibi]

In Gitlab by @rummeny1 on Feb 25, 2018, 17:51

Thanks for the quick answer - with the new prt5parser-file, the negative times are correctly removed. Unfortunately, the original problem still exists.. I have updated the log and trajectory file for download under the link in my first post. And again - changing the trajectory file does not help.

Could it be another issue? I see exactly 1180 Frames for Person 1 (which is also the expected frames from JPSReport) but I don't know how JPSReport assumes, that there are 1181..

[chraibi]

In Gitlab by @chraibi on Feb 25, 2018, 20:33

Sure you are working with the branch develop? This sounds like a familiar old bug, that was already fixed. Please upload the inifile too.

[chraibi]

In Gitlab by @gjaeger on Feb 25, 2018, 21:43

Please upload the geometry file too.

[chraibi]

In Gitlab by @rummeny1 on Feb 26, 2018, 08:01

Good Morning. I have uploaded both files under the first sciebo link. I am aware, that the geometry does only cover a small part of the complete simulation but as far as I know JPSReport just writes an INFO Message for Person out of geometry and continues with the calculation. In case I "reconstructed" the old bug - please discribe what I'm not supposed to do in the ini-/geometry-file. Thank you both!

[chraibi]

In Gitlab by @gjaeger on Feb 26, 2018, 15:04

A short analysis with jupyter

There is a problem with merging each evacuation mesh in prt5parser.py. There are two z-values at one time step.

Feel free to fix it.

[chraibi]

In Gitlab by @chraibi on Feb 27, 2018, 11:07

@rummeny1 any updates on this?

[chraibi]

In Gitlab by @rummeny1 on Feb 27, 2018, 13:05

Yes, I also searched the trajectory file in detail and found about 2250 lines with the same time step and ID. As Gregor already stated, it seems that the parser adds the information for one person from both meshes while they are moving to the other mesh. So it's not only because of the z-values but because of the transition to another mesh.

Nevertheless, after removing the doubled lines, JPSReport worked properly.

[chraibi]

In Gitlab by @chraibi on Feb 27, 2018, 13:07

:+1: So we should close this issue then .. ;-)

[chraibi]

In Gitlab by @rummeny1 on Feb 27, 2018, 13:08

Yes :)