Flight plan altitudes depending on selected approach transition in a most non-intuitive way

Just spent about an hour arguing with IFPUV about an LIRN - EDDB flight I was planning, and ended up finding something I don’t understand.

If I start with this route in SimBrief:
BEDP7G BEDPI M725 MOLUX TORPO LIMRA TIVAP UPEGU ODLIV LEGAZ BEFRE T204 NUKRO NUK25L

and select IFPS validation Simbrief generates this FPL:

(FPL-EJU68JZ-IS
-A320/M-SDE3FGHIRWY/LB1
-LIRN0500
-N0456F300 BEDPI7G BEDPI M725 MOLUX/N0456F340 DCT TORPO DCT LIMRA DCT TIVAP DCT UPEGU DCT ODLIV DCT LEGAZ DCT BEFRE T204 IVDUF/N0456F300 T204 ABLOX/N0456F340 T204 NUKRO NUK25L
-EDDB0220 EDDP
-PBN/A1B1C1D1O1S1 DOF/231212 REG/OEIVO RMK/TCAS)

When I put that in the IFPUV free text editor it has never heard of NUK25L. If I delete NUK25L in the free text editor FPL the FPL clears validation with no errors.

But if I instead remove NUK25L in SimBrief (don’t want to use the RNAV transition) to get this route:
BEDP7G BEDPI M725 MOLUX TORPO LIMRA TIVAP UPEGU ODLIV LEGAZ BEFRE T204 NUKRO

and select Validate SimBrief instead generates this FPL:

(FPL-EJU68JZ-IS
-A320/M-SDE3FGHIRWY/LB1
-LIRN0500
-N0456F300 BEDPI7G BEDPI M725 MOLUX/N0456F340 DCT TORPO DCT LIMRA DCT TIVAP DCT UPEGU DCT ODLIV DCT LEGAZ DCT BEFRE/N0456F300 T204 NUKRO
-EDDB0220 EDDP
-PBN/A1B1C1D1O1S1 DOF/231212 REG/OEIVO RMK/TCAS)

When I try to validate that I get a string of “forbidden” and “off mandatory route” and general nastiness from IFPUV.

The difference is the altitudes along T204. Why does SimBrief generate different altitudes along that airway depending on whether or not I have the RNAV approach transition in the SimBrief flight plan?

Those climbs up and down along T204 are nonsense anyway since BEFRE ends up being after TOD, but it seems you have to file that way to make IFPS happy…

NUK25L can only be approved by ATC and therefor cannot be filed with the ATC submission.

NUK25L can only be approved by ATC and therefor cannot be filed with the ATC submission.

Exactly, and I also do not expect to fly it, so I don’t want it in my flight plan.

But my question is: Why does deleting NUK25L in the SimBrief flight plan make SimBrief change the altitudes along T204 resulting in a flightplan that will not validate with IFPS?

Hi, there is no one simple answer to your question unfortunately. This is just a fringe case that has a lot of factors at play, leading to different altitude profiles for seemingly small differences in route/options.

This is because NUK25L is an RNAV transition, but it shows up in the AIRAC database the same way a STAR would. IFPS won’t recognize it but SimBrief doesn’t know that based on the AIRAC alone. Simply removing it when validating IFPS (or removing it from your route entirely) is the way to go.

That’s a bit complicated. The AIP says that the segment IVDUF T204 ABLOX is capped at FL315, however the rest of the airway is not. Stepping down for such a short leg isn’t really feasible, but if your cruise altitude before IVDUF is low enough, SimBrief may still attempt it. In other words, it may or may not step down depending on many factors, including your weight, optimum cruising altitude, distance from TOD, etc.

Adding NUK25L adds 54 nm to your route distance, effectively shifting your TOD by 54 nm. That’s the main reason you’re seeing such a difference I think.

The early step-down at BEFRE in your second route is due to a user-submitted route. Basically, an authorized user with access to the SimBrief routes database (normally a VATSIM/IVAO controller or real-world dispatcher) manually capped the entire T204 airway at FL300, likely to avoid the yo-yo step descent/climbs. But for this route I guess IFPS wants you above FL300 over BEFRE. When you add NUK25L, the user-submitted restriction is no longer considered (since you’re on a “different” route), so SimBrief instead descends as per the AIP over IVDUF (or doesn’t, as described above).

(I’ve added another IFPS compliant route to the database for this city pair, so the T204 cap should be fixed now).

As a final note, the IFPS validation button on the Flight Options page should be considered an estimate only. The flight profile (TOC/TOD and altitude optimization) isn’t fully calculated like it is when you actually generate the OFP. It’s a useful tool, but you may find that in such fringe cases you’ll get a more logical altitude profile when you actually generate the flight.

Hope this helps,

Thank you for your detailed response, crystal clear. Now I understand how these things can happen and what to look for next time I end up playing whack-a-mole with IFPS violations!

1 Like

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.