Originally Posted by
BraceBrace
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.
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.