Chaostheory wrote:

Pilots are conservative creatures and in the decades gone by where we did on occasion use charts, there was excessive rounding up and intercalation.

As much as we would like to have very precise data, my impression is that even using an app or other electronically calculated data, there is still conservatism factored into the calculations.

At many operators, passenger and luggage weights are still either estimated or seasonally averaged. In the event of a max gross weight takeoff, there is still margin built in to comply with all applicable requirements.

e38

e38 wrote:

Chaostheory wrote:

Pilots are conservative creatures and in the decades gone by where we did on occasion use charts, there was excessive rounding up and intercalation.

As much as we would like to have very precise data, my impression is that even using an app or other electronically calculated data, there is still conservatism factored into the calculations.

At many operators, passenger and luggage weights are still either estimated or seasonally averaged. In the event of a max gross weight takeoff, there is still margin built in to comply with all applicable requirements.

e38

Yes indeed. If nothing else the distances are factored as per regulation.

Starlionblue wrote:

e38 wrote:

Chaostheory wrote:

Pilots are conservative creatures and in the decades gone by where we did on occasion use charts, there was excessive rounding up and intercalation.

As much as we would like to have very precise data, my impression is that even using an app or other electronically calculated data, there is still conservatism factored into the calculations.

At many operators, passenger and luggage weights are still either estimated or seasonally averaged. In the event of a max gross weight takeoff, there is still margin built in to comply with all applicable requirements.

e38

Yes indeed. If nothing else the distances are factored as per regulation.

One thing electronic calculation does is it gives a flat "yes/no" answer and removes some ability to bend the rule(r) in edge cases. Using edge of a pencil mark instead of a center is a much smaller step compared to going back and re-typing a number.
And since success criteria is offen untestable (how many times did you have to check if there is actually enough runway after reject at V1?), bias can build up.


Coming back to "big picture", one thing that is obvious from the graph and maybe less so from the single point calculation - runway performance is more sensitive to weight at more challenging situations. For example, looking at a purple curve from Airbus graph I posted - going from 170 to 180 tonns at sea level barely changes runway reuirement, while going from 230 to 240 adds a good 20 %.
While some pilots believe this 20% shortfall can be mitigated by flaps extension by a notch or two, I doubt there is that much performance to spare. Hence the comment - a relatively small increase in MTOW by structural engineering without performance improvement can make chart look much worse - while it wouldn't change things much for "old MTOW" situation.

Airlines and pilots don’t do runway performance calculations, they do takeoff performance calculations.

Runway requirements are just one aspect that needs to solved for, specific climb gradients and obstacles for the given conditions and airport environment tend to be the real life limits experienced in an operational environment.

kalvado wrote:

Starlionblue wrote:

e38 wrote:

As much as we would like to have very precise data, my impression is that even using an app or other electronically calculated data, there is still conservatism factored into the calculations.

At many operators, passenger and luggage weights are still either estimated or seasonally averaged. In the event of a max gross weight takeoff, there is still margin built in to comply with all applicable requirements.

e38

Yes indeed. If nothing else the distances are factored as per regulation.

One thing electronic calculation does is it gives a flat "yes/no" answer and removes some ability to bend the rule(r) in edge cases. Using edge of a pencil mark instead of a center is a much smaller step compared to going back and re-typing a number.
And since success criteria is offen untestable (how many times did you have to check if there is actually enough runway after reject at V1?), bias can build up.


Coming back to "big picture", one thing that is obvious from the graph and maybe less so from the single point calculation - runway performance is more sensitive to weight at more challenging situations. For example, looking at a purple curve from Airbus graph I posted - going from 170 to 180 tonns at sea level barely changes runway reuirement, while going from 230 to 240 adds a good 20 %.
While some pilots believe this 20% shortfall can be mitigated by flaps extension by a notch or two, I doubt there is that much performance to spare. Hence the comment - a relatively small increase in MTOW by structural engineering without performance improvement can make chart look much worse - while it wouldn't change things much for "old MTOW" situation.

I don't see what the problem is. Either we can go or we can't go. The "shortfall" can't be mitigated by more flap extension. As Zeke says, the software is not only looking at the runway, but also at obstacle clearance and climb gradients.

We can't just extend more flap. The app spits out a flap setting. Sure, we can force a flap setting in the software, but that won't improve matters in edge cases.

Setting something different from the calculated data is a very bad idea.

Those documents and graphs are not performance planning docs, just an idea of what might be expected performance. Lots, LOTS more goes into the performance planning than is shown in ACAPS.