Closed Petterjakobsson closed 2 years ago
Iwhite67
commented
2 years ago So
I thinks for solved the big problem, @rpuig2001 you need to give a possibility to remove a people from sequence.
Why ? Actually, for don't have in real sequence a traffic, put 0000 but he keep traffic in sequence and if you but a other with 0000 he come just after.
Can you add a function for delete Traffic from sequence ?
rpuig2001
commented
2 years ago Good Afternoon @Petterjakobsson, I've reproduced your situation in my Euroscope b26, CDM v1.1.5 and Time static set to 08:58, Normal Rate 34 and LVO Rate 20.
Before:
First 4 tfcs at 0910 (Nothing wrong...):
Other 4 tfcs at 0915:
And finally .cdm lvo on and you are right, some of them are moving down (It's a known bug that I'll try to fix):
Apart from that, as far as I know, anyone who've tried the plugin didn't had this problems.
So, can I have your departure list items to check if is there anything wrong?
Petterjakobsson
commented
2 years ago I did a new test to get a screen print of the DEP-list and it's the same result.
If you like we can take it on Discord, Petter Jakobsson#2165
Or did you mean the DEP-list items?
m_Column:A:1:1:8:106:0:1:CDM Plugin:CDM Plugin::0:0.0 m_Column:EOBT:5:1:1:100:112:1:CDM Plugin:CDM Plugin:CDM Plugin:0:0.0 m_Column:E:2:1:9:0:0:1:CDM Plugin:::0:0.0 m_Column:TOBT:5:1:4:0:0:1:CDM Plugin:::0:0.0 m_Column:TSAT:5:1:2:0:0:1:CDM Plugin:::0:0.0 m_Column:TTOT:5:1:3:0:0:1:CDM Plugin:::0:0.0 m_Column:TSAC:5:1:5:103:104:1:CDM Plugin:CDM Plugin:CDM Plugin:0:0.0 m_Column:ASAT:5:1:6:0:0:1:CDM Plugin:::0:0.0 m_Column:ASRT:5:1:7:107:0:1:CDM Plugin:CDM Plugin::0:0.0 m_Column:CTOT:5:1:10:108:0:1:CDM Plugin:CDM Plugin::0:0.0
Petterjakobsson
commented
2 years ago My bad! Interestingly running the same test with another simulation does not reproduce the issue with the TTOT. This time no dubbel assignment of TTOT happens and the sequence seems stable. Might have been something strange in the scenario file.
However I still get the issue that multiple flights TSAT expires and being removed from the sequence even though the TSAT is still valid. This time all flights with EOBT/TOBT at 14:35 expired within a few seconds. Notice DLH721 have an expired TSAT of 14:41 at time 14:41.
Out of the corner of my eye it looked like when the first flight expires, the second flights TSAT is moved to an earlier TSAT since no previous flight is forcing a delay. Looks like the TSAT updates to current time - 5 minutes, but a second later the new TSAT for the second flight also expires and then the third flight moves to current time - 5 minutes and a second later it expires. Notice the small time difference between the images. See images below.
rpuig2001
commented
2 years ago However I still get the issue that multiple flights TSAT expires and being removed from the sequence even though the TSAT is still valid. This time all flights with EOBT/TOBT at 14:35 expired within a few seconds. Notice DLH721 have an expired TSAT of 14:41 at time 14:41.
First, they expire because their time is Invalid, so if the first expire, the second moves forward, the second forward, etc. So.. Any traffic has an state, that way all will move forward and will expire ;) Just for your information, you can clear a tfc to S/U +/-5 min of TSAT (Dark green), so that would never happen.
Out of the corner of my eye it looked like when the first flight expires, the second flights TSAT is moved to an earlier TSAT since no previous flight is forcing a delay. Looks like the TSAT updates to current time - 5 minutes, but a second later the new TSAT for the second flight also expires and then the third flight moves to current time - 5 minutes and a second later it expires. Notice the small time difference between the images. See images below.
It moves forward little by little forward due to the refreshtime, which as you may see it runs every X seconds.
Petterjakobsson
commented
2 years ago First, they expire because their time is Invalid, so if the first expire, the second moves forward, the second forward, etc. So.. Any traffic has an state, that way all will move forward and will expire ;) Just for your information, you can clear a tfc to S/U +/-5 min of TSAT (Dark green), so that would never happen.
I'm testing edge cases that's true, however I can see cases where it could happen. If it can happen it will and probable during a busy period. Let's say you have a group flight with a common departure time. The flight plans is filed and the CDM starts calculating TSATs. If for some reson there are a delay for the first couple of flights then there will be a cascading effect if the first TSAT becomes invalid. I would argue that it would be better if a TSAT that is in the past can't move to an earlier time and a TSAT in the future can't move to an earlier time than present time. The delay has already occurred so pushing TSATs earlier back into the past time won't help.
It moves forward little by little forward due to the refreshtime, which as you may see it runs every X seconds.
The issue is more prominent when you have a high refresh time. I was using 5 second so I could see how the system worked but setting default value of 30 seconds makes this issue less of an issue, but still there. I understand that this might not be prioritized but I thought I bring it up.
rpuig2001
commented
2 years ago TSATs will only expire if no state is set and actual time TSAT+5, traffics with ground status set, TSATs will not expire even if the actual time equal TSAT+5 or greater. If other traffics become invalid, they won't improve TSAT earlier than EOBT.
Hi
Great to see a CDM-tool for ES, really appreciated.
I have done some testing at Arlanda (ESSA) with a simulator session and I have found some behaviors of the algorithm that is not as I would have excepted it to behave. There are some different issues but I think they might be related so I report them in the same "Issue".
The issues I see are:
TTOT is not issued with respect to EOBT/TOBT sequence. I expect TTOT to be assigned in accordance with the sequence set by EOBT/TOBT even if there is delays due to capacity. A flight with a later EOBT/TOBT should not be assigned an earlier TTOT than a flight with an earlier EOBT/TOBT. Obviously there need to be some kind of cut out time that prevents a flight that loggs on with a EOBT/TOBT at current time to be "forced" in to the sequence and jumping the queue. I think this is related to the issue below where the assignment of TTOT will generate a non logical sequence.
When a new flights is added it sometimes get the same initial TTOT as an already existing flight. After a while and some recalculation it will delay the first/original flight instead of sequencing after the already existing flight. Some kind of "First come, first served" should apply in this case. It would be best if the system could not assigned duplicate TTOT in the first place.
Related to above, when setting a "ready-msg" the flight is "forced" in to the sequence on to the same TTOT as other flights. Then as above the flight that already was at that TTOT gets a new TTOT at a later time, sometimes at the end if the sequence.
Flights with a TSAT delayed by 5 minutes or more due to capacity, times out / is removed from the sequence about 5 minutes after EOBT/TOBT even if the TSAT is still in the future.
Sequence is not kept after changing the rate, LVO ON/OFF.
Some screen shots from differents tests:
In the first test I will add flight in alphabetical order with some delay between every addition. I am adding the first 5 flights to time 09:10 and the last 5 flights to time 09:15. I have a rate of 42, a refresh time of 10.
The initial state.
First three flights added without issues.
FIN632 added and gets the same TTOT as BAW468C.
After a few seconds it recalculates and BAW468C is forced to the bottom even though it initially had TTOT at 09:26.
NAX4201 is added and the same happens, this time affecting COA069.
Then I add 4 flights with time 09:15 without issue.
Adding the last flight, SKX1013, at time 09:15. This time it happen too fast to get a print screen but it forces both BAW and COA to the bottom.
The next example is showing the issue with flights timing out and being removed from the sequence.
Initial state, notice the same issue with EOBT/TOBT as above.
AFR1463 times out and is remove as expected.
A few seconds later BAW and FIN times out. FIN is still inside TSAT-window and BAW has just entered it with more than 9 minutes to go. Might it be that FIN times out because the TSAT is not set to whole minutes but actually has a hidden seconds parameter? If so then please change so that TSAT is only in minutes even though TTOT needs to be in seconds.
After a few more seconds COA and NAX times out even though their TSAT was valid. Notice that FIN and BAW is removed at the same time and NAX and COA at the same time. If you have a look at the previous example where I add the flights you'll notice that FIN forced BAW to the bottom and NAX forced COA to the bottom. This happens every time I try and it seems to be related when they are removed. It's like BAW and COA has a hidden TSAT containing their initial TSAT. Me guessing. :)
Next I set a "ready msg" for all timed out flights. All of them is forced in to the sequence moving flight that are in their way.
The last example shows that the sequence is not kept if you change the rate. Changed from normal rate, 42, to LVO, 21. I guess that I'm provoking the system by using the same EOBT/TOBT but that should not be a factor, the sequence should be kept.