Weird thing noticed with AIFP 3.3.2.3

[Firebird]

For reasons unconnected with AIFP I was checking something with a set of flight plans I had.

What I found was an anomally or two.

For reasons unknown to myself I chose to load the traffic file to check something rather than the raw text files. What I got was some warnings in a Validation Report. This I thought was weird as I got nothing when I compiled the plans earlier.
What I thought I would do is check out the warnings listed. The first thing I noticed was that flight plan numbers in the compiled version seemed to be in a random order. This wasn't the case in traffic files produced in earlier versions, I checked some randomly.
The second thing was that the warnings that were picked up were genuine. I have Minimum Time Arr->Dep set to 3 mins so as to pick up possible TNG issues that have been well documented over the years.
Sure enough the arrival time for the TNG leg was 1/15:17:35 and the departure time of the departure home leg was 1/15:18:49 in the raw txt files. In the compiled version both times were 1/15:18.

So in a nutshell I think I discovered two issues. One the compiled version now has the plans sorted on something other than the AC#. Two the warnings are not being picked up in the raw text files.

For your verification, I have attached the raw files and the compiled file.

If I have missed something obvious or need anything else from me please let me know.

 

[gadgets]

One the compiled version now has the plans sorted on something other than the AC#.

What compile options were selected when you created the traffic file. Did you actually check the compile parameters. By default, flight plans in traffic files are saved in the order of descending aircraft wingspan which makes most efficient use of available parking. This is detailed on Page 12 of the user manual.

the warnings are not being picked up in the raw text files.

All information required for a full validation is available upon decompilation of a traffic file. Not all such information is available upon loading a file set. (Validation is accomplished before the fileset has been fully processed because processing may not be possible if certain information is missing.) Filesets are, however, fully validated prior to saving. Also, as noted on Page 10 of the user manual, validation of the current flight plans can be accomplished at any time.

 

[Firebird]

OK I double-checked and found that 'Sequence Flight Plans for Best AI Performance' was highlighted'. The weird thing is that I have never had that on before. At some point it must have been altered. This is proven by the amount of compiled files I have that are perfectly fine.
However, I recompiled with the option definitely off and I got the result I wanted.
The thing that still rattles around my mind is that we compile by Sqns or Wings so the vast majority of the time all of the wingspans are exactly the same. These aircraft are all Typhoons. So what criteria are they being sorted on?

However, from my perspective that issue is fixed.

On the validation aspect I can understand what you are saying. It makes perfect sense. What I get with those files I attached is that the txt files load without warnings and are still without errors when a manual validate is used.
However the validation report opens with warnings as soon as the traffic file is loaded. The same validation report opens on a manual validate.

What I am saying is that for some reason the warnings being found in the compiled plans are not being found in the txt plans. The warnings are genuine, according to my subsequent checking of the txt plans.
The weird thing is that when I first loaded the txt plans there were warnings and they showed automatically in a report, and I used the report to fix those to get a clean report. Now it seems that some warnings are not being produced. I would expect to see exactly the same warnings in either the txt file or the traffic file.

Am I wrong?

You should be able to recreate with those files. If you need any more of my settings other than the 'Minimum Time Arr->Dep (min)' then let me know. Or if you think it would be easier to supply you with my AIFP.ini file I can supply that.

Do you need anything from me?

 

[gadgets]

As I said above, all information required for a full validation is available upon decompilation of a traffic file. Not all such information is available upon loading a file set.

Once the fileset loading is complete, you can manually request a full validation. Such a validation is also performed automatically upon attempting to compile or save the fileset. While I appreciate you may not understand the reasons for initial validations being different, validation on request is but a mouse click away. I don't anticipate redeveloping that aspect of AIFP.

 

[Firebird]

Thanks for replying, Don.
I re-read that section of the manual and read what you wrote. If we ignore me possibly giving too much info about loading files then lets take that out of the equation.
A manual validate of that compiled traffic file gives a different outcome to a manual validate of those loaded text files.
Unless I am misunderstanding both yourself and the manual this shouldn't be the case.

What am I not seeing, or possibly doing wrong.

 

[gadgets]

About which, specific, consequential issue are you concerned. As I said before, I don't plan to redevelop this area of code. But, I am happy to address specific consequential issues.

 

[Firebird]

Well the specific issue here is that it compiles without warnings but then it has built-in issues that are not seen unless you check the compiled file as well. It is double work. for the user
The reason why this is an issue is mainly down to the fact that if you use TNG legs then you have a narrow window of time between the arrival at the end of the TNG leg and the departure of the next leg. I will ignore a gap that is too large for this discussion. If the gap is non-existent or too small then you run the risk of the arrival time being equal to or before the departure leg after compilation.
As we know that leads to aircraft not appearing further down the schedule.

The gap being too small is already expressly checked for by AIFP. In this specific example the txt files are clean but the compiled traffic file reports :-

Flight Plan 5:
Leg 08: Departure scheduled before or very close to arrival time of previous leg

Flight Plan 6:
Leg 08: Departure scheduled before or very close to arrival time of previous leg

Flight Plan 11:
Leg 03: Departure scheduled before or very close to arrival time of previous leg
Leg 11: Departure scheduled before or very close to arrival time of previous leg

Flight Plan 12:
Leg 02: Departure scheduled before or very close to arrival time of previous leg

Flight Plan 21:
Leg 03: Departure scheduled before or very close to arrival time of previous leg

Flight Plan 26:
Leg 03: Departure scheduled before or very close to arrival time of previous leg

Now potentially, in this specific case, you have 6 aircraft out of 27 that may not complete their full schedule.. This fact you would not be aware of unless you also checked the traffic file.

I am not somebody that expects you to bend over backwards to write or redo a large amount of code for a small gain. Far from it. The most I hope for here is that the results from the manual validation of the both the raw and compiled data would be consistent. The section in the manual would seem to suggest that it should be.

I am not suggesting that the validation code should be rewritten. It just seems to be AIFP maybe either using two different routines or maybe using the same routine differently.

Apologies if I am not explaining this very well.

 

[gadgets]

AIFP maybe either using two different routines​

I've already told you (twice) that it does and explained why.

I don't have time to analyse your flight plans to try and understand what it is you consider a problem. You seem to be suggesting there's an issue with TNGs; you haven't told me what it is. You've simply identified some legs on which you apparently believe AIFP is giving incorrect information.

I understand how TNGs work. If the subject of concern is TNGs, then please tell me what AIFP is doing wrong (or not doing) in those particular cases that you think needs to be corrected (please describe the correction you think is needed - in general terms) or what else AIFP needs to do that it isn't.

But, before you do, please consider that times in AIFP are not guaranteed to be experienced in Flightsim and that a discrepancy of 5 min is not uncommon. AIFP guides the aircraft to the boundary of the sector containing the destination airport. It's then up to Flightsim to set up and execute the approach. AIFP allows 15 minutes for this. The time actually required depends on a number of things, including, distance (0 to ~100 nm), approach speed of the aircraft, IFR/VFR, other traffic, etc. So, the "window" for TNGs will expand or contract in real time. What you see as being wrong or missing in AIFP may be impossible to correct with any degree of certainty.

The topic of TNG timing has been discussed in this forum before. You might want to see if you can find those threads. My recollection is that generally, nothing could be done in AIFP to address these situation reliably.

 

[Firebird]

I agree with you that TNG timings are a road that has been covered for a long time.

The bottom line is that I feel that I found an issue within AIFP. I realise that my job is to convince you that there is a problem that needs to be looked at. I have failed to achieve this.

 

[gadgets]

I realise that my job is to convince you that there is a problem

That's one way of looking at it. But, I've concurred with your findings and:

• explained why the results are different, and
• that to change this would require a significant amount of redesign (that I don't think is warranted given the other related features that already exist).

You then indicated that the situation is most serious when there is TNG operation and sent me an error report with the following note

Now potentially, in this specific case, you have 6 aircraft out of 27 that may not complete their full schedule.. This fact you would not be aware of unless you also checked the traffic file.

- seemingly expecting me to determine which of the error messages were of concern to you. In response, I volunteered to re-assess the situation if you would identify the specific issue(s) affecting TNGs and recommend a solution. But, I also cautioned you that the vagaries in operation of Flightsim could defeat anything I might do in AIFP and asked you to consider that. (Your apparent reliance on the traffic file error message suggested you were unaware of AIFP's inability to control exact arrival timing in Flightsim.)

So, your post above in response is a little surprising.

 

[Firebird]

I apologize if I was not getting across succinctly enough my concerns.

The report that I copied for you happened to be a report with 6x warnings. They all happened to be errors that AIFP recognizes about TNG legs.
I will stipulate that I understand that AIFP produced traffic files will not produce exact results in a flt sim. Nor will exact timings written in flightplan txt files be faithfully kept upon compilation into traffic files. So hopefully I can lay any misgivings that you may have about my thinking about that to rest.

I guess where the bottom line that I was coming from was this. I use the txt files to compile without having to think about any other factor. If I get a traffic file I always save as txt files and if I see warnings whern the traffic file is loaded I save the txt files, correct them, and compile. That would be the end of it.

Discovering what I did, purely by accident, means that now I know that I am not going to be 100% certain that I have cleared all the warnings. So now when I clear warnings from txt files and then compile I will have to then load the traffic file to see if there are any more warnings.

I was hoping to have to avoid double checking. That is it. I do not have any issue with the warnings that are produced. I was not asking for a rewrite or an overhaul of code. I guess I was hoping for one of those things that is easy to sort out.

Now I feel that I should explain about my previous statement. I was not getting stroppy or anything like that. I was just being professional. After I left the RAF I became a Systems Analyst for over 30 years. My job was to identify failures and their causes in computer programs and systems and report it back to programmers. My job was to try and explain the situation in a manner that convinced them to take a look and fix it permanently.
Most times this was successful, some times it was not. Like I said I know my role.

If I think that there is an issue I will bring it to your attention, however I understand completely that whether you look at it or not is your choice not mine - and for whatever reason .

I am not a person prone to throwing his toys out of a pram. You do not wish to proceed any further on this matter. I am perfectly fine with that.

I think that should clear up any potential misgivings you may have about either myself or this exchange.

 

[gadgets]

Nor will exact timings written in flightplan txt files be faithfully kept upon compilation into traffic files.

If this is really what you meant to say, them you missed my earlier point altogether. Times specified in flight plans are saved in traffic files exactly ( a 1 minute variation may occur due to rounding.) The point I was attempting to make was that while AIFP does include the specified arrival time in the traffic file, it has no control beyond that. AIFP specifies a series of times for the aircraft to be at the borders of the successive sectors that AI must cross or enter between departure and arrival. AIFP's job is done when the AI arrives at the border of the destination sector. Flightsim takes over from there. AIFP sets arrival at that sector 15 minutes before programmed arrival-at-the-airport time. But how long it takes Flightsim to actually land the AI depends on a variety of circumstances. If a TNG is specified and the AI arrives at the decision point within the TNG "window", a TNG will occur. If not, no TNG - AIFP' error messages notwithstanding..

Incidentally, with AIFP there is no need for you to retain the text file-set. The traffic file is all you need. Indeed, if you always work from traffic files, it seems to me you will always get the error messages you seem to believe are most reliable.

I suggest we terminate this conversation here