Random large TTOT gaps

[pinatacolada]

Sometimes CDM ignores the defined rate and applies separation much greater than it is supposed to, for example below:

The defined rate at time was 20/h, so 3 minute gaps between TTOTs. This is what is happening until DLH152, even if TAP1364 randomly has a 4 minute gap between him and the preceding.

But then DLH31X has a 6 minute gap, without any flow measure or CAD limitation. Even worse is TAP1697, that not only has a 9 minute gap to the preceding, it should have been able to be slotted in at TTOT 1533, between DLH152 and DLH31X, or even at TTOT 1545 between VLG298 and DAL273, where a 14 minute gap exists and could be used. It ends up with a 39 minute delay when it could have been 6 minutes with a TSAT at 1520.

These large gaps occur where there are a lot of departures, the full list looked like this:

[pinatacolada]

More examples, gap between TTOT should be 3 minute again according to the rate:

TAP56 should have had no delay and departed first of everyone else, instead it took a 9 minute delay.

KLM1696 could have been TTOT 1725, iso 1728

[pinatacolada]

RYR5WC should have had a TTOT ahead of everyone else at 1729

[rpuig2001]

Hi @pinatacolada, Thanks for the report, can you modify your config as sent in discord.

Then a new file will be created under the CDM folder such as CDM_data_LPPT When this occurs, can you attach this file to have a complete look of the internal list.

[hannesaltmann]

I guess the same problem here at EDDB:

Started with EWG1TK (6 minutes interval

What is interesting is, that DLH25M gets slotted in front after I gave start-up approval for EWG1TK and DLH2AW (as there was no reason to give delay to them):

Rate for for EDDB is: EDDB:A:25R:25L:D:25L:25R::30_15 EDDB:A:25L:25R:D:25R:25L::30_15 EDDB:A:25R,25L::D:25R,25L:::25_10 EDDB:A:07R:07L:D:07L:07R::30_25 EDDB:A:07L:07R:D:07R:07L::30_25 EDDB:A:07R,07L::D:07R,07L:::25_10

This evening both 25L and 25R were used for departures.

[hpeter2]

@rpuig2001 careful. EDDB has taxizones defined.

[rpuig2001]

Hi all, I have been trying to reproduce this issue with the latest version under development. Unfortunately I'm unable to reproduce it.

Do you have any clue or example (step by step) to reproduce this issue?

[becas22]

@rpuig2001 the problem itself appears to be fixed. However, when you get CTOTs in the mix, if the interval between CTOTs is not a multiple of the interval between departures, there will be some gaps that could be shorter.

We have 3min separation between departures in LPPT. With the first TTOT being 1039, the second one could be 1042. Because we have a CTOT at 1043, 1 min is wasted here. The same with the CTOT at 1050. CTOT has a window of -5min to +10min so theoretically the CTOT could be the same but the TTOT adjusted to fit in gaps, while complying with the CTOT window

[rpuig2001]

The next version in development should fix this issue due to a new CTOT handling :)

I will close this issue for now.