Can we keep it simple and state that the answer to the question is: not required (not sure how you would get an increase of 5°C in the time frame between perfo calculation and actual takeoff). If you have time available, you're not doing any harm by recalculating. Just use common sense. Can we agree we don't fly on the limits, but we fly safely around in a world protected by safety margins?

If the question is about "optimum" performance, that's not a question to be discussed on the flightdeck by pilots. Because my initial question would be "optimum what?". Assumed temps were introduced for maintenance purposes. So what are we optimizing? (don't worry, I'm NOT looking for an answer here)

What's the point of a 1kts Vr increment, if 99% of the pilots don't call out the rotate at the exact speed? The world is human. Let's keep it human. Not robotic, nor autistic.

I probably didn’t express myself correctly, and I would definitely hesitate to question your expertise.
But I have always read it as: Assumed/FLEX will set the power for that temperature. If the actual OAT is lower, as it should be, you will have an additional margin. If the OAT rises, that margin will decrease, but up to OAT reaching FLEX your FLEX power setting should be safe to use. You say that there would be no extra margin because the calculation takes OAT into account, and if OAT rises you would have to do a recalculation. I obviously understand that you are correct if there is no extra margin, so will go back to my books.

Books tell you nothing more than what I have produced already. OAT and wind intersection gives you MTOW which will decrease if OAT goes up. But many times it's beyond structurally limited wt. When you want flex you enter wind find ETOW then on the left you get flex. There's no OAT column. Which is checked later against flex. No performance document tells you to recalculate performance with OAT rise.

I guess by now we are all on the same page when it comes to temperatrue.

What about a change in QNH? In the past manuals there was a flow chart like the one posted by Vilas in #36 under the Performance chapter that say up to 2 hpa drop there's no need to recalculate our performance but that has since been removed since the introduction of Flysmart.

In theory, any reduction in pressure reduces aircraft performance so we recalculate for any pressure drop. Is that what everyone out there is doing?

Never saw any such rule to ignore changes. Also makes no sense, the manufacturer provides a method how to calculate what needs to be found. Not a cookbook how to bend the input data.

What the operator writes in their manual are different RoE.

There are some embedded allowances and getting picky about 0.25 hPa is unnecessary. Namely so as there are several Pandora's boxes - who supplies the operator with obstacle data and how often those are updated is an example one not in a plain sight.

A severe practical problem lies where to draw the line how much of wrong is acceptable. Now and then something leaks that sounds rather silly, and while you can appreciate the effort there cannot be any points for trying.

Happy new year, safe skies and jolly arrivals!
​​​​​​

We recalculate if the data we used changes by more than 2hPa, 2 degrees C, any increase in TW, 5 kts HW.

Using Boeing Performance app.

Paraphrasing the PPRuNe's all time classic: Tell me, please, which airline you fly for so that I can apply with them in the future!

:ok:

Why with variation of 2hPa when chart gives you a block of 10hPa?

Because in many companies the Boeing performance application is the primary tool. Hardly anybody uses tables anymore. It's not because the table works in 10hPa blocks, it is "the" way. It is "a" way to calculate.

I was just trying to show it doesn't make a difference. Even in Airbus it's computerised and as I said in my first reply it hides the process and just gives magic numbers. The process shows you that rise in OAT or change in QNH doesn't compromise anything.

The rise in temperature is connected to the assumed, and therefore there is a performance margin. If it turned out to be a performance limiting takeoff, the question would not be asked, it would be visible as the temperature would rise above the assumed temperature. With a different QNH this is not that visible. The 10 is an arbitrary number. You cannot simply ignore.

I understand and agree on your reasoning in performance cases with large assumed temperatures. But there are also many takeoffs done close to the limit performance. And basic rules have to cover all situations.

Previously Airbus had limitation on flex temp being higher than OAT by 6° or 9°C to avoid a situation where during taxiing the OAT could rise above flex. But Airbus removed that after it carried out a mod by which if that situation arises then then on setting flex pilot is warned to set TOGA and if not done TOGA is set automatically. As far as QNH is concerned it's corrected in blocks of 10hPs and not interpolated so it's not that critical

Entirely different opinion on that, both accounts.

It’s just the policy we have. I assume it’s more to do with whatever optimisations they’re favouring.

Hey FD, trust me, some of things we do is just to prove that re-inventing the wheel, and making it worse, is possible..:p

IMPRECISE ACCURACY

This thread has shown some clear differences in attitude to routine ops. The OP outlined the scenario of a FLEX departure and a subsequent small rise in actual OAT used initially. Many of the posters have outlined the inherent "buffers" which are already used in the calculation ( esp. Villas ) Since the common use of EFBs for calculations it seems that many people get hung up on spurious accuracy which these will show. By that I mean : How accurate is the loadsheet really - assumed weights plus look at the amount of hand luggage regularly carried. How accurate is the fuel on board actually - sure the gauges read to 10 kgs but what is their accuracy levels really.? How accurate has the runway line-up been done - did you definately not cut the corner on line up to get away quickly? On hot days - how much warmer is the air above the runway versus the ATIS value used? Is the wind component accurate ( sure it is factored but what if zero wind was used)

The buffers are build into the software for good reason - do not assume that implied extra accuracy is there just because the EFB is used and if minor changes produce critical situations then perhaps FLEX is inappropriate?

Computing 101: accurate data in - accurate data out.
less than accurate data in - dubious result out

Oh, well. .... even better: A familiar environment! :E

Adding to say that I can see the truth in the last vilas' post but the explanation would be based on a very different set of arguments in my class.

Meikleour On the level this discussion rose up to, we don't say the EFB SW has inherent buffers. There are some inherent buffers in the algorithm and mathematics behind it, and the SW does not introduce any more margin to it, if anything the contrary is true. Don't wish to rehash what's been said, just pointing out that beyond a specific moment the terminology requires accuracy too.

Whether or not the pilots strive to achieve numerical precision, when and why is that a void effort is perhaps best debated with clear distinction. I suppose people who know how to apply the results safely in daily ops and can zoom out their attention might find the mathematics irrelevant to discuss at all, however, please understand the noise thereafter makes listening to the fine tunes very difficult for the likes of A.W. As well for the original OP, who got laughed at first yet no explanation was provided until 2 years later. Well, except for being told effectively his attention to that particular detail was superfluous.

In more succinct terms - measuring with a micrometer and cutting with an axe.

measuring with a micrometer and cutting with an axe.

This has been a major problem since we obtained general access to digital computers spitting out answers to a precision of a squillion decimals but still maintaining a reasonably realistic accuracy of real world figures. Aircraft weight and cg is my favourite - I see numbers to a precision of, say, 2 or 3 decimals where the accuracy is still, maybe, a quarter inch or worse (on a good day).

Especially with younger folk, GIGO is a real hazard across the board.

Truth...?

Lesson nr 1 I was taught starting left seat upgrade: the only truth there is in aviation is the truth of numbers, and the ability to explain those numbers black on white if something happens and questions are posed. Fixed numbers are ie limitations. Offices don't care, you do what you want if all goes well. But if you venture into the world of limitations and decide to "neglect", you give somebody a hammer to slam if something ended up not so well. If you want to "taste" it, have some SAFA inspections. They will kindly tell you the importance of 1kg if it’s written on a paper somewhere.

The question was about temperature, that's pretty visible because assumed is a temperature. Other influences... as long as I'm sure I'm not busting a limitation, fine. But when it’s not clear I prefer to set my ego aside and do a quick recalculation. No harm done. Calculate, store, get on with life.

Ps: we have no rules on the subject. Stay out of the office is the main goal (and those people do like clean safa reports to...)

The ATM that is applied is valid, so long as the actual temperature doesn't exceed the assumed temperature. The crew are finding the limit case for the weight they are at, therefore as far as runway performance goes, they are hot to trot. However.... the V speeds should be recalculated if a significant change occurs. At least one airline gets around that by using the V speeds for the limit case... can't say I really like that concept. The company flight ops engineering or performance team can conduct a sensitivity analysis and make a determination as to when they wish the V speeds to be corrected to match actual conditions or not.

...

As to concerns that a pilot may ask for guidance on the subject, I personally am comforted that they would do so. Having an uncertainty in what is necessary is a troubling situation to find yourself in. Performance is bad enough without having some means to get a better comprehension than an airline and national licensing system may achieve. I do performance flight testing in R&D, and I end up asking questions also...

Boeing's performance manual, the Performance Engineers Manual, or Jet Transport Performance methods, should be mandatory reading for anyone with a Part 25 rating... so should the USNTPS FTM-108 Fixed Wing Performance and FAA AC 25.7D, Flight Test Guide for Certification of Transport Category Airplanes. Airbus's performance is a dark art...


JTs comment is on point, having a cognitive awareness of the situation saves a lot of heartache, like the bingle of the B742F at Halifax NS. The more we go towards a computer solution, the greater the chance of a gross error leaving bits of tin around the end of the paddock. Having a conceptual understanding of what the numbers means will assist in recognition when things are not quite as expected. Recall, that to be airworthy, the aircraft must conform to its TCDS as a part of its requirement , and the other is that it must be safe to fly, whatever that may mean. The TCDS includes the basis of certification that includes the AFM which has the legal TO performance requirements. Much performance is guidance material only and not certified, but TO performance is not subject to negotiation.

On a different point.

My operator hasn’t allowed us to update to iPadOs 16 yet. Are there other operators with this?
If so, anybody got any idea what the holdup is?

Usually it’s the authors / owners of the software suites that need to approve the upgrade. They aren’t usually very fast.

Why? History has proven completely opposite is correct. We think we can do better. Usually we can’t. Computers can be tested on the ground under pressure and they will handle complexity in a consistent way. Humans need simplicity, and even then won't survive under pressure.

it’s approved with my mob so not sure what the holdup is with yours.

I checked on EFB OAT 20 ° flex56°. With change of OAT by 5° to 25° there was no difference in speeds nor flex. Change of QNH by 4hP didn't change them either.

iOS 16.1.1 was finally cleared for use in mid November. There were some holdups with compatibility.
You might have some other managed apps on there that are incompatible. .

Do you mean because of adding more OAT means nothing because you're assuming the maximum already?

As far as I am concerned and some have mentioned already, beyond a certain temperature flex will keep going down due to performance limitations and before that point it won't matter if it goes down.

There's no stupid question and certainly this is not.

Change of temperature changes your performance. Always do another one, or do the initial performance anticipating this increase in temperature. Too little thrust is never good.

You might want to read the thread first.

well, you don’t even need computers for that, paper manuals can do it too. Ours are translated into American, and so I have to deal with limitations like max landing weight of 145,505lbs. Pretty sure there’s a reason AB rounds all of those weights to a number ending with a few zeros……

Are companies still using RTOW charts?

Last airline I flew with printed a set of performance data for different runways and conditions. The crew requested actual performance numbers via ACARS from the performance service provider and compared those with the paper numbers. So long as the actual temperature and pressure didn't deviate by a certain tolerance from the paper numbers the plane was good to go.

What I found more concerning was the tiny margin on some of those calculations. Some calculations had less than 100m runway remaining. That's not much room for error.

Charts and tables give a rough order of merit to a calculation, computer programs like calculators, smartphone apps etc give numbers, which are perfect when no error occurred in the data entry. Human nature is to err, and some software packages had processes that occur that were not within the crew awareness, and can result in catastrophically erroneous output. Anyone using a calculator should have a rough idea of what the aircraft will do, what the speeds are likely to be and same for thrust setting etc. On occasions, you can also get paradoxical outcomes for surprising reasons.

Poster child was the B747-200F at Halifax, worth a read of the accident report.


A comment previously in this thread by a pruner, was related to N1 vs temperature, and the statement made needs to be qualified.
As temperature rises, N1 increases to achieve rated thrust UP UNTIL CRITICAL TEMPERATURE, thereafter N1 will decrease, and the engine will no longer make the rated thrust, it is limited to the thrust for the temperature, (you can do the simple maths on density ratio to work that reduction in thrust achieved out).

Depending on your software, caution may be needed with environmental temperatures below CT, and applying an assumed temperature above CT. If the temperature is extremely cold, the N1 to achieve the full rated thrust may be say, 88% N1, but a temp around say, CT+10C may be give the hot day limit weight you are trying to determine the limit for, and that may have a higher N1 than the actual temp full thrust N1 case. If you use say 98% N1 with an engine that achieves full thrust at 88%, you are in fact over boosting the engine, and not by a little bit, that is a biggly baddie.

Another set of issues arise when the computer analysis uses a balanced field solution for the output. This one can be a real pain, makes it good to have the standard charts on hand. Say you are taking off on 25L at VVTS, and you use half the runway to get to 35', you might be surprised that there is an obstacle limit weight that comes into play, when the nearest tall buildings are about 10 miles off the centerline, and no close in obstacles actually exist. Landing from the other direction, 07R, there is an ILS, and there is no building that you have to fly through to land, or power line or tree to dodge, but there is a small obstacle, within the splay, well past the end of the TODA, and that becomes the obstacle limit problem. The fact that you will be at 35' 1/2 way down the runway, and will have an extra mile or more to go to get to an obstacle that insults the OCS is discounted, and a restriction applies. Insanely, cutting back the runway length with this particular software, which should give a new supplemental takeoff distance and OCS to the object eventually did achieve that, so cutting back the revised software package would remove the obstacle, and increase the departure weight.

IMHO, and coming from a performance flight test background, around 5% of all takeoff charts that I get to analyse have oddities that arise, items where the answer that is given doesn't match reality. It is always the case that these anomalies are more limiting than the true condition that would be achieved by doing a full analysis.

Computer output quality matches the input and the calculation algorithms.

With the plethora of what is called information but which devolves into white noise during most preflights, little gems like runway length reductions etc are a major cause of non compliance. A takeoff using the wrong runway length will give the operator hours of fun working out how such a thing can happen.

Interesting as always, fdr. Thank you. I have not come across critical temperature of a jet engine before wrt performance calculations. Where would I be able to find what it is for a Trent 1000 and is it variable or fixed?

I routinely see stop margins of 1m. Provided the difference between flex and actual temps is high it's not a problem.

Engines are generally rated for full thrust at "ISA+X" - where X is somewhere between 10 and 25 degrees C. Since ISA drops with altitude, the flat rate temperature will be less at altitude than at Sea Level. Above the flat rate temp, the max rating will decrease as a rate that gives a roughly constant EGT as the OAT increases.
It is also common that the flat rate for Takeoff - max five minutes (sometimes 10 minutes) is higher than for continuous operation - e.g. Takeoff might be IAS plus 20, but Max Con might be ISA plus 10.
I'm afraid I don't know what the numbers are for the Trent 1000 - your operations types should know (and it should be in the flight manual).

how many accidents, or near-accidents, in Airbus history, have occurred because of a change in air temperature.

Airbus has warning if Flex goes below OAT. And in eight seconds if you don't set TOGA it sets automatically.