Creating Flight Plans from Timetable Data Testing

[gadgets]

it only assigns an aircraft to the first flight plan it creates. The other flight plans has no aircraft assigned to them.

Bob, I am unable to duplicate with the latest development release nor can I see anything in the code that would produce this result. Are you sure you are using the latest release?

The MRAI Compiler does not work that way for me. If I set it to use Local time (Timetable use GMT Times box UNchecked), then the local times are converted to UTC according to its AirportDB.txt file found in the Database folder

Tom, perhaps there's more than one version of the MRAI compiler out there. Anyway, I'm happy that the latest release of AIFP is now fully competitive with MRAI and, while it placing the deadhead leg (where necessary) in a realistic manner may result in extra FPs, leaving that feature unchecked allows the user to close (or not) in whatever manner the user chooses.

Don

 

[tgibson]

Hi,

Development version (u) seems to work as it did in version (t1). One thing - when I load the Timetable Data file after restarting the program, the box that comes up has all my previous settings, except ATC Calls by Flight Number is never saved; it reverts to Registration.

Thanks,

 

[gadgets]

Remind me Tom, is that good or bad.

when I load the Timetable Data file after restarting the program, the box that comes up has all my previous settings, except ATC Calls by Flight Number is never saved; it reverts to Registration.

Simple oversight. Will be fixed in general release.

Don

 

[gadgets]

I'm trying to use the open time table data file option, and while it finds my AI aircraft based on the aircraft type, it only assigns an aircraft to the first flight plan it creates.

Bob, are you still having difficulty? If not, I'm ready for general release.

Don

 

[tgibson]

Hi,

Well, it's both. I think it's working as you intend, which is good. I would prefer that it create circular flight plans without adding an extra leg (like the MRAI Compiler does), so (for me) that's bad.

BTW I don't believe you work in C, but there is source code available for the MRAI Compiler in the Source Code folder. I once tried to compile it using Visual C++ (as I remember?) but it is older code and wouldn't compile.

 

[gadgets]

I would prefer that it create circular flight plans without adding an extra leg (like the MRAI Compiler does), so (for me) that's bad.

That would be nice. But, how do you suggest it be done, Tom? If the data does not yield a circular FP, the only way I know how to make it circular is to add an extra leg. (As noted below, MRAI does, in fact, add an extra leg.)

The main problem with creating FP's from timetable data is that there is no indication in the submitted data as to which physical aircraft is used for a particular leg - which indication would guarantee circularity. While both MRAI and AIFP consolidate the Aeronaves data into 15 FP's, we have no way of knowing how many aircraft were actually used in executing that schedule (probably more than 15 given maintenance and reliability constraints) or if any deadhead legs were involved. (Airlines spend millions on fleet management software which takes into account many variables not known or available to AIFP. Expecting AIFP to accurately reverse-engineer the resulting schedule without access to this additional information is unrealistic.)

As I have previously pointed out, when the MRAI compiler discovers a non-circular result, it does add a deadhead leg at the end of the FP - whether or not there is time for that leg to actually occur and without regard to specified sit-time. On the other hand, AIFP ensures that there is time for the deadhead leg to occur using the specified sit-time which, yes, occasionally results in additional FPs with only a few legs. If you don't want AIFP to do this, uncheck the feature and take whatever closing action you wish - or simply ignore the non-circularity and let the FPs be non-realistic in a different (but minor) way.

BTW I don't believe you work in C, but there is source code available for the MRAI Compiler in the Source Code folder. I once tried to compile it using Visual C++ (as I remember?) but it is older code and wouldn't compile.

I have examined that source code. It's not written in any language I have ever used and it certainly isn't c++ (which explains why it wouldn't compile for you). But its methodology is clear and, save for the indiscriminate addition of deadhead legs, is essentially identical to the methodology used by AIFP.

I hope this clarifies the situation.

Don

 

[Bob Keeshan]

No

Bob, when that happened to me only one aircraft had been found by AIFP, not all of them. Only the one found by AIFP was assigned to flight plans. Are you saying that every aircraft type in the drop down box in Step 4 of my post above (the "search box") listed all of the relevant planes without you having to press the Add button?

No, it only showed one. I thought, though, that I had tried to select multiple aircraft and it still gave me multiple flight plans, but assigned the aircraft to only the first. I'll check it when I get home tonight.

Also, I thought it would be great if we couple import multiple timetable plans to create one large flightplan, but it seems they overwrite each other.

 

[gadgets]

I thought it would be great if we couple import multiple timetable plans to create one large flightplan, but it seems they overwrite each other.

You can do that, but you must first save each flight plan file set created from timetables and then Merge them with one another after you've dealt with all the timetables.

Don

 

[Bob Keeshan]

When I create the timetables, here's how the aircraft select box looks:

It doesn't allow me to multi-select. However, if I click on each option then click continue then it populates my flight plan with each aircraft. I guess I'm not sure how it's suppose to work, especially when it looks like I'm only able to select one of the aircraft.

 

[gadgets]

Bob, that dialog tells you which aircraft in your "stable" of installed aircraft match the specified aircraft selection criteria and allows you to add to or delete from that automatic selection. In this particular case, you have asked AIFP to display the aircraft that will be used for the designation A319_DL. One such aircraft is available. You may add other aircraft by clicking the Add button and entering the specification(s), or you may delete from the list by highlighting the aircraft to be deleted and clicking Delete. Whatever aircraft are in the lists when you click Continue are candidates for use in the flight plan and will be listed in the Aircraft List once the flight plans have been generated. If there are multiple flight plans for any aircraft type, AIFP will sequentially assign available aircraft of the required type, repeating the sequence as necessary.

Don

 

[tgibson]

Hi Bob, as stated above, there would be no reason to select multiple aircraft in that drop down box since each aircraft requires a different AI plane, except in the unlikely event that you want to use the same plane for many aircraft types (usually not very accurate). In that case you'll have to do them one at a time.

Don, I do know how difficult this can be. I have spent many hours with the MRAI Compiler trying to get certain flight plans to compile correctly (i.e. without non-circular legs). Often the logic in the program selects the incorrect next flight, leading to flights left over at the end. To combat this, I sometimes have to split up the flight plans for a given plane type into multiple parts to get what I want (i.e. figuring out manually how the planes flew their schedules (using pencil and paper), then compiling each plane's flights separately). It's the only way I know to force the compiler to use the correct legs for each plane.

The flight plan data file I uploaded does have an equal number of flights into and out of each airport, so theoretically a completely circular flight plan file can be created without any deadhead legs. The MRAI Compiler is able to do that with this specific file (often it is not), and I have confirmed that it is converting local time into GMT. That's all I'm saying.

 

[gadgets]

Tom, I have once again looked into this. AIFP and MRAI use identical algorithms for creating these flight plans. The differences between the results are due entirely to erroneous time zone offsets in MRAI's airport data, including MMLP, MMLT, MM0S and others. You may recall that you had to change the offsets of the latter two just to get the MRAI compiler to run with your data. Even now, if you compare the two sets of flight plans, you will find the sequence of legs in individual FPs to be identical until an erroneous time zone offset is encountered. (They're easy to spot since the arrival time will usually be off by 1 hr.)

I believe all AIFP's time zone offsets are correct. At least no one has pointed out that they aren't, and they are all in agreement with the AIG database. If you wish to do further comparisons, please update the MRAI airport database so the time zone offsets agree with AIFP. Once you do that, I suspect you will get identical results, including the need to add the deadhead legs AIFP proposes. (It seems sheer coincidence that MRAI does not now find a need for/apply deadhead legs in this data - as you report it does for other data sets.)

Incidentally, the reason MRAI previously computed FP times in local time for me was that I was attempting to run the compiler from the .zip. As a consequence, it did not see the airport data - nor did it complain about the absence of airport data.

The flight plan data file I uploaded does have an equal number of flights into and out of each airport,

While this makes closure of all generated flightplans theoretically possible, practically, it has little effect on the issue. The algorithm used by both sorts the legs by departure time - destroying any relationship you might have implemented - picks the earliest departure time for an aircraft type, adopts the arrival time for that leg, adds sit-time and looks for the next earliest departure of such an aircraft, repeating the process until 10080 minutes have been used. That becomes flight plan 1. The process then begins again, starting with the earliest unused leg for the aircraft type. Guaranteeing closure of all flight plans (when theoretically possible) would involve a great deal more computation - potentially testing thousands of combinations.

As I mentioned in an earlier post, if you want "perfection", AIFP needs to know which legs are flown by a single aircraft, something that is not currently provided in the data.

Don

 

[tgibson]

Hi,

I've now changed the time zones using the AIFP Timezone Editor for all the airports in the plan to the ones I have set in my MRAI Compiler database and I still get the no closure message for the majority of the flight plans when compiling with AIFP. Very odd. I've looked at the first DC-3 flight plan and all is identical up to the point where a single flight passes through midnight, then things are suddenly different. But things become different in the first DC-6 plan without passing midnight, so that is probably a coincidence.

If you care to try to compare them I've attached the output file I get from the MRAI compiler when using the original flight plan file (also included). To be clear, I use the plans_AMX62_text.txt file (in the first upload) when compiling with AIFP and the attached plans_amx62.txt file when compiling using the MRAI Compiler due to their different aircraft type requirements. They are otherwise identical. The included New1_plans_amx62.txt file is the output compiled from the MRAI Compiler when I use the plans_amx62.txt file as the input data file. BTW, all wait times/max wait times are set to 5 minutes. I did not enter a time in the Priority to Same FN Within box in AIFP.

I have included the edited AIFP Timezones.dat file in case you want to try compiling in AIFP under identical conditions. I have also included my edited MRAI Compiler AircraftDB.txt and AirportsDB.txt files I use, but those should not be needed unless you want to do that compile yourself.

Hope this helps,

 

[tgibson]

PS. You mention defining legs used by specific aircraft; as I said I do that currently by breaking out those legs into separate flight plan files and compiling them separately. Works fine.

 

[gadgets]

I have included the edited AIFP Timezones.dat file in case you want to try compiling in AIFP under identical conditions. I have also included my edited MRAI Compiler AircraftDB.txt and AirportsDB.txt files I use,

Thanks. I'll take a look when I have a chance.

 

[gadgets]

Tom, as you have already discovered for yourself, the MRAI compiler does not generate circular FPs for all data. That it does for this particular data seems pure happenstance.

As best I can tell from experimentation and an analysis of the MRAI code, there are two differences between the methodology of these two products:

• MRAI starts its analysis an Monday; AIFP starts with Sunday; and
• MRAI sorts it departure times based on whatever timezone is used in the data; AIFP sorts based on UTC.

Please open your data with MRAI. There are two extra columns in addition to a tabular presentation of the data. Those two columns are titled "Dep Int" and "Arr Int". These two columns represent the number of minutes since midnight Sunday/Monday. Dep Int is the sort criteria prior to construction of the flight plans. Note also these two columns represent local time (because the timetable data is in local time).

The fact that MRAI starts the process at 0001 Monday - as opposed to AIFP's use of midnight Saturday/Sunday seems largely inconsequential as regards the number of FPs generated. But, the other difference has a major effect. So long as the originating and destination airport are in the same time zone, there's no issue. But, if the time zones are different, the duration of the leg will be one (or more, depending on the difference) hours longer or shorter than intended - though arrival will be as scheduled. Since AIFP sequences legs based on UTC, leg duration will be as intended. As a demonstration, I modified AIFP also to sequence legs based on local time. To my surprise, AIFP generated only 15 FPs (like MRAI), 5 of them deadheaded.

I think it's time to bring this discussion to a close. AIFP generates flight plans that accurately reflect the input data. MRAI ignores time zone changes within a leg. From limited experimentation, it would seem that MRAI's approach may generate fewer FPs albeit with potentially unrealistic leg durations. Use whichever best serves your purposes.

Don

 

[tgibson]

Hi,

Thanks for looking into this. It's probably true that the AIFP compiler will generate cleaner flight plans in certain cases, and the MRAI Compiler in others.

BTW, I don't see a problem with the MRAI Compiler leg durations when the airports are in different time zones. An example from the above plan is:

AM;100;MMGL;MMCL;1040;1120;1234567;DC6

MMGL is -6/-5, and MMCL is -7/-6. So at 1040 at MMGL, it's 0940 at MMCL. The leg duration is thus 0940 to 1120, or 1 hour 40 minutes.

In the plan compiled by the MRAI compiler this leg is:

MMGL,1/16:40,@1/18:20,220,F,0100,MMCL

which is indeed 1 hour and 40 minutes.

Here is the leg when the same plan is compiled by AIFP:

MMGL,1/16:40,1/18:20,040,F,0100,MMCL

Looking at the leg in the other direction:

AM;101;MMCL;MMGL;1450;1740;1234567;DC6

MRAI Compiler gives:

MMCL,1/21:50,@1/23:40,190,F,0101,MMGL

And AIFP compiles to:

MMCL,1/21:50,1/23:40,030,F,0101,MMGL

So I think they are both making the proper conversion (luckily).

Again, thanks for your help and I will now try the other compiler when I get bad results with my first attempt- the other one might work better - good to know! I'll still use my "divide and conquer" approach for those plans that don't cooperate either way.

 

[gadgets]

I don't see a problem with the MRAI Compiler leg durations when the airports are in different time zones.

Yes, in retrospect, I agree MRAI's use for sequencing purposes of whatever timezone scheme is used in the data is not problematic, since each departure must be from the same airport as the previous arrival and, hence, there is time zone consistency in the selections.

As I have demonstrated on a number of occasions, I love a challenge. Over the past week or so, it has become obvious to me why the flight plans generated by AIFP and MRAI are different. But, I have continued to be bothered by the fact that MRAI encounters such little difficulty in making FPs circular - as opposed to AIFP - at least using the limited amount of test data I have. So, despite my apparent reluctance in continuing the debate, I have persevered "behind the scenes". Now I know why!

While I initially thought MRAI sequencing the legs for FP generation using whatever timezone scheme is in effect in the input data was problematic, whether by design or accident, this use of input time zone is the key to MRAI's lack of difficulty in effecting closure with the data currently being used for testing. Why? Because, with the test data, in local time there is usually a large gap between the last arrival of one week and the first departure of the next - which leaves lots of time to force closure where necessary. In the case of the current test data (Mexico), AIFP using Time 0 UTC pushes this gap to the middle of the first day, leaving little time for end-of-week closure. (I'm not going to go into further detail. Doubters can "do the math" for themselves.)

So, the key appears to be to start the sequence at the first leg following the longest gap between in legs in the data. Fortunately, with AIFP, that's easy to determine and do. It won't make much difference where 24hr operation is the norm, but otherwise, AIFP should generate no more FPs than MRAI would for the same data and, where the gap in operation is other than midnight to dawn, AIFP should be able to improve on MRAI's results.

Now that I know what to look for, I think you'll be able to put the MRAI compiler "on the shelf" after the next release.

Don

 

[tgibson]

Woo hoo, that's good news! I have always wondered why some FP will compile effortlessly and others take me hours to get right. Now I know that it depended on where the "natural gaps" were in the data, and if those gaps matched the compilers default protocol they would compile smoothly, but would cause problems if not. If you can do a search for that natural gap in the data and start there, that will be great.

Thanks,

 

[gadgets]

Please download Development Release 3.2.03(c) from http://stuff4fs.com. I think you will find there are few exceptions to it generating the same number of, or fewer, FPs than MRAI.

Don