TASOPT 2.16 User Guide 9 Nov 2016 Mark Drela, MIT Aero & Astro Introduction ------------ TASOPT (Transport Aircraft System OPTimization) is a program for optimizing the airframe, engine, and operating parameters of a wing+tube transport aircraft. A complete documentation of the physical models implemented in TASOPT is given in the various PDFs in the doc/ directory. See file doc/README for a list. A recent application of TASOPT has been for the NASA N+3 program, whose Phase I finished in April '10. All the team reports and final presentations are here: http://evt.grc.nasa.gov/sfw_n3/main/presentations/ Compilation ----------- TASOPT is written in Fortran 77. See README file in this directory for build instructions. Quick start ----------- The directory runs/737 contains a number of sample input files for the Boeing 737-800. See file runs/737/README for a list of the cases and how to execute them and plot the results using MATLAB and Gnuplot. Execution --------- TASOPT is executed with the xxx case prefix given as an argument: % tasopt xxx A second argument can also be given % tasopt xxx yyy which specifies a yyy.sav file. The yyy argument is rarely used, and may be phased out in future TASOPT versions. Operation Summary ----------------- TASOPT Actions: 1) Reads and processes input file xxx.tas 2) Writes output to file(s) xxx.out if no i,j looping is specified or xxx_iNN.out if only i looping is specified or xxx_jMM.out if only j looping is specified or xxx_iNN_jMM.out if both i and j looping is specified where "NN" and "MM" are the specific i,j values. File outputs can be suppressed by setting flags in xxx.tas . 3) Writes plot-data output to files xxx_1.plt contains Matlab plot titles xxx_2.plt contains Matlab plot data xxx_3.plt contains Matlab airplane stick figure data xxx_g.plt contains Gnuplot airplane stick figure data The plot-data files are intended for plotting using the Matlab scripts apl1.m apl2.m apl3.m apl4.m Input Files ----------- 1) xxx.tas This is the main TASOPT input file. The "xxx" is an arbitrary case string. Example .tas files are given in the runs/ directory, in the following subdirectories: runs/ 737 ; Boeing 737-200 and -800 777 ; Boeing 777-300 D8 ; D8.x aircraft from N+3 project D12 ; D12.x aircraft from N+3 project All the sample input files are heavily commented. All data after a "!" is ignored, allowing inline comments and labels. The data labels closely match the TASOPT theory documents, so the sample files are effectively self-documenting. For these reasons a listing of all the parameters in the .tas file will NOT be given here. The excuse offered here is that such a list would be mostly superfluous (it's easier to just go to the file), and it would also be one more thing which needs care and feeding to keep up to date. 2) aaa.air This is an airfoil-database file, whose filename is specified in the xxx.tas file. This filename is arbitrary, although the .air suffix is suggested. The following .air files are provided in the runs/air directory: B200.air ; Relatively old Boeing 737-200 airfoil family. All turbulent. C.air ; Basic modern transonic airfoil family. All turbulent. Cl.air ; Same as C, but with laminar bottom to about 65% The C.air file is recommended for typical transport aircraft. The polfit/ directory has program POLFIT, which was used to create the .air files from MSES polars. See file polfit/README for more info. 3) xxx.tase This is an optional file with altitude, Mach, and thrust-fraction values which TASOPT uses to compute the corresponding engine-performance matrix. This file contains three numerical data lines, with each line containing one or more numbers. For example: Alt1 Alt2 * 0.3048 Mach1 Mach2 Mach3 Ffrac1 Ffrac2 Ffrac3 Ffrac4 Frac5 The "* 0.3048" at the end of the first line is an optional multiplier, described later. In this case it converts all the Alt_ altitude values from feet to meters, which is the required input unit. Blank lines, and lines beginning with "#" are ignored. All characters after a "!" character anywhere in the line are ignored. The engine performance matrix for the example three data lines above will have 2 x 3 x 5 = 30 operating points specified by the data values. These will be written to the output file xxx.oute , with the following nested ordering: Alt1 Mach1 Ffrac1 Ffrac2 Ffrac3 Ffrac4 Ffrac5 Mach2 Ffrac1 Ffrac2 . . Alt2 Mach1 Ffrac1 . . These operating points are computed after all other sizing and/or optimization calculations, described in more detail next. Run types and output files -------------------------- A TASOPT run can be one of four possible types: 1. Single point, sizing only. Runs in less than 1 second. 2. Multi point, sizing only. Runs in 5-10 seconds. 3. Single point, sizing + optimization. Runs in 2-5 minutes. 4. Multi point, sizing + optimization. Runs in an hour or more. For the single-point run types 1 or 3, the main output filename is xxx.out For the multi-point run types 2 or 4, the main output filename is one of the following xxx_iMM.out if "i" parameter is varied, MM = 01, 02, 03 ... xxx_jNN.out if "j" parameter is varied, NN = 01, 02, 03 ... xxx_iMM_jNN.out if "i" and "j" parameters are both varied The run type selection is specified in the xxx.tas file as follows: * Single-point vs Multi-point A multi-point case occurs if there is at least one numerical value given after the "i" and "j" parameter keywords. To illustrate, compare the single-point and multi-point setups in the runs/737 directory: % diff 737s.tas 737m.tas * Sizing only vs Sizing+Optimization Optimization is performed if Lopt=T is specified. It's also advisable to disable the weight-iteration info if optimization is selected. To illustrate, compare the setups with and without optimization in the runs/737 directory: % diff 737s.tas 737so.tas Single vs Multiple Missions --------------------------- The term "point" above refers to a point in design space, so that a "multi-point" run considers a sequence of aircraft all of which are physically different. TASOPT also allows any of these distinct "point" aircraft to be operated over multiple missions, each having a possibly different value for the following parameters: off-design range (i.e. less than maximum) off-design payload (i.e. less than maximum) takeoff altitude (e.g. high airport) takeoff temperature (e.g. hot day) A collection of such missions for one aircraft is called a "fleet". TASOPT has the ability to optimize fuel burn which is a weighted average for a fleet rather than just for the design-point sizing mission. The number of missions and their optimization weights are both specified by the following data line, shown in two versions a) and b), taken from the sample .tas files: a) 1.0 ! 0.0 0.0 0.0 ! mission-averaging weights for total fleet PFEI b) 0.2 0.4 0.2 0.2 ! mission-averaging weights for total fleet PFEI Example a) specifies only one mission, since the values after the "!" are ignored and effectively absent. Example b) specifies four missions in the fleet, with the fuel-burn optimization weights given. The five data lines which follow the line above then give the parameters for all four missions: 3000.0 2142.0 633.0 347.0 * 1852.0 ! Range(.) [m] 180 150 180 120 ! Npax(.) number of passengers 215.0 215.0 205.0 200.0 * 4.45 ! Wpax(.) PAX weight (including baggage) 0.0 0.0 0.0 0.0 * 0.3048 ! altTO takeoff/landing altitude [m] 288.0 288.0 288.0 288.0 ! T0TO ambient takeoff/landing temp [K] The first number in each line is taken as the design mission which sizes the aircraft, so that it must have the largest range and/or payload specified. Output files ------------ 1) File xxx.out or multiple-point variants as described above. This is the main TASOPT output listing file. It has a number of sections and sub-sections, with the following headers shown below. The "Fleet mission 1" section would be repeated if multiple missions are specified. ============================================================= TASOPT v 2.06 ----------------------------------------------------------- Config: 737-800 ----------------------------------------------------------- Airframe parameters... ============================================================= Fleet mission 1 ----------------------------------------------------------- Cruise performance... ----------------------------------------------------------- Takeoff performance... ----------------------------------------------------------- Mission profile summary... ----------------------------------------------------------- Aero, Engine parameters... - - - - - - - - - - - - - - - - - - - - - - - - - - - - - RO: Rotation... - - - - - - - - - - - - - - - - - - - - - - - - - - - - - TO: Takeoff... - - - - - - - - - - - - - - - - - - - - - - - - - - - - - CB: Cutback... - - - - - - - - - - - - - - - - - - - - - - - - - - - - - B1: Climb1... - - - - - - - - - - - - - - - - - - - - - - - - - - - - - B5: Climb5... - - - - - - - - - - - - - - - - - - - - - - - - - - - - - C1: Cruise1... - - - - - - - - - - - - - - - - - - - - - - - - - - - - - C2: Cruise2... - - - - - - - - - - - - - - - - - - - - - - - - - - - - - D1: Descent1... - - - - - - - - - - - - - - - - - - - - - - - - - - - - - D5: Descent5... These are self-explanatory. All numerical values in each section have labels which closely match the variable names in the documentation. For this reason, a complete listing of all the outputs is NOT given here, since it would be superfluous. The various RO:, TO:, C1: etc labels on each line give helpful data labels when searching the output file using grep. For example: % grep " FPR " 737s.out RO: FPR = 1.6514 TO: FPR = 1.6455 CB: FPR = 1.3442 B1: FPR = 1.6040 B2: FPR = 1.6114 B3: FPR = 1.6402 B4: FPR = 1.6609 B5: FPR = 1.6715 C1: FPR = 1.6500 C2: FPR = 1.6813 D1: FPR = 1.2972 D2: FPR = 1.2393 D3: FPR = 1.2319 D4: FPR = 1.1897 D5: FPR = 1.0687 This conveniently and clearly lists the fan pressure ratio values over the entire mission. Any other quantity of interest can be listed in this manner. NOTE: The xxx.out file generated by versions 2.15 and earlier also had the following four sea-level static thrust operating points. T1: 100% thrust... T2: 85% thrust... T3: 30% thrust... T4: 7% thrust... These have been eliminated since they can now be specified via the optional xxx.tase file, with the following three data lines: 0.0 0.0 1.0 0.85 0.30 0.07 2) Files xxx_1.plt, xxx_2.plt, xxx_3.plt These contain plotting axis labels, axis values, and plot data for the MALTAB plot scripts apl1.m, apl2.m, apl3.m, apl4.m See file runs/737/README for script execution examples. 3) File xxx_g.plt This contains x,y data for plotting a simple outline of the output aircraft. See file runs/737/README for more info. Units ----- TASOPT's internal Standard Atmosphere functions and fuel property tables return values in SI units. For simplicity, TASOPT is therefore set up to require all its inputs to be in SI units as well. For convenience, the routine which parses the xxx.tas file allows an optional multiplier or divisor at the end of each data line, for example: 33500.0 * 0.3048 ! altCR cruise-start altitude [m] This conveniently specifies a 33500 ft cruise altitude, and the " * 0.3048 " at the end converts this to meters as required. As an alternative, a divisor could also be used: 33500.0 / 3.28 ! altCR cruise-start altitude [m] Bit Precision and Convergence Tolerances ---------------------------------------- TASOPT is intended to be operated in double precision (64 bit arithmetic). For simplicity, this is specified by the appropriate compiler flags rather than in the code. Again for simplicity, TASOPT's iteration loops have hard-wired convergence tolerances using DATA statements, currently set to values which assume double precision operation. These are tolerances typically set quite tight. For example, the engine off-design routine TFOPER uses 1.0e-10, and the overall weight sizing routine WSIZE uses 1.0e-9. The reason for such tight tolerances is to ensure that the aircraft sizing outputs and in particular the fuel-burn and field-length function outputs appear very smooth in design space. "Noisy" outputs can easily confuse the optimization descent algorithm, which currently is the straightforward Simplex method, with the constraints implemented as one-sided quadratic penalties. Using the penalty approach means that the constraints will not be _exactly_ satisfied. For example, if a 5000 ft balanced field length is imposed as a constraint, the final output value might be 5030 ft or so, which is considered close enough. The "error" could be reduced by increasing the penalty weight, which is hardwired in array penfac() in subroutine fobj (in src/fobj.f). However, a larger weight may cause the Simplex algorithm to behave erratically near the constraint "wall", so this is not advisable. Another approach is to re-run the case with the constraint reduced by the error amount, to 4970 ft in the example above. specified result --------- --------- 5000 ft -> 5030 ft 4070 ft -> 5000 ft Optimization Variable Scales ---------------------------- The sample .tas files have the following lines which select the design variables (lines beginning with # or ! are comments): #- Variables to be optimized (if Lopt=T), and their initial perturbations #- Keywords are declared as array cparo , in index.inc #- A zero or missing perturbation value disables the optimization of that variable CL 0.001 ! cruise CL AR 0.05 ! overall aspect ratio sweep 0.025 ! wing sweep angle hboxo 0.00025 ! airfoil t/c at etao (wing root) hboxs 0.00025 ! airfoil t/c at etas (planform break) lambdas ! 0.001 ! inner panel taper ratio lambdat 0.001 ! outer panel taper ratio rcls 0.001 ! local cl scale at etas (planform break) rclt 0.001 ! local cl scale at 1 (tip) FPR ! 0.005 ! fan pressure ratio BPR ! 0.025 ! bypass ratio alt 10.0 ! start-of cruise altitude Tt4CR 0.5 ! cruise Tt4 Tt4TO 0.25 ! takeoff Tt4 OPR ! 0.05 ! overall pressure ratio (pilc assumed fixed) Each of these lines has the format variable_name [ perturbation_value ] [ * multiplier ] where the [ ] brackets indicate optional data. Each of these data lines is parsed as follows: 1) If Lopt = F, then all this data is ignored. 2) If Lopt = T, then... 2a) If the perturbation_value is present, then that variable is placed in the design variable set. The initial value for this variable is given elsewhere in the file. 2b) If the perturbation_value is absent (or commented out as above), then that design variable is NOT in the design variable set, but is instead held fixed at the value specified elsewhere in the file. Note that the perturbation_value is used only for case 2a). This is the initial step size away from that variable's initial value. So all the perturbation values in effect determine the overall size of the initial simplex (or sampling stencil) in design space. The Simplex algorithm will adjust the size and shape of this stencil as the optimization descent proceeds. The numerical perturbation value choices in theory shouldn't affect the final optimized result. However, they do affect the robustness and speed of the optimization descent. The tradeoffs are: * Larger perturbation_value: Pro: Faster initial descent Con: Larger sample steps may cause inner-loop calculation failure * Smaller perturbation_value: Pro: Less likely to cause failure Con: Slower initial descent Example: Failure may occur if the FPR perturbation value is too large. As the optimization proceeds, the optimizer might take an excessively large step in the direction of positive FPR, and increase it to the point where the core flow stagnates because of the excessive fan power requirement, forcing a program halt (see Hints and Troubleshooting below). A possible fix is to reduce the perturbation_value for FPR so that it can't "run away" too fast, at least initially. Hints and Troubleshooting ------------------------- TASOPT will sometimes fail to converge at one or more of its numerous internal iteration loops. Some possible causes and fixes are listed below. 1) The main weight sizing loop will not converge if the aircraft specification is physically impossible to realize. For example, if a 20000 nmi design range is specified for an aluminum aircraft, the sizing iteration will fail. It will most likely appear as an explosive growth in the maximum takeoff weight and overall size with each iteration, rather than the usual rapid convergence. This can be clearly seen if the iteration history output is enabled by setting Litprint = T. 2) The turbofan sizing or analysis calculation may result in a zero or negative core velocity, forcing the engine subroutine to stop. The most common cause is an excessive Fan Pressure Ratio together with an excessive Bypass Ratio, so that the fan requires more power than the core can provide. In reality the engine would "stall" or surge in this situation. The warning message just before program stop is the following: TFOPER: Convergence failed. iTFspec= 1 pt18 Tt18 = 0.10584E+06 292.03 pt2 Tt2 = 0.10584E+06 292.03 pt25 Tt25 = 0.21695E+06 366.61 pt3 Tt3 = 0.27460E+07 803.59 pt4 Tt4 = 0.25813E+07 1509.0 pt41 Tt41 = 0.24259E+07 1427.1 pt45 Tt45 = 0.59210E+06 1057.2 pt5 Tt5 = 0.10132E+06 725.22 p5 = 0.10132E+06 FPR BPR = 1.4522 8.7487 Fe = 0.0000 Failed on operating point 5: B1 "B1" is the first climb point. Note that pt5 and p5 (at core exit) are equal, so that the core flow has stagnated due to excessive power extraction by the fan. The only solution here is to reduce FPR or BPR or both, or possibly to increase Tt4 to increase the core's power. 3) The turbofan routine terminates during one of the descent mission points. Example: TFOPER: Convergence failed. iTFspec= 2 pt18 Tt18 = 31483. 245.05 pt2 Tt2 = 31483. 245.05 pt25 Tt25 = 47720. 279.67 pt3 Tt3 = 0.15011E+06 403.62 pt4 Tt4 = 0.14110E+06 403.62 pt41 Tt41 = 0.12832E+06 403.62 pt45 Tt45 = 30671. 279.68 pt5 Tt5 = 21213. 256.46 p5 = 20655. FPR BPR = 0.97818 11.479 Fe = -3139.4 Failed on operating point 12: D1 "D1" is the first descent point. The reason here is that the descent angle is excessive, requiring braking or negative thrust, with specified Fe < 0. The current turbofan model does not adequately model small reverse thrust such as might be obtained from a windmilling fan. The reason is that its loss calculations are based on efficiency, which becomes undefined and useless in the windmilling condition FPR -> 1. At present, the only workable fix is to specify more shallow (less negative) descent angles gammaDE1, gammaDEn. Future TASOPT upgrades might improve engine modeling in this regime to allow braking with the fan, or possibly allow for spoiler or other airbrake modeling in the descent. These would allow steeper descent angles without causing the engine routine to fail. 4) The specified design values for OPR,FPR,M2,M25 are imposed at the first cruise point. In general, they will be larger at the top-of-climb point, since that is a higher power flight condition. Hence, if the cruise fan-face Mach number M2 is specified too large, it is possible that the M2 value at top-of-climb will be too high, and may even try to exceed 1.0 which in general is not physically feasible ( the engine routine artificially limits M2 to 0.98 ). Hence, the top-of-climb engine parameters should be checked to see if they are still reasonable. If not, then the specified cruise values will need to be reduced somewhat.