PPRuNe Forums - View Single Post - Derate vs ATM
Thread: Derate vs ATM
View Single Post
Old 13th May 2018, 03:37
  #28 (permalink)  
john_tullamarine
Moderator
 
Join Date: Apr 2001
Location: various places .....
Posts: 7,185
Received 94 Likes on 63 Posts
I haven't played with the device in question so my comments can only be generic.

One of the problems with the various first principles computer calculations is that you can get some "strange" results (with our pilot hats on) on occasion, eg with integer temperature increments there can be considerable head scratching variations in the speed schedule with quite small temperature variations. Also, the reduced thrust technique is a little different for EPR and N1 engines so that may introduce some head scratching (I am presuming that you are looking at an N1 thrust setting ?).

These sorts of observations are an artefact of the systems being used and one just has to live with them - a small penalty to pay to get the last few kilos for the takeoff calculation. It used to be a lot easier to see what was going on with the older AFM chart presentations but one had to accept that these were conservative and simplified to make them workable. Nowadays, the mighty bean counter driven dollar on the bottom line is the be all and end all.

Several comments -

(a) while the cited TODR1 delta is a bit eyebrow raising, we would need to know some details of how the program approaches the problem to make much sense of things. That detail should be in your manuals for the box. V1/VR protocols are the main concern I can see, as other posters have cited.

(b) How come we need a longer distance engine inop go with FULL than ATM Not enough information for me to hazard a call on that. However, book distances are very sensitive to V1/VR ratios so that may have a role to play here ?

(c) This is a mistake, sorry. A lower V1 gives a longer, not shorter, accelerate-go distance You might like to revisit that comment ? ASDR will reduce, TOD1 will increase

(d) I don't think V1 as an importance V1 (ie V1/VR ratio) is extremely critical to what distances might fall out of the sums.

(e) Take off run is assumed to be with all engines operating until V1, from V1 to V2 with one engine inoperative and as such reduced acceleration. Do be careful. There are two separate calculations involved - take off distance and take off run. Best not to mix one with the other.

(f) the all-engine go distance is longer than the inop go distance. Does that make sense to you? Doesn't to me The calculations are different - TOD2 is factored. Whichever case gives the critical distance will be longer on the day.

(g) Boeing says FMC gives speed for a balanced field performance BFL is useful for manual calculations which need to be done in a hurry. For the computer case where the takeoff is to be optimised on a first principles basis, BFL (as a policy) makes no sense ? As to what the aircraft FMC might be able to do will depend on how it is designed and how the operation is conducted.

(h) So technically the shortest go distance would be achieved by TOGA until vr then chop thrust to give zero acceleration, rotate and climb to 35ft at vr. Then accelerate. Pointless information! I don't think this post makes much sense at all ?

(i) The ASDR are always longer than the Engine inop go distance (unbalanced field) While I can't comment for the particular aircraft, the statement generically is incorrect. Run V1/VR down and ASDR decreases while TOD1 increases. Which is the greater and where the two might cross will be Type and runway dependent.

(j) There is definitely something not logical with the software Not necessarily the case. It all depends on how the program logic is set up. Each calculation will be from first principles and, depending on what the logic might be, there might be little or no relationship between one calculation case and an adjacent set of data calculations.

(k) but here the clearway is 190 m and the stopway 60 m.. If the calculation is optimised, that might well give you a significant difference to the BFL simplified calculation
john_tullamarine is offline