Rds Win P Manual

You might also like

Download as pdf or txt
Download as pdf or txt
You are on page 1of 189

…Industry Methods, Industrial Strength

Version 10 User’s Manual

Conceptual Research Corporation


PO Box 5429, Playa del Rey, CA, 90296
www.aircraftdesign.com

This RDSwin user’s manual is also provided as a PDF file, callable from the program’s Help pulldown menu. It opens
in a separate Window using whatever program your computer has set to open PDF files.

The RDSwin–Professional computer program, its unique methods and design approaches, all accompanying images
and text files, this User’s Manual, and any translations of this material, are all:

Copyright © 2017 by D. P. Raymer ALL RIGHTS RESERVED


No part of this publication may be reproduced, distributed, or transmitted, in any form or by any means, or stored in
a database retrieval system, or posted on the Internet, without prior written permission of Daniel P. Raymer.

i
RDSwin–Professional
You should carefully read all of the terms and conditions of this agreement prior to opening this package. If you do
not agree to the terms, return the program unopened for a prompt refund. If you open the package we will assume
you have read, understood, and agreed to our warranty terms.

LICENSE AGREEMENT AND DISCLAIMER OF WARRANTY:


This license agreement replaces and supersedes any and all other agreements, explicit or implied, concerning this
product, including any terms and conditions attached to or included with the payment for this product, unless such
terms have been agreed to in writing, signed by an officer of Conceptual Research Corporation.

1. Conceptual Research Corporation and Daniel P. Raymer ("the purveyors") provide this documentation and the
accompanying diskette and/or digital product transmission for use "as-is" and without any expressed or implied
warranty as to accuracy or fitness for any use. The purveyors do not warrant or guarantee the use, or the results of
the use, of the software or documentation in terms of correctness, accuracy, reliability, currentness, merchantability,
or fitness for any purpose, and assume no responsibility for errors, omissions, or damage, including without
limitation damages caused by the use of this computer program or from the use of information contained therein.
The entire risk and performance of the accompanying software is assumed by the user. In no event shall Conceptual
Research Corporation, Daniel P. Raymer, or anyone else involved in the creation, production, distribution, and
support of this software be liable for direct, indirect, special, or consequential damages, nor for any costs or expenses
associated with implementing the software to perform any specific purpose, nor for claims by you based upon third-
party claims. Conceptual Research Corporation warrants the program and the electronic media on which the
program may be provided only to be free of material or software defects that would prevent loading the software on
the user's computer system and running the program, at time of licensing. NO OTHER WARRANTY,
REPRESENTATION, OR CONDITION IS EXPRESSED OR IMPLIED.

2. This software is licensed SOLELY for use in aircraft conceptual design, and may not be used for final design or
analysis of existing, modified, or new actual aircraft, including but not limited to the prediction of aerodynamic,
weight, propulsion, stability, cost, range, and performance characteristics. No data produced by this software may
be used for prediction of flight characteristics of actual aircraft, and this software may not be used to produce flight
handbooks or any other information to be used for flight of actual aircraft. Purchaser assumes the liability for the
unauthorized use of software results as described above by third parties to whom the purchaser has provided such
results.

3. The original purchaser may make backup copies of the software as needed, which may not be sold, rented, lent,
or in any other way transferred to another person or organization. Any attempt to defeat the software unlock code
protection system incorporated with the software is forbidden.

4. Please note that if this software is licensed for use by or on behalf of a unit or agency of the United States
Government, this license agreement still applies in full. RDSwin was developed without government funds at private
expense and in all respects is proprietary data copyrighted solely to Daniel P. Raymer.

If you are unable to accept the RDSwin–Professional usage agreement please contact Conceptual Research
Corporation prior to opening this package

ii
TABLE OF CONTENTS
INTRODUCTION .................................................................................................................................................... 1
WHAT’S NEW IN VERSION 10 .................................................................................................................................. 3
RDSWIN-PRO OVERVIEW ..................................................................................................................................... 4
PROGRAM ORGANIZATION AND MODULES .............................................................................................................. 5
RDSWIN DESIGN EXAMPLE: RAYMER’S V-GULL ...................................................................................................... 8
RDSWIN OPERATION NOTES ............................................................................................................................. 15
INSTALLATION AND STARTUP ................................................................................................................................ 15
INSTALLATION ISSUES ........................................................................................................................................... 16
FUN STUFF – BACKGROUNDS, COLORS, AND SOUNDS ........................................................................................... 17
COMMANDS AND DATA INPUT............................................................................................................................... 18
Pulldowns, Prompts, and Picks, ....................................................................................................................... 18
Ghost Menu ...................................................................................................................................................... 19
Input Grids for Analysis Data........................................................................................................................... 19
Smart Data Input – the Amazing ParseVal Routine ......................................................................................... 21
Mouse Operation .............................................................................................................................................. 22
JoyStick Operation ........................................................................................................................................... 23
DRAFTING ............................................................................................................................................................. 24
GRAPHS ................................................................................................................................................................. 25
MAKING SQUARES SQUARE................................................................................................................................... 26
LIST AND PRINT TEXT FILES.................................................................................................................................. 27
UNITS AND CURRENCY .......................................................................................................................................... 29
USEFUL TOOLS FOR DESIGNERS ............................................................................................................................ 30
CURVE FIT TOOL FOR CREATING STATISTICAL EQUATIONS .................................................................................. 30
FILE NAMES .......................................................................................................................................................... 31
CUSTOMIZING RDSWIN-PRO ................................................................................................................................... 32
LIMITATIONS AND ASSUMPTIONS .......................................................................................................................... 34
BUGS AND BOO-BOOS ........................................................................................................................................... 35
DESIGN LAYOUT MODULE .............................................................................................................................. 37
DLM OVERVIEW ................................................................................................................................................... 37
DLM OPERATION .................................................................................................................................................. 38
DLM COMPONENT GEOMETRY ............................................................................................................................. 40
NON-PLANAR, NON-PARALLEL CROSS-SECTIONS................................................................................................. 49
DLM AXIS SYSTEM AND SYMMETRY .................................................................................................................... 51
IMPORTED STL COMPONENTS ............................................................................................................................... 54
COMPONENT SELECTION FOR VIEW AND EDIT ...................................................................................................... 55
VIEWING YOUR DESIGN ........................................................................................................................................ 56
FlyView ............................................................................................................................................................. 59
Relative Viewing ............................................................................................................................................... 61
Relative Views with Overlapping Airfoils or Sections ...................................................................................... 62
Render – Hidden Lines and Shading ................................................................................................................ 62
View Cross-Section Cuts................................................................................................................................... 66
Underlay Image ................................................................................................................................................ 69
NEW COMPONENT CREATION ................................................................................................................................ 69
Wing/Tail Creation ........................................................................................................................................... 71
SCALE COMPONENT .............................................................................................................................................. 75
SHAPE COMPONENT .............................................................................................................................................. 75
Fixing the Reference Trapezoid Wing or Tail (-Pro only) ................................................................................ 79
Shape One Cross-Section ................................................................................................................................. 80
Shape Cross-Sections by Longitudinal Lines .................................................................................................... 84
COMPONENT INSTANCES (-PRO ONLY) .................................................................................................................. 85
ASSEMBLE COMPONENTS ...................................................................................................................................... 85
DragAssemble ................................................................................................................................................... 86

iii
FlyAssemble ...................................................................................................................................................... 86
UNDO AND REDO................................................................................................................................................... 88
DESIGN FILES & GEOMETRIC ANALYSIS (TAB FILE) ............................................................................................ 88
DESIGN EXPORT (-PRO ONLY) ............................................................................................................................... 91
FUNCTIONAL ANALYSIS MODULES ............................................................................................................. 96
FUNCTIONAL ANALYSIS OVERVIEW ...................................................................................................................... 96
AERODYNAMICS .................................................................................................................................................... 98
WEIGHTS ............................................................................................................................................................. 105
PROPULSION ........................................................................................................................................................ 108
AIRCRAFT DATA FILE..................................................................................................................................... 111
THE HEART OF RDSWIN IS A FILING CABINET ....................................................................................................... 112
WEIGHTS & MISC AND MUCH MORE .................................................................................................................. 114
T/W AND W/S (OR THRUST AND WING AREA) .................................................................................................... 116
ENGINE DATA – THRUST AND SFC ...................................................................................................................... 119
ENGINE DATA – PART-POWER SFC AND PART AB ............................................................................................. 122
ENGINE DATA –MINIMUM THRUST ..................................................................................................................... 123
AERODYNAMIC DATA ......................................................................................................................................... 123
AIRCRAFT DATA FILE TOOLS AND OPTIONS ........................................................................................................ 124
CAPABILITIES ANALYSIS MODULES ......................................................................................................... 126
CAPABILITIES ANALYSIS OVERVIEW ................................................................................................................... 126
SIZING & MISSION ANALYSIS .............................................................................................................................. 126
PERFORMANCE .................................................................................................................................................... 133
COST ESTIMATION ............................................................................................................................................... 136
ROAST - TRAJECTORY ANALYSIS & FLIGHT SIMULATION ............................................................... 138
INTRODUCTION .................................................................................................................................................... 138
ROAST DATA IN RDSWIN MODULES ................................................................................................................... 139
ROAST METHODS AND ASSUMPTIONS ............................................................................................................... 140
COORDINATE SYSTEM ......................................................................................................................................... 142
INPUT PARAMETERS ............................................................................................................................................ 143
MULTI-STAGE ..................................................................................................................................................... 146
RATO (ROCKET-ASSISTED TAKE OFF) ............................................................................................................... 146
UNPOWERED LANDING SIMULATION ................................................................................................................... 147
ROAST RESULTS AND OUTPUTS......................................................................................................................... 150
ROAST TRAJECTORY SCRIPTS ............................................................................................................................ 151
TRAJECTORY SCRIPT EVENT TRIGGERS AND CONTROLS ..................................................................................... 152
TRAJECTORY SCRIPT MISC. CONTROLS ............................................................................................................... 155
REAL-TIME USER CONTROL ................................................................................................................................ 156
ROAST INSTRUMENT PANEL .............................................................................................................................. 157
REAL-TIME CONTROLS........................................................................................................................................ 158
RDS-EZ ................................................................................................................................................................. 161

OPTIMIZER AND CARPET PLOT .................................................................................................................. 162


RDSWIN-PRO OPTIMIZATION OVERVIEW .............................................................................................................. 162
OPTIMIZATION INPUT GRID ................................................................................................................................. 163
CARPET PLOT ...................................................................................................................................................... 164
ORTHOGONAL STEEPEST DESCENT SEARCH ........................................................................................................ 165
EVOLUTIONARY AND GENETIC ALGORITHMS ...................................................................................................... 166
POST-OPTIMIZATION AUTOMATIC DESIGN SCALING ........................................................................................... 169
OPTIMIZATION METHODS AND ISSUES................................................................................................................. 170
APPENDIX A: WEIGHTS EQUATIONS & VARIABLE NAMES ............................................................... 173

APPENDIX B: TAB FILE INFORMATION.................................................................................................... 182

iv
LIST OF FIGURES
figure 1. RDSwin-Professional Organization ____________________________________________________ 5
figure 2. V-Gull Initial Fuselage & Wing ______________________________________________________ 9
figure 3. V-Gull – Making the “V” ___________________________________________________________ 9
figure 4. Fuselage Reshaping – Stretch Sections _______________________________________________ 10
figure 5. V-Gull at 20 Minutes _____________________________________________________________ 10
figure 6. Add the Engine, Reshape the Fuselage (40 min) ________________________________________ 11
figure 7. More Fuselage Reshape (cowling doesn’t fit yet) ________________________________________ 11
figure 8. Pilot Made from Spheres __________________________________________________________ 12
figure 9. Add Canopy and Tails, then Do More Shaping _________________________________________ 12
figure 10. V-Gull Completed (at least for initial analysis) _________________________________________ 13
figure 11. V-Gull Mission Segments __________________________________________________________ 14
figure 12. Typical RDSwin Input Grid _________________________________________________________ 20
figure 13. Point Cloud (connected points stacked in component X direction) __________________________ 40
figure 14. Conic vs. SuperConic _____________________________________________________________ 41
figure 15. SuperConic Shaping ______________________________________________________________ 41
figure 16. SuperConic Cross-Sections (stacked in component X direction) ____________________________ 42
figure 17. SuperConic Patch Schematic _______________________________________________________ 43
figure 18. RDSwin SuperConic Patch Geometry (surface and slope control sections)_____________________ 43
figure 19. One RDSwin SuperConic Patch – Side & Top ___________________________________________ 44
figure 20. SuperConic Patch Collars _________________________________________________________ 44
figure 21. SuperConic Patch Showing Many Sections and Lines ____________________________________ 45
figure 22. Two RDSwin SuperConic Patches (one longitudinal patch bay) _____________________________ 46
figure 23. Two SuperConic Longitudinal Patch Bays _____________________________________________ 46
figure 24. Automatic SuperConic Smoothing (Akima) ____________________________________________ 47
figure 25. RDSwin’s AutoSmooth Recognizes Straight Segments _____________________________________ 48
figure 26. Non-Parallel and Non-Planar Cross Sections __________________________________________ 50
figure 27. DLM Axis System ________________________________________________________________ 51
figure 28. DLM Symmetry Options ___________________________________________________________ 52
figure 29. Wing Mirroring __________________________________________________________________ 53
figure 30. Slice through airplane with and without Component End Caps _____________________________ 58
figure 31. FlyView Controls ________________________________________________________________ 59
figure 32. Joystick Controls ________________________________________________________________ 60
figure 33. Relative Side View of Wing _________________________________________________________ 61
figure 34. Relative Top View (Up) of Wing with Overlapping Airfoils ________________________________ 62
figure 35. Relative Side View of Fuselage with Overlapping Cross-Sections ___________________________ 62
figure 36. RDSwin Rendering ________________________________________________________________ 63
figure 37. Rendering Clean Up via Powerpoint _________________________________________________ 65
figure 38. Slow Render (Caught half way with Alt-PrtScn) ________________________________________ 65
figure 39. Stacked Cross-Section Cuts of Fuselage and Canopy (Y-Z Slices) __________________________ 66
figure 40. Buttock Plane Cuts of Fuselage and Canopy (X-Z Slices) _________________________________ 67
figure 41. Cross-Section Cut Through Whole Airplane at One X-station (Y-Z Slice) _____________________ 67
figure 42. Angled Cross-Section Cut Using Relative View _________________________________________ 68
figure 43. Selected Airfoil and Resulting Initial Trapezoidal Wing __________________________________ 72
figure 44. Stretch Sections using Click-Drag ___________________________________________________ 77
figure 45. Stretched Proportional vs. Stretch-Front ______________________________________________ 78
figure 46. Reference Wing/Tail Revision _______________________________________________________ 80
figure 47. Cross-Section Shaping With Slice Through All Components _______________________________ 81
figure 48. Move Points in Cross-Section using Click-Drag ________________________________________ 82
figure 49. SuperConic Fast Cross-Section Shaping ______________________________________________ 83
figure 50. Shaping by Longitudinal Line _______________________________________________________ 84
figure 51. Volume Distribution plot (with “broomsticks”) _________________________________________ 89
figure 52. Mach Plane Cut Volume Distribution plots ____________________________________________ 90
figure 53. Typical Analysis Input Grid (Piston-Prop Propulsion) ___________________________________ 97
figure 54. Attainable Laminar Flow _________________________________________________________ 102
figure 55. Skin roughness value k ___________________________________________________________ 103
figure 56. Typical Aerodynamic Results ______________________________________________________ 105

v
figure 57. T/W, W/S, Weights and Other Data Input Grid (partial) _________________________________ 114
figure 58. Sample Thrust Scaling using T/W and T ______________________________________________ 118
figure 59. Sizing Trade Study ______________________________________________________________ 133
figure 60. Rate of Climb __________________________________________________________________ 134
figure 61. ROAST Instrument Panel During Trajectory Script Operation ____________________________ 138
figure 62. Typical Trajectory Graph _________________________________________________________ 141
figure 63. Vehicle Flight Orientations _______________________________________________________ 143
figure 64. ROAST Input Grid ______________________________________________________________ 143
figure 65. Landing Simulation ______________________________________________________________ 148
figure 66. Typical Landing Simulation Results – Vvert vs. Time____________________________________ 149
figure 67. Instrument Panel During Real-Time User Control ______________________________________ 157
figure 68. Instrument Panel with Rocket-like Attitude Icon _______________________________________ 158
figure 69. Real-Time Control Trajectory _____________________________________________________ 160
figure 70. Carpet Plot ____________________________________________________________________ 162
figure 71. MDO Solution Convergence _______________________________________________________ 168
figure 72. Bit-String Affinity _______________________________________________________________ 169
figure 73. Approximate Empty Weights _______________________________________________________ 173
figure 74. Misc. Weights Data ______________________________________________________________ 181

vi
INTRODUCTION
Welcome! RDSwin was developed to allow you to take an
aircraft design from first conceptual layout through functional
analysis, leading to performance, range, weight, and cost
results. RDSwin is an all new, all-original code and is uniquely
optimized for aircraft conceptual design and analysis. RDS win
is a true 32-bit Windows* Application, with Windows
pulldown menus, popup boxes, fonts, graphics, dialog boxes, clipboard read/write, Undo/Redo,
and more. It also outputs analysis results and program data to popup boxes, text files, Windows
printers, or directly to your spreadsheet, word processor, or Internet browser.

RDSwin comes in two versions – Student and Professional. The Pro version is ideally suited for
aircraft designers in industry, government, and academia to use during new aircraft conceptual
design and trade studies, technology evaluations, and preliminary performance predictions. It can
also be used to quickly evaluate performance of an existing airplane or a contractor’s proposal,
and to do derivative aircraft design studies.

The RDSwin Student version, as a companion to Dr. Raymer’s award-winning textbook Aircraft
Design: A Conceptual Approach, is the perfect tool to help students get through their first design
class. It automates the laborious analysis tasks – hopefully learned during preparatory
coursework - allowing the student to spend more time learning the techniques and philosophy of
new concept development including configuration layout, trade studies, and design refinement.

RDSwin is a fully integrated design environment with its own built-in Design Layout Module
(CAD), a complete aircraft analysis suite, and for the Professional version, built-in mission
optimization, carpet plot, and multidisciplinary optimization routines. Its balanced and time-
proven methods are suitable for virtually every type of aircraft, and have been extensively
calibrated on everything from homebuilts to supersonic stealth fighters to UAVs to futuristic
advanced technology airliners. And, RDSwin is really fast, both in computer execution and in the
time it takes the user to design, analyze, and optimize a new aircraft concept.

The Design Layout Module of RDSwin is original CAD software developed just for new air
vehicle conceptual design. It is not a separate or linked program as for some other aircraft design
packages, nor was it adapted from a generic CAD program developed for other uses. DLM is an
integral part of RDS, being a number of design layout routines which are coded with and
compiled into the rest of RDS, and called from the same pulldown menu as the rest of the
program.

Unlike typical commercial CAD programs, the RDSwin DLM “knows” what an airplane is. DLM
allows the rapid development of a new or derivative design layout. It has automated routines for
quickly creating most of the components used in aircraft design including wings, tails, fuselages,
landing gear, engines, seats and more. It uniquely “decouples” the screen display from the
geometry commands allowing certain design tasks to be done in any desired view using the
aircraft coordinate system, even when mouse inputs are being used.

1
DLM works closely with the RDSwin analysis modules, and automatically extracts the geometric
information required for their calculations. The Professional version even includes automatic
redesign of the vehicle, scaling its geometry instantly to match sizing results and optimized
values of aspect ratio, sweep, and more.

RDSwin includes powerful analysis of aerodynamics, weights, propulsion, and cost. It has full-
featured modules for aircraft sizing, mission analysis, and
performance analysis including takeoff, landing, rate of
climb, Ps, fs, turn rate, and acceleration. RDS win provides
graphical output for drag polars, L/D ratio, thrust curves,
flight envelope, range parameter, and more. RDS win-
Professional also features both traditional carpet plot
optimization and a multivariable/multidisciplinary design
optimizer (MDO).

RDSwin follows the design and analysis methods of the


best-selling textbook Aircraft Design: A Conceptual
Approach, by Dr. Daniel P. Raymer, now in its 5th Edition.
These methods are distilled from the classical and time-
proven first-order techniques commonly used in industry
design groups for early visibility into design drivers and
options. With RDS, these methods are automated and
incorporated into user-friendly modules that permit a
tremendous quantity of calculation including trade studies
and optimization in the very early stages of design.

RDSwin literally means “RDS, raised to the win power”,


and was created to help you “win” your battle to make a good design. The name also tells you
that RDSwin is a Windows-based implementation of the excellent and proven capabilities of the
five previous DOS versions of RDS. As any Windows* programmer knows, there is no such thing
as “conversion” from DOS to Windows, and this RDSwin program is no exception. The entire
user interface is new, with Windows pulldown menus and popup boxes, shortcut keys, on-screen
users manual, context-sensitive help boxes, graphical selection menus, and full implementation
of the Windows clipboard. Not a simple “prepackaged GUI” or spreadsheet add-on, the main
user interface alone totals over 16,000 lines of source code to guide and help the user through the
aircraft design process.

In addition to the typical Windows interface, RDSwin is full of shortcuts, hotkeys, and automatic
features to speed things up – a lot. While experienced users will appreciate these unique abilities,
new and casual users will find that all features are available from the Windows-typical pulldown
menu.

*
Microsoft®, Internet Explorer®, Excel®, and Windows® are either registered trademarks or trademarks
of Microsoft Corporation in the United States and/or other countries. Note that RDSwin is not a product
of, nor is it tested or endorsed by Microsoft.

2
RDSwin includes a rather unique capability – all user input files and all analysis results can be
displayed on the program’s screen as expected, or they can be displayed using your computer’s
default word processor, spreadsheet, or Internet browser. This is instantaneous and automatic,
once selected.

Displaying via Web browser is especially nice because you can email your results to others and
they can immediately see those results using their own Web browser, even if they don’t have
RDSwin and wouldn’t know how to use it if they did. Depending upon the browser you use, all of
your previous displays should be available as tabs, long after RDS win has moved on to other
things. If desired, you can even save them for future display, or post them on your website.

(Note that despite this capability, RDS win is not a “Web-based application” and it runs just fine
on computers with absolutely no Internet connection, nor does it ever connect to the Internet
without your knowledge. In fact, it has no internally coded capabilities to send or receive
information over the Internet. All of its Internet functionality comes from “Shelling” to whatever
Web browser your computer has set as default, using an HTML file created in real-time by
RDSwin and visible to you through Page-ViewSource in your browser. So don’t worry – RDS win
is safe!)

For those interested in such things, the core of


RDSWIN-PRO IS OVER 92,000 LINES
RDSwin is coded as a “Windows Console
OF ALL-ORIGINAL SOURCE CODE Application.” This is not the old DOS window as
some mistakenly believe, but a true native 32-bit Windows environment suitable for those who
want more direct control of the computer and less “interference” by Windows. The actual
Console is not seen by the user during RDS win operation except for a brief flash during start up,
before it is covered by the graphical window overlay. And yes, it all runs on 64-bit machines as
long as they are set up to run 32-bit Windows programs.

Please realize that while RDSwin truly is a Windows program, it’s not a Microsoft program. It
reflects the preferences and ideas of its author, and in some areas those ideas are a bit different
from the Microsoft norm. So, read the manual, check the Help pop-up boxes when needed, and
learn how to run RDSwin on its own merits - especially how it helps you to follow best practice
for aircraft design. In the end you’ll find it rewarding.

What’s New In Version 10


The most visible change in RDSwin Version 10 is the Main Screen user interface. Due to deep
changes in Windows 10, it will not reliably capture on-screen button clicks while the big
pulldown menu is active. Often two or three button clicks were required to select a module so
the Main Screen has been changed to use the ghost menu scheme as in the other parts of RDS win.
The flowchart menu buttons are active until you hover over the ghost menu, which brings up the
actual pulldown menu. This also allows certain Hot Keys to be active on the main menu,
including H for Help and # to toggle units (fps/mks).

The main pulldown menu has also been modified, with the overly-large Component pulldown
submenu being broken into three main menu options, namely Component, ShapeComp, and

3
ScaleComp. This speeds up access to the most commonly-used routines in the Design Layout
Module.

To avoid conflicts with other Windows programs and operating system files, the long-standing
RDSwin three-letter filename extensions (.DAT, .DSN, etc…) have been changed to 6 letters
starting with ‘rds’ (.rdsDAT, .rdsDSN, etc…). The old ones still work but RDS win will encourage
you to change them. A utility program is provided to easily change the old filenames
(RDSwinFixExtensions.exe). Just click on it – it tells you what to do.

In addition to the previous IGES, DXF, and other design export formats, RDS win-Pro V10 will
export your design as a file for 3-D printing in stereolithography file format (STL). This lets you
make desk models of your latest design – what fun!

RDSwin V10 features many more improvements and additions, and also includes the new
capabilities first seen in Version 8 such as “click-drag” for lines, surfaces, and assembly.

Since RDSwin is a complicated and sophisticated program, it is strongly recommended that new
users go through the Tutorial Sessions in the Help pulldown menu. This is not a program to learn
by “click-and-play!”

Dr. Daniel P. Raymer, author of RDSwin, is passionate about continuously improving RDS win.
Kindly email suggestions or bugs to rds@aircraftdesign.com. Be as specific as possible.

The RDS website at www.aircraftdesign.com/rds.html offers Tips & Tricks, sample data files,
and the occasional “back door” secret. You can go there from the RDS win Help pulldown menu.
.

4
RDSwin-PRO OVERVIEW

Program Organization and Modules


RDSwin-Professional is a conceptual aircraft design and analysis system developed for operation
on a personal computer, written to provide the design professional in industry or government
with a fast and user-friendly tool for design, analysis, and optimization of new aircraft concepts
and of aircraft derivatives. RDSwin includes a 3-D CAD module for aircraft layout and a full set
of analysis tools leading to performance and sizing calculations. RDS win is a single compiled
Windows executable (.exe) file plus associated data, text, and graphics files. RDS win will run on
any Win-XP or later Windows system.

Below is figure 1 which illustrates the organization of the various RDS win program modules. This
flowchart is not just an illustration – it actually appears on the main screen and the user can click
on any box to go to that module. A design is normally created “top to bottom” as shown by the
arrows. The Design Layout Module allows you to develop a design layout using a wide variety
of commands and capabilities including direct creation of common components such as wings
and engines, and section-by-section creation of complicated shapes when desired. The Design
Layout Module allows you to quickly assemble these components into a design, and rapidly
reshape them to create an integrated configuration arrangement.

figure 1. RDSwin-Professional Organization

Once the design is complete, a Geometric Analysis routine extracts from the CAD file the
information required for Aerodynamics, Weights, and Propulsion analysis. Those geometric
parameters such as wing area and fuselage length can then be pulled into the analysis modules
and used for calculations. It is not necessary to use the Design Layout Module to employ the
analysis modules of RDSwin. Instead, you can provide the required geometric data from a paper

5
drawing or from another CAD system by typing the data into the appropriate locations in the
RDSwin analysis module input matrices. While this sounds laborious, it actually takes less than
an hour to manually input all the required data this way.

The Aerodynamics Module estimates parasite drag (subsonic and supersonic), drag due to lift,
lift curve slope, and maximum lift, based upon classical techniques. RDS win includes a
longitudinal stability and control capability that estimates static margin and creates a trim plot,
and also calculates and stores a trim drag adjustment.

Weights and balance are estimated statistically based upon aircraft type (fighter,
transport/bomber, or general aviation). Results are presented in standard weight report format
including structures group weight (fuselage, wing, etc.), propulsion group, equipment group, and
useful load group. Center of gravity is also determined.

Propulsion analysis includes installation analysis of thrust and specific fuel consumption for jet
engines, and propeller thrust and specific fuel consumption for piston-prop and turboprop
engines.

The Aircraft Data File Module is the analytical heart of RDS. It can be thought of as a “filing
cabinet” containing the design’s calculated C D0, K, CL-max, installed engine thrust and specific
fuel consumption, and other sizing inputs such as key weights and allowable load factor. Most
of these are stored in array format as a function of one or two variables (usually velocity and
altitude).

Data for the Aircraft Data File can be calculated elsewhere and directly typed in, thus skipping
the modules shown above it in the flowchart. Normally, though, the Aerodynamics, Weights, and
Propulsion Modules are used to analyze a design and load the appropriate data into the Aircraft
Data File. Once the Aircraft Data File is properly created, by whatever means the user prefers,
its data can be used in the Sizing & Mission Analysis Module and in the Performance Module.

Because of this deliberate program structure, the analysis results from the Aerodynamics,
Weights, and Propulsion modules are not directly used by the Sizing & Mission Analysis Module
or the Performance Module. This speeds up those calculations and gives great flexibility for
analysis. It also allows - almost forces - the user to check and revise these analysis results before
committing them to vehicle sizing and performance. Instantaneous graphing capabilities make
this easy – just press “G” or select Graph from the pulldown menu. To revise the data (perhaps
the transonic drag rise doesn’t look right to you) you can type in some new values, or add or
multiply into rows, columns, or individual data entries. You can also “grab” data arrays from
other designs, or just throw the whole thing away and type in the numbers that you like.

Since the Aircraft Data File is used as an intermediate “file cabinet” for design data storage and
review, RDSwin does not work like a magical spreadsheet where everything flows down from one
input change. This means that if you change the inputs in, say, the Aerodynamics Module, there
isn’t a direct and immediate effect on the previous sizing and performance results. The methods
used by RDSwin are far too complicated for that – would you expect this in a Navier-Stokes
solver? Also, with RDSwin the user has dozens of options to review and change the answers along

6
the way, based on experience, judgment, intuition, historical fudge-factors, statistics, and
sometimes lucky guesses.

So, if you want to change the tail size and see the effect on performance, first you change the
appropriate inputs in the Aerodynamics Module * then run Aero analysis using the option to store
the results in the Aircraft Data File. Going there, you review the results for reasonableness,
probably by looking at the drag polar or a parasitic drag graph. If all looks OK, you go to the
performance module and run the desired calculations. This whole process takes only a few
minutes.

Note that sizing, mission analysis, and performance analysis cannot be run if the Aircraft Data
File is missing or incomplete. In most cases, RDS win will warn you if something is incomplete or
inappropriate. If you get strange results, go back and check the Aircraft Data File values.

Farther down on the flowchart of figure 1 is the Sizing & Mission Analysis Module. Here a
mission is interactively created by selecting mission element types (takeoff, cruise, combat, etc...)
then entering the required mission parameters in an input grid. Then the aircraft can be sized to
that mission, resulting in the sized design takeoff weight and the fuel weight to perform that
mission. The aircraft may be sized assuming either a rubber-engine or a fixed-size-engine,
selected from the Options menu in the Sizing & Mission Analysis Module.

It is also possible to analyze the as-drawn aircraft for range and loiter capabilities over a defined
mission, maintaining the as-drawn takeoff gross weight (i.e., not resizing to meet the specified
range but instead varying the range or loiter until the as-drawn aircraft can make the mission).
This is used for analysis of an existing aircraft or to determine alternate mission capabilities of a
conceptual design that has been previously sized to another mission.

The RDSwin-Professional Sizing & Mission Analysis Module includes a number of commonly
used sizing trades. These calculate the effect on aircraft gross and empty weight of parametric
variations in parasite drag, drag due to lift, specific fuel consumption, dead weight, payload
weight, and range. Also, the range-payload tradeoff can be determined. Results of these trades
are graphed automatically. Cost can be calculated and used as the trade measure-of-merit. This
is a key difference between RDSwin-Pro and RDSwin-Student: the students are supposed to learn
how to do trade studies themselves by changing the parameters, rerunning sizing and
performance, and graphing the results themselves as a learning experience. Professionals simply
want the results, right now!

The Performance Analysis Module uses the data in the Aircraft Data File to calculate
performance such as takeoff, landing, rate of climb, Ps, fs, turn rate, and acceleration. This
module will also graph the aircraft flight envelope, rate of climb, Ps contours, fs contours, and
specific range parameter (nmi/lb). Most performance calculations and graphs are immediately
run from the values in the Aircraft Data File, but the takeoff, landing, individual Ps, and

*
Or you could change the tail size in the Design Layout Module, select DoAnalysis to extract the geometric
information, and pull those results into the Aerodynamics input grid, but it is faster to “cheat” by just changing the
inputs in the Aero inputs. RDS has great flexibility for such things, and users will find their own preferred
methods.

7
acceleration calculations require additional inputs in a Performance Analysis input grid. This can
be stored and retrieved for future analysis of similar airplanes.

The Cost Module uses the statistical DAPCA IV model for development and procurement costs.
Life Cycle Cost and Airline Economic costs are calculated by yearly accumulation of costs based
upon user inputs, adjusted for the inflation rate.

The Carpet Plot & Multivariable Optimizer Module of RDS win-Professional permits automatic
optimization of T/W, W/S, aspect ratio, taper ratio, sweep, and wing airfoil thickness. The RDS win
MDO routine adds fuselage fineness ratio and wing design lift coefficient (equivalent to camber).
Graphical output of the carpet plot is available for any selected measure of merit including gross
weight, empty weight, fuel weight, purchase price, life cycle cost, net present value, and internal
rate of return. Performance constraint curves for requirements such as takeoff distance and turn
rate are also included. The Multivariable Optimizer does a simultaneous optimization of all
parameters then permits you to view a two-variable carpet plot at the optimal point to better
understand the tradeoff of the parameters and performance constraints.

RDSwin Design Example*: Raymer’s V-Gull


To give you the big picture before describing the program details, a complete sample design was
done from “scratch” and then analyzed. The chosen example has an unusual measure of merit –
beauty. I’ve always thought that gull wings like on the Corsair are especially beautiful, and
despite their technical challenges, have thought the same about V-tails as on the Bonanza. What
about a V-tail, gull wing airplane – the V-Gull.

I assumed that it would be a single seat “fun” flyer, built using the moldless composite method.
I did the pre-layout sizing using the RDS win Quick Initial Sizing Tool. This uses super-simple
methods such as statistical empty weight and Oswald’s span efficiency factor to estimate sized
takeoff gross weight. I assumed a 500 nmi mission, and to provide mild aerobatic capability,
assumed a power loading (W/Hp) of 10 and a wing loading of 20. I used crew weight of 220 plus
50 lbs of baggage for those cross-country trips to Napa Valley.

The Quick Initial Sizing Tool asks various questions – other than the above, the defaults were
used. For empty weight estimation, the composite homebuilt statistical equation was selected.
For parasitic drag, Cfe for a typical single engine GA airplane was selected. This all took about
30 seconds, and yielded a takeoff gross weight of 1,027 lbs. I rounded it to 1,000 lbs for the initial
design layout. With Wo=1,000 lbs and power loading of 10, the readily available 100 hp
Continental O-200 was selected. Based on the assumed wing loading of 20 psf, a wing area of
50 sqft was calculated.

The Design Layout Module was selected and “CreateNew” was selected. Design started with the
wing. Component-NewWing/Tail was selected. The wing area was entered, along with an aspect
ratio of 10 and a taper ratio of 0.45. An airfoil was chosen and other prompts were entered, and
a wing was created.

*
Written in 1st person to make it “real”

8
Next an initial fuselage was made using Component-NewComponent and selecting the fuselage
option. The Streamlined-BluntNose option was selected since the engine will be at the front, and
the 2-conic cross section shape was chosen. The initial wing and fuselage, as of now, are shown
in figure 2. On the right side, the wing has been moved forward using FlyAssemble, which allows
quickly moving components around in 3-D using the mouse, arrows, or joystick.

figure 2. V-Gull Initial Fuselage & Wing

figure 3. V-Gull – Making the “V”

In figure 3, the “V” shape to the wing has been made using ShapeComp-
ShapeCrossSectionsSide/TopView-MoveSections. The airfoil at the centerline of the wing was
deleted and an additional airfoil section was interpolated at the side of the fuselage. This was slid
upwards until it aligned with the fuselage, making the “V” shape.

StretchCrossSections was used to revise the fuselage geometry visually, scaling the sections to
get the desired side and top view shapes. This lead to figure 5, which shows the design at 20
minutes.

9
figure 4. Fuselage Reshaping – Stretch Sections

figure 5. V-Gull at 20 Minutes

An engine was created using NewComponent. This is a “simplified” geometry, more of an


envelope than an exact representation of this particular engine. Better geometry is not really
needed for configuration layout, but RDS allows you to make a more exact representation if you
wish. The engine length, width, and height (above and below the propeller shaft) were entered.
Propeller diameter was estimated by RDS win based on the horsepower of the engine. The engine
was then moved into position using FlyAssemble, and the fuselage was reshaped to fit. This is
shown in figure 6. Additional fuselage shaping around the cowling area is shown in figure 7, and
we are about 40 minutes into the project.

10
figure 6. Add the Engine, Reshape the Fuselage (40 min)

figure 7. More Fuselage Reshape (cowling doesn’t fit yet)

“Digital Dan,” a human figure made from stretched spheres to approximate myself, was retrieved
from the Component Bank. This is a file of standard components accessed using
GetComponentFromFile. FlyAssemble was used to move Digital Dan into position. Note that he
is a bit smaller than the USAF 95% Standard Man. Me too.

Then, a canopy was created using NewComponent, moved into position, and shaped using
StretchCrossSections. Tails were added using NewWing/Tail and moved into position. The
wingtip was shaped using StretchCrossSections, and more work was done on the fuselage
shaping using StretchCrosssections and ShapeByLongitudinalLines.

11
figure 8. Pilot Made from Spheres

Finally, a ground plane was grabbed from the Component Bank and moved into position, then
copied and pitched to the tail-down ground angle, and landing gear was created. The wheels were
made using NewComponent and entering the aircraft weight. The wheel struts and fairings were
created using NewComponent-StreamlinedStrut, then the cross sections were stretched out
enough to cover the tires. This led to the completed initial design of figure 10, after a total of
about 3.5 hours.

figure 9. Add Canopy and Tails, then Do More Shaping

12
figure 10. V-Gull Completed (at least for initial analysis)

With the initial design completed, the analysis could be started. First, the DoAnalysis button was
pressed to begin the geometric analysis. This is mostly automatic, but you are prompted to
indicate with the mouse the location of components and systems needed for center of gravity
calculations, such as the fuel system. DoAnalysis creates what is called a “TAB” file, a Tab-
delimited, spreadsheet-readable listing of a tremendous amount of geometric information about
the design (see Appendix B).

Exiting the Design Layout Module, the Aerodynamics module was selected and the last option,
“Make New Input File from Geometry From DLM TAB File”, was chosen. This reads the TAB
file and creates an input grid that has many items already set as default values, which you should
carefully check. Other values are blank and need to be input by you, such as the expected percent
of laminar flow. Explanations of these parameters are provided below and can be found in more
detail in Raymer’s textbook. Quick explanations can be found by clicking on the various column
heading boxes. Assistance with using the grid itself can be found below or by pressing “H”.

The TAB file geometry calculations need to be double-checked. In this case, the fuselage and
canopy have a large area where they touch each other. RDS double-counts this, so the combined
wetted area was estimated by making direct measurements back in DLM.

Once all the input values seemed correct, DoAnalysis was pressed. Results were checked for
reasonableness, then the pulldown option “Run Analysis and Put Results in Aircraft Data File”
was selected. As described below, the “Aircraft Data File” is sort of a filing cabinet where
analysis results are stored and reviewed, and then can be accessed for sizing, performance, and
range calculations.

A Weights analysis input grid was created in a similar fashion, pulling geometry from the TAB
file. Once all inputs were completed, DoAnalysis was pressed to see the calculations. The

13
Avionics, Hydraulics, Electrical, Fuel System, and Installed Engine numbers looked high
compared to similar airplanes, so Fudge Factors were applied to adjust them to more reasonable
values. This is common for very small airplanes – the installation statistics aren’t meant for them.
After review and adjustment, “Run Analysis and Put…” was selected.

A Propulsion analysis input grid was created as well. The 2-bladed, fixed-pitch prop option was
chosen, DoAnalysis was pressed and results were reviewed, and finally “Run..Put” was selected.

The Aircraft Data File was selected and the completed functional analysis was reviewed using
“Graph All Aircraft Data File,” and by viewing the individual data arrays. All looked fine, so the
Range&Sizing module was selected. A new mission was created by clicking on the available
mission segment types (figure 11) and then completing the required inputs, such as mission range,
climb speed, and the like. For the V-Gull, the required range was set as 500 nmi.

figure 11. V-Gull Mission Segments

Once the mission inputs were completed, the DoAnalysis button was pressed. Results indicated
that the airplane could be lighter than the initial guess, 759 pounds, and still reach the desired
range. This lower weight would improve the aerobatic capabilities as well, so the next iteration
of the V-Gull design would be based on this reduced weight.

Clicking on the “Performance” button allowed creating an input grid for takeoff and landing.
Once all inputs were entered and checked, DoAnalysis was clicked and the results were
displayed, namely 1288 ft for takeoff ground roll, and 700 ft for landing ground roll. These final
results were obtained about 5 hours after the project was started.

Cost calculations were not made since the DAPCA cost model used by RDS really isn’t relevant
for a homebuilt. For other aircraft, the inputs are similar to those of the Weights module and
produce results that track well with historical norms.

If the V-Gull were a real project, the next step would be to revise the design geometry based on
the sizing results. The RDSwin Design Layout Module makes that easy.

14
RDSwin OPERATION NOTES
Installation and Startup
RDSwin is a true Windows executable program (.exe) but does not require a “hard” Windows
installation in which the Registry is changed and the computer has to be restarted. All you have
to do to install it is to click on RDSwinInstall.exe on your CD-ROM. Run it, and then follow
instructions. Or, you can do the installation yourself. Just copy the entire CD-ROM into your
computer’s root directory (C:\). This will create a new directory C:\RDS-win, plus several needed
subdirectories, and fill them with the program and associated files.

Then set up a Windows Shortcut using My Computer or Windows Explorer. In the main RDS
directory (default is C:\RDS-Win), find and right-click on the program file RDSwinPro.exe and
select SendTo-Desktop. RDSwin is then ready for use. Now just click on the Shortcut icon to start
RDS. It does looks nicer if you right-click on the Shortcut icon, select Rename, and change
“Shortcut to RDSwinPro.exe” to simply “RDSwinPro”.

Normally RDSwin will show the background image in use the last time it was shut down, but you
can customize your shortcut to always start with a certain background image regardless of the
last image. To do this, right-click on the Desktop Shortcut, select properties, and add to the
“shortcut target” the complete path and image filename (must be a bmp), for example:
C:\RDS-Win\RDSwinPro.exe C:\RDS-Win\RDSUser\DanBkGr10.bmp

Or, you can tell RDS to start with a random RDS image by modifying the shortcut target to:
C:\RDS-Win\RDSwinPro.exe RDS.RND

The RDS main screen uses a custom font


called "Hemi Head 426" to make the
large “RDS” text at the top of the screen.
If you don’t have that font installed on
your computer, RDS shows a stored image of that font which looks fine, but if you install the
font on your computer it will look better – more crisp, and with a subtle color special effect.

With the kind permission of the developer Ray Larabie, the Hemi Head 426 font is included on
the CD-ROM. Click on the file “hemihead.zip” and extract it to your fonts folder. You may have
to go to ControlPanel-Fonts and select File-InstallNewFont. It’s easy, and takes about a minute.
RDSwin will look better, and you can also use this eye-catching font for other things.

RDSwin-Pro is provided in a non-copy-protected format, using a password-based software


protection system. Your password unlocks RDS to run on a specific machine based on a code
created from serial numbers and other information. The first time you start the program a message
will appear with an alphanumeric code generated from parameters in your computer system.
Email this to the address provided and an unlock code will be sent to you.

In RDSwin-Pro, each user can have a unique configuration setup. These are remembered for each
user and include things like preferred colors and background image, working project file, and
certain analysis parameters. To use this feature, make separate copies of the Desktop Shortcut

15
used to start RDS, right-click it and select properties, and add to the “shortcut target” so that it
reads as follows:

C:\RDS-Win\RDSwinPro.exe user=yourname

“Yourname” can be any string you wish but cannot have any punctuation, quotation marks, or
special characters.

Installation Issues
Today’s computers have a wide range of security software to protect against viruses and
malicious software, and to protect companies from installation of unauthorized or pirated
software on their computers. Depending upon the security methods in use, there may be problems
getting RDSwin to run the first time. Since RDSwin is not used widely enough to be flagged as
“normal” by security software, it may be flagged as “suspicious.” If so, you may have to open
the security software and give RDSwin permission to run. You may need to install RDSwin while
logged on to Windows as “Administrator.” You may need to “Unblock” it using My Computer
or Windows Explorer. Right-click on RDSwinPro.exe, go to Properties, and click UnBlock.

RDSwin is not intended to be installed on a network and will almost certainly not work if that is
attempted. The license specifically prohibits this, so don’t be surprised when it doesn’t work!

Newer versions of MS-Windows prefer that programs such as RDS win keep their user’s data files
in the User Documents Folder (directory) rather than in some folder created elsewhere, including
in the RDS-win folder containing the program. Otherwise Windows might, in the event of a
System Restore, automatically 'restore' them to their previous versions. This erases your most-
recent work! To avoid this, you should create and use a directory at
C:\Users\[yourusername]\RDSUser\. Note that the C:\Users\ terminology may be different for
your version of Windows - look for something similar.

Some computer screens or resolution settings might clip off the bottom of the RDS win Window.
You should see buttons at the bottom of the main screen including one labeled “Exit RDS”. If
these are missing or cropped, right-click on your RDSwin shortcut then try:
1. Options - Use Legacy Console
2. Compatibility - Disable Display Settings on High DPI settings
3. Layout - Let System Position Window
4. Compatibility - Compatibility for Win8,7, or XP
Next try changing the screen resolution, right-clicking on the desktop and selecting Display
Settings, then Advanced Settings or something similar. Try higher and lower resolution values
but first write down the original one.
A final method is to go to the RDSresource subdirectory and open file RDSwinParams.RTD
using NotePad (not Word). Find {ConXsizemult= } and {ConYsizemult= } and change their
values to smaller numbers as appropriate. Save the file and restart RDS win. Revise these values
until the bottom buttons and right side image are fully visible. You can also try a smaller value
of parameter {xShrinkWorld}. This allows both width and height of the Window to be adjusted.

16
A new problem has arisen on Windows 10, which seems to be trying to turn your computer into
a smartphone. Changing the Windows text size can cause the RDS win graphical display to be
smaller than the console showing unusable gray areas to the right and bottom. To fix this, right
click on the desktop and select Display Settings. Make sure the slider for “Change the size of
text..." is set to 100%. If it was set higher, you'll probably have to restart your computer before
running RDSwin.

Fun Stuff – Backgrounds, Colors, and Sounds


Those who use RDSwin regularly will probably spend a lot of time on it, so a bit of fun stuff has
been included. Some are hidden for the adventurous to stumble across (these may be revealed on
the web site in the fullness of time).

The main page shows a program flowchart with clickable buttons, taking you to the major
modules. On that main page or in any analysis input grid as described below, a background image
can be shown. RDSwin includes a large number of airplane-related photos and images, mostly
photos taken by the author or design images from his book Living in the Future. These can be
selected using Options-Wallpaper-PickRDSImage, or select Random to see a different image
each time you start RDS. The Wallpaper submenu has a lot of other options – play with it.

Options-Wallpaper-SelectUserImage allows selecting your own favorite images, placed in


subdirectory C:\RDS-Win\RDSUser. The author’s personal backgrounds are included there,
mostly travel photos (do you recognize any places?). RDS can stretch those images to fill the
screen, but this may distort the image if it isn’t the same aspect ratio as your screen.

To make a background image that completely fills the RDS window without distortion, open
RDS then select File-SaveScreenToClipboard. Go to your favorite graphics editing program and
open/paste the clipboard as a new image. It will be exactly the correct size to fill the RDS window
on your computer. Then fill it with a solid color, paste other photos on it, draw all over it, or do
whatever you want. Save it as a Bitmap (bmp) to C:\RDS-Win\RDSUser then select it as
described above.

If you wish, you can create a custom background bitmap for each project. Create it with filename
“ProjectName.bmp” (such as DR3_win.bmp), and place it in the project’s subdirectory. Then
when you switch to that project using File-SwitchProject, it will appear as the background image.

RDSwin always uses solid backgrounds for graphs and for the Design Layout Module. In the
Options menu you can choose to use solid backgrounds for the main page and input grids as well
(ShowSolidBackground…). There are several options for setting that solid color. You can
PickSolidColorBackground, which brings up a grid of default colors you can select. You can
select BlackOnWhite, which is good for images to be used in reports. You can enter a color using
the Windows HSW scheme, if you know how. You can also make a background color from the
current background image. This is done by sampling, so a photo of an airplane in the sky will
probably produce a light blue image, whereas a night scene photo will produce a dark gray
background. Note that this is offered automatically each time you change your background
image. You can lighten or darken any background color, and can add grid lines to it.

17
Colors for the various boxes such as those on the main page flowchart or in the input grid routines
are always picked by sampling and lightening your background picture. If the picture has a lot of
yellow, the boxes will be a yellow pastel.

Colors for text and the various lines drawn in graphs and the design layout module can be selected
in the Options menu, along with line thicknesses. Do be careful – you can select white lines on a
white background, but nobody will see them! Also, don’t pick the same color for Design…Lines
and SelectedComp…Lines or you won’t know which components are currently selected for
shaping and moving.

Concerning sounds….click on the big RDS if you are bored.

Commands and Data Input

Pulldowns, Prompts, and Picks,


As for most Windows programs, the features, options, and commands of RDS win can be selected
from the extensive pulldown menu across the top of the screen. All options are shown, all of the
time, so you won’t have that “where did it go” feeling as you move from module to module. The
options that aren’t applicable in a particular module are faded and unusable until you are in a
module that uses them. This explains why so many of the submenus are un-selectable when you
first start RDSwin – you haven’t yet selected a module to work in.

In RDSwin-Student, some of the menu options are always faded and unusable. If an option never
becomes active and you can’t it in the User’s Manual, the reason is simple. That option is for
RDSwin-Pro only. These appear in the menus because RDS win-Student and RDSwin-Pro are
compiled from the same source code.

RDSwin uses Windows pop-up boxes for data and text input in various places, and for selecting
files and command options. Familiar GUI devices from the Windows API, such as the ubiquitous
“Select File” box, are also used in appropriate places. The Windows clipboard is supported for
text and data inputs, and the entire RDS screen can be copied as an image to the clipboard. Or,
the current contents of the clipboard can be “grabbed” as the background image.

In addition to the Windows-typical pulldown menu bar, RDS win has on-screen buttons and single-
keystroke hot keys to speed up operation for experienced users. On the main page you will see a
flowchart depicting RDS operation, from the Design Layout Module at the top to Sizing,
Performance, and Cost at the bottom. The boxes are all hot buttons – click on one to go to that
module. Once within a module you will find more hot buttons at the bottom, for various common
tasks. The options called using these hot buttons can all be called from the pulldown menu if you
prefer, but hot buttons are faster to use.

18
Ghost Menu
You will notice as you operate RDS win that the typical
Windows pulldown menu across the top is sometimes
turned off, at which time it is visible as a faded “ghost
menu”. This is deliberate, and it permits RDS win to use
single-keystroke shortcuts and arrow buttons to speed
up operation.

To re-activate the pulldown menu, all you have to do is


move the cursor over its ghost. After you select and
execute the desired menu option, it will go back to
“ghost” status.

You can also activate the pulldown menu by using the


Alternate Hotkeys (Alt-F, Alt-E, etc…). Hold down the
Alt key and press the desired hotkey TWICE. The first
press activates the pulldown menu, the second selects
the top-level menu category. Then you can use the arrows to navigate to the desired option.

If you then decide that you do not want to pick an option from the pulldown menu, just press
ESC or click anywhere on the screen.

Some users may not like this feature and may wish that it worked “just like Excel.” One RDS win
beta tester described the ghost menu as “some kind of cruel joke.” Hopefully his opinion is the
minority, and perhaps he’ll even grow to like it. But, if you really hate it you can turn it off in
Options. Then you will have to remember to move the cursor to the top of the screen to access
the Pulldown Menu, or you can always use the Alt-(hotkey) method.

Input Grids for Analysis Data


The aircraft analysis calculations of RDSwin need a lot of data input by you, the user. To make it
easy, an all-new proprietary input grid routine was developed for RDS win. This is directly
integrated into the code and is tailor-made for aircraft-oriented data input. It allows rapid input
of required data, allows hot key inputs such as a single keystroke to change from metric to
Imperial units, and automatically sets defaults, guides the user, and besides, it looks very nice!

19
figure 12. Typical RDSwin Input Grid

These input grids are used in all analysis modules, and also in the Aircraft Data File. Each is
customized for the data being entered. They are either two-variable arrays, such as parasitic drag
versus speed and altitude, or are paired columns of data such as stores drag versus Mach #, or are
paired columns of data and labels. Actual inputs are described below in the various module
descriptions.

The RDSwin input grids work a bit different than commercial spreadsheets. When in one of these
input grids, there is always an “active” box as shown by a depressed frame and a darker color,
whether or not the mouse is hovering over it. You can always type in a new value for that data
item – just start typing, or press RET and enter a number, or click on a box and enter a number.
As described below, you can also enter a simple expression which will be converted into a
number.

While all features can be selected from the pulldown menu bar, there are a number of fairly
obvious hot key shortcuts. While in an input grid, you can press A to run Analysis, G to make a
graph (if there is graphable data), or P to List and Print the data. Press H for Help, or click on a
column header box for specific information. ESC will exit the grid and go back to the main
screen.

You can press Ctrl-C to copy the contents of the active data box to the Windows Clipboard, or
press Ctrl-V to copy the current contents of the Clipboard into the active data box. You do not
have to highlight specific text first – the number in the active box is used automatically.

Ctrl-U and Ctrl-R work for Undo and Redo (or Ctrl-Z and Ctrl-Y, as many other programs use).

Copy, Cut, or Paste can all be selected in the pulldown menu. First hover over the data item box
you wish to copy or paste, then briskly move the mouse up to the pulldown menu so that it doesn’t
change the active box to one that you pass over on the way.

20
Keep in mind the way that RDS turns off the main pulldown menu, showing a “ghost” until it is
reactivated. If you want to use the pulldown menu, hover over it until it reappears. If you have
done that but decide to go back to the grid, you may need to click on the grid to reactivate it.

Smart Data Input – the Amazing ParseVal Routine


Data entry in RDSwin is processed by a routine called ParseVal. The name isn’t important, but it
makes data input a whole lot easier. Almost every data entry into RDS win can be done as an
expression rather than a single number, and many typical aircraft abbreviations are supported.

For example, if you are asked to enter the landing gear length in feet but only know that it should
be 42 inches, just enter 42/12. When entering a drag coefficient of 0.0142, you can instead type
142counts, or 142cts. 10,000 can be entered as 10k. For you pilots, flight level can be entered for
altitude, and is correctly understood even if you are using metric units at the time. FL100 will be
converted to 3048 meters which, upon pressing #, is converted to 10,000 feet.

ParseVal is also used for multiple entries such as “enter number of propeller blades and maximum
power.” Simply enter the two values, separated by a “pipe” symbol {|} or a space. So, for this
prompt you could enter “2 150” (without the quotes). You could also enter these values as “6/3
50*3”.

Because a space can be used as the separator for multiple entries, you cannot have a space in a
single entry. 10k is acceptable, but 10 k will be understood as two entries, 10 and 1000. If only
one entry was requested, 10 will be used, not 10,000.

Don’t get carried away with complicated expressions. ParseVal isn’t that smart, and can only
handle single expressions, so 10sin30 isn’t allowed. It doesn’t recognize parenthesis either.

ParseVal options are listed below, along with sample usage. This help list will pop up if you type
HELP whenever RDS is waiting for a numerical input.

21
Arithmetic Operations (2+7=9, 20/12=1.6667 ) + - * /
(only one per expression, no spaces, and no equal sign)
Thousand (10k=10000) K
Million (20m=20000000) M
Counts (87cts=.0870) COUNTS OR CTS
Pi (2pi=6.2832) PI
Minutes (20min=0.33333 - use when hours requested) MIN
Seconds (20sec=0.00556 - use when hours requested) SEC
Percent (27%=0.27 - use when ratio requested) %
Trig (angle in radians, or add "deg") SIN, COS, TAN
(tan.33333=1.7321, tan60deg=1.7321)
Inverse Trig(atan15/30=0.46365) ASIN, ACOS, ATAN
Square Root (sqrt9 = 3.) SQRT
Squared (sqr9 = 81.) SQR
Exponential (exp2=7.3891) EXP
Natural logarithm (log7.3891=2.) LOG
Scientific notation (15E-2=0.15) E
Flight Level (100ft, gets converted to meters if using metric) FL
(FL250=25000 ft, FL250=7620 m)
Statute Miles (gets converted to km if using metric) miles
Statute MPH (gets converted to kmph if using metric) MPH

The SimpleCalculator in the Tools menu is based on ParseVal, so it too cannot handle
complicated expressions. However, you can use cut-and-paste to do a more complicated
calculation, one step at a time. Or go find your pocket calculator.

For certain inputs, Parseval can produce a range of values in a manner similar to computer
programming. For example, when using Tools-CalculateStandardAtmosphere you can input
altitudes as “0 to 50k step 10k” and get data for every 10,000 feet up to 50,000 feet.

Mouse Operation
RDSwin uses a typical Windows mouse interface, but adds a few neat tricks. When fine control is
desired during Graph or Design displays, the arrow keys can be used to move the cursor. The
speed and sensitivity of the cursor movement can be changed by pressing S for Slow, D for
Default (medium), or F for Fast. These are especially useful for Locate and Measure operations.
Repeatedly pressing S or F will make the cursor move even slower or faster. If it stops moving
you’ve pressed S or F too many times. Press D.

In the Design Layout Module, most mouse input requests will allow you to enter a value
numerically. Press N, then enter the desired value in the pop-up box.

Also in DLM, the FlyView and FlyAssemble modes (see below) allow the mouse to move or
rotate the design display or the selected components, much like a pilot flies an airplane. When
these modes are selected, the cursor changes to a 4-arrow cross indicating motions of your
“control stick”, and is trapped on the upper-right edge of the screen. Motion of the mouse directly

22
“flies” the airplane or selected components. Pressing S for Slow, D for Default, or F for Fast will
change the mouse sensitivity during these modes.

JoyStick Operation
Given the purpose of RDSwin, many of its users are likely to have a flight simulator joystick
attached to their computers. Now your toy analog input device can be used for aircraft design!

In the RDSwin input grids, the joystick moves the active cell around the screen, up-down-left-
right. Twisting the stick jumps to the top or bottom of the column. Twisting while pressing the
trigger fires photon torpedoes…no, sorry, it just jumps to the start or end of the whole array.
Clicking any button allows inputting data in the current cell (or just start typing).

In the Design Layout Module, the joystick can be used to “fly” the aircraft display around the
screen and to select certain viewing options. In FlyAssemble mode it can be used to “fly”
individual components into position. These are detailed in the DLM chapter, below.

The first time you start RDSwin with a joystick attached you will be prompted to enter a range of
“throttle settings”. This control paddle (see illustration below) is used to zoom the display in
DLM. Note that if the joystick stops working or you install a new one that doesn’t work the same,
exit RDS, delete RDSCONFIG.RTD then restart RDS.

If you can’t get your joystick to work, test it by running RDS win from Start-Run with the
command line statement “joystick” (\rds-win\RDSwinPro.exe joystick). The values returned to
the program by your joystick are shown on the screen. If they are all zeros and/or don’t change
as you move the joystick, then RDSwin isn’t receiving any values. This is probably due to a bad
joystick, an inoperative device driver, or a non-standard joystick that doesn’t work in the normal
way with the Win API command “joyGetPosEx.” Try another one.

In some cases a computer tell will RDSwin that there is a joystick, but there isn’t. It keep
prompting to set the throttle position – annoying. Open file RDSwinParams.RTD in the
RDSresource subdirectory and set the magic parameter JoyBreakout to minus one (=-1).

23
Drafting
RDSwin has a powerful
set of drafting
capabilities, called
from the Drafting
pulldown tab and
useful in Graphs and
the Design Layout
Module. These allow
you to draw circles,
lines, arrows, angles,
and parallel lines. It
mimics the drafting
table tricks once
laboriously learned on-the-job by young designers.

Other options allow you to place text on the screen, erase or move a designated area, or flood-
fill a region with a selected color. You can also draw a filled polygon by clicking around the
screen. Most options allow multiple use, continuing until Esc or double-click are used to exit.
Prompts at the bottom of the screen should guide you through these useful commands.

Erase and Move start by clicking on one corner of a rectangular box to be erased or moved, then
dragging and releasing the mouse button at the other corner. For Move, after the box is defined
you click and hold down the mouse button again as you align the box as desired. Move can be
used to reposition the labels on a graph. However, if you use Graphic Move to reposition the
design components, it only changes the picture on the screen right now, not the actual component
geometry!

The Title Block option is a nostalgic nod to this programmer’s early years on a drafting table at
a major aerospace company, where every design layout was identified with such a block pasted
at the bottom-right corner. Enter the data requested. If you are in the Design Layout Module and
have defined layout notes, they will be added below. You can modify these or add additional
lines of text, up to about 60 characters. After entering the text, an outline box will appear – place
it where the title block should go.

The text you enter for the Title Block isn’t saved, but you can copy the whole input page to your
word processor, save it elsewhere, and then copy and paste it for later title blocks. You can also
customize the Title Block, replacing the green “RDS” logo with your own company logo. Find
the file CompanyLogo.bmp in the RDSuser directory, open it with a graphics program, and paste
your company logo into that file, then save it without changing the name. There is a copy of the
original RDS default logo image in that directory in case you mess it up.

The Drafting images are like “paint” that is added onto a design layout or graph display. They
are not permanent and will disappear as soon as the underlying display is changed. So, first get
the display correct, then add the drafting and save the image to a bitmap or the clipboard.

24
Graphics Undo and Redo are available from the pulldown menu in case you make a mistake, but
as soon as you change the underlying Graph or Design display, all graphics are lost.

The Drafting pulldown menu also includes Measure and Locate options. These are “smart” and
know what design layout view you are in. Results are given for X-Z, X-Y, or Y-Z appropriately,
and are in the aircraft axis system (see below). Plus-Y is out the LEFT wing, which is to the left
when in a rear view, and towards the bottom of the screen when in a top view. They also work
in Graphs, allowing you to easily read off points of interest.

The Measure routine shows a lot of useful information as you click-drag a line, including the
length of the line and the horizontal and vertical distance of the line. The angle of the line is
measured three ways. First is the total angle off zero (normally zero is to the right). A positive
angle is defined in the appropriate coordinate axis so in top view, a positive angle is downwards.
Then in parenthesis, the angle is converted into its first quadrant equivalent (0-90) and its
reciprocal. These are often more useful than the actual angle.

The MeasureIncludedAngle routine works much like a traditional drafting machine. First you
click on the angle origin point, then you click-drag from a point on the angle start line to a point
on the angle end line. It is easier to do than to explain – try it.

Locate and Measure leave the answer in a box, centered on the line or angle. If you don’t like
this, you can turn it off. Uncheck the ShowMeasurementInTextBox option.

RDS will measure the area of a defined, filled region on the screen. First mark and fill the areas
you wish to measure using DrawFilledPolygon or Drafting-FillRegionWith. Use a unique solid
color (not your wallpaper). Then, select MeasureFilledArea and click on the region. The area will
be measure for ALL areas with that color currently on the screen, so fill with a color not being
used already (including lines and text). Bright red or yellow work just fine, unless you are using
those elsewhere. To perform the calculation, RDS counts all the pixels of that color, converts to
the proper drawing scale, and then tells you the area of that color as well as the area of the
remaining screen.

Graphs
RDS has a sophisticated, airplane-friendly routine to graph inputs, analysis, performance results,
and aircraft data such as engine thrust and drag polars. Graphs are plotted with an Akima-based
curve fit routine. The graphing module includes editing capabilities to create viewgraphs and
report graphs. Finished RDS graphs can be saved as bitmap images or copied to the clipboard
for use by Windows application programs for rapid production of technical reports and briefing
charts. In RDS-Professional, the data defining graphs can be output in a text format readable by
most spreadsheets and data plotting programs.

When a graph has been displayed on the screen, a number of options are available as single-
stroke hot keys. These can be displayed by pressing H (help). These magic buttons are useful
for experts, but the commands are also available through the Windows pulldown menu bar for
new and casual users.

25
Axis Limits A
Zoom to Limits of Data Z
Location L
Measure M
Multiply Data by input values X
Take Log of Y values \
Curve Fit between Points (toggle) ~
Grid (toggle) |
White and Black color scheme W
Bitmap Image Save B
Slow Cursor Speed (by arrow buttons) S
Default Cursor Speed D
Fast Cursor Speed F
Help H
Exit Graph (return to Grid main screen) Esc

The graph axis may be changed by entering the letter A (Axis). This erases the graph, including
any editing or lettering as described below, and prompts for new X and Y minimums and
maximums. Pressing “|” (it looks like a grid line) will remove or restore the grid lines on the
graph.

You can Zoom a graph by pressing Z, or by click-dragging a zoom box on the graph itself.

Various other graphing options can be selected from the Graph pulldown menu. These parameters
include the desired default graph origin and the use of a curve fit or straight-line interpolation,
and are saved for next time when you exit RDS. Note that changing these will redraw the screen
and erase any drafting you have done.

A screen image bitmap can be created simply by pressing B. Each bitmap created is given a name
derived from the design file name in use, truncated and with a number added.

In RDSwin-Pro you can press S to Save the graph as an ASCII text file of the data used to create
a graph, which can be used by other programs such as a spreadsheet. Enter a filename as
prompted. Alternatively, pressing a digit from 0 to 9 immediately creates a file named
GRAPH(#). Also in RDSwin-Pro, pressing “/” causes the vertical axis of the graph to be
normalized to some value (i.e., divided by the value). For example, sizing trade studies can be
normalized so that the baseline measure of merit result (weight or cost) is 1.0, and trade results
are shown as plus or minus from 1.0. This is useful for presenting results trends.

Making Squares Square


Windows cannot always determine the final X-Y scaling of screen and printer displays, so
squares might not look square, and airplane tires might not look round. To deal with this, RDS
uses a brute-force method, storing a Y-axis scaling factor for screen displays, and another for
displays to be printed. Both ratios are created by you.

26
Go to View-DesignViewOptions-ChangeImageXYratio and select either ReviseScreenRatio or
RevisePrinterRatio. Two boxes will be shown. The box with solid lines should appear square,
either on the screen or after printout by whatever printer you are using. If it is not square, measure
the width and height of the DASHED square and enter the ratio Width/Height when prompted.
Remember, with the RDSwin ParseVal input processor, you can enter the calculated ratio (for
example, 1.122) or an expression with the numbers that you measured (4.6/4.1).

You can create two different ratios and select between them as desired. Normally keep the Screen
ratio active. Select the Printer XY ratio just before printing or saving an image to be printed, then
go back to the Screen ratio. In the Design Layout Module, the divide sign (/) is a hot key that
toggles between your Screen and Printer XY ratios.

List and Print Text Files


One of the nicest features of RDS win is the way it shows analysis results and other text output.
This offers tremendous flexibility for the user, and makes it easy to share data throughout a design
team. Whenever a text file is to be shown, RDS win formats it, converts it to several formats, and
displays it. What is unique is that RDSwin lets the user select any of six different displays,
including via other programs such as Excel and MS-Word.

The default option is to show the text on the RDSwin Console*. The screen is cleared completely,
even the pulldown menu, and the text appears. This provides the maximum amount of room for
text. Pressing H will list options such as P for Print. Ctrl-C is available, to allow copying the text
to other Windows applications. You don’t have to highlight anything first – all of the text is
automatically copied.

You can also choose to show the text in a pop-up box. This is quick, but the box is smaller so
you may have to scroll to see everything. In a pop-up box, Ctrl-C copies only the selected text as
in most Windows applications.

Other options send the text to whatever Windows program your computer system identifies as
the default for opening such files. If you select “Use My Word Processor,” RDS will create a file
with filename extension .DOC and ask Windows to open it. Windows will (usually) start MS-
Word† and open the file. This may take a few seconds so a “Wait” sign is shown on the RDS
screen.

Similarly, if you select “Use My Spreadsheet,” RDS creates an XLS file which most computers
will open it in Excel. If you select “Use My Web Browser” most computers will use Internet
Explorer to open the HTML file created by RDS. If you use other programs for these file types
it should work the same – if not, please email details to rds@aircraftdesign.com.

*
Other than a flash during start-up, this is the only time that the actual RDS Console is shown to the user.
Normally it is covered by an attached Graphics Window.

On some computers, you may need to download and install a converter to use MS-Word this way. It should tell
you what converter is missing. Or, it may tell you a converter is missing but work fine anyway!

27
When you’ve finished looking at the results, close that other program to automatically return to
RDSwin. Alternatively, you can go back to RDS win without closing the other program so you can
look at the text again. Just click on the RDS win button at the bottom of your screen. You can
toggle back to the previous display at any time.

The Web Browser option is especially useful. RDS win actually writes a complete Web page for
each printout. This can be saved in HTML format, posted on the Internet, and emailed * to others.
They will be able to see exactly the same results that you see, even if they don’t have RDS win.
You can see the HTML for each page using your browser’s Page-ViewSource † command.

Each new printout will be shown in its own Web browser tab (at least in IE and Firefox) so you
can keep a number of analysis printouts as you work. This is especially useful for trade studies,
for example changing the drag coefficient and calculating the effect on sizing (done automatically
in RDSwin-Pro).

Normally the Web Browser option includes the same background image that you are using in
RDS. If this is too cluttered, or you don’t want others to see it, select the “Plain” option.

Note that when RDSwin uses the Web browser for display, it is entirely local to your computer.
You don’t even need to have an Internet connection to use your Web browser for display.

If you select one of the “other program” options and nothing happens, you may have to tell
Windows which program to use for that file type. Go to either My Documents or Windows
Explorer and select Tools-FolderOptions-FileTypes. Scroll down to the non-working file type
(DOC, XLS, or HTML) and highlight it. You should see “Opens With…” and your default
program. If not, select Change and find the desired program (normally Word, Excel, or IE).

After viewing the text file by any of the routines above, RDS will normally offer saving it as a
TXT file. If this gets annoying, you can turn it off by un-checking “Offer Save after Listing File.”
When needed, you can turn it back on or save the text using the Clipboard.

Printing (hard copy) is done using your attached Windows printer, after viewing the displayed
text. It is done differently for the various options above. In the Console display, press P to print.
In a pop-up box, there is a Print button. If you display text on another program such as Excel,
just print using that program.

RDS normally “wraps” big data tables, automatically truncating an excessive number of columns
and showing them below. For example, if you have 20 Mach number for the drag data and want
to show it as text on regular paper, RDS will cut the table after the 5th column and continue the
table below, doing the same at the 10th and 15th columns.

If you uncheck this option, RDS will, like Excel, show all of the columns at once. This works
great if you are using Excel or the RDS Pop-Up Box for your display, but may cause problems

*
If you are looking at an image from ShowScreenInWebBrowser, the IE option SendPageByEmail may not
include the image. Instead choose SaveAs-WebArchive (.MHT) then email the saved file as an attachment.

When viewing the source code, note that the oft-repeated phrase “&nbsp” is used to provide regular spacing.

28
with others. Word, for example, will wrap each line individually making for complete confusion.
This can also cause problems with the RDS Console display, which doesn’t like super-long rows.

An insider’s tip – regardless of the display option you have selected, RDS makes and saves ALL
of the text output formats, in the RDStemp directory. You can go there and click on them, opening
them in the appropriate program. However, these are overwritten the next time you select
ListAndPrint, and are all erased when you shut down RDS win.

Units and Currency


RDS is fully capable in both Metric (MKS) units and in units of the British Imperial (FPS) type.
In the FPS units RDS uses thrust in lbs., C in 1/hr, altitude in feet, and velocity in either knots or
Mach Number. In the MKS units RDS uses thrust in kN, C in mg/Ns, altitude in meters, and
velocity in either km/hr or Mach Number. It is not necessary to identify whether knots (or km/hr)
or Mach Number are used because RDS assumes that any velocity values less than 10 were given
in Mach Number.

Units are selected in the Options pulldown menu tab, or by clicking on the FPS/MKS button in
an input grid, or by entering # (pound sign) from any data input grid or design layout display.
The units currently in use are shown up on the window title bar.

You can jump from one to the other at will, and can enter or view all data in whatever units you
prefer. For example, even metric users often want to enter velocities and ranges in nautical miles
and knots because that’s how the pilots talk. This is easy - just press # to toggle to FPS, enter
the value, and toggle back to MKS.

The Design Layout Module allows the use of Inches or Centimeters rather than feet and meters.
These are selected in Options-Units. Be careful – it is very easy to get confused by such small
units, and their use is NOT recommended. Still, some users prefer them.

The current units can be displayed by selecting Help–About RDS. While most programs use this
to display only static information such as the copyright, in RDS win this also displays useful
dynamic information including analysis parameter files, program options, fonts, directories, and
more.

There is also a units conversion utility in the Options menu allowing you to type in a value in
one system and have it converted to the other system. This includes typical aircraft design-related
values such as wing loading and specific fuel consumption.

The RDSwin Cost Analysis Module, described below, allows conversion of inputs and results into
different currencies via the Options menu. 16 common international currencies are included, and
others can be added as described in the last menu option. All cost values are actually stored as
dollars (US$), and converted to and from other currencies using the values in the Resource file
RDSCostC.RTX. You can edit this file to change the currency conversion values or to add another
currency. Read the instructions carefully!

29
Useful Tools for Designers
The main menu Tools tab offers a collection of routines useful for designers, including:
 Simple Calculator
 Units Converter
 Calculate Standard Atmosphere
 Calculate Flight Data from True Airspeed
 Calculate Flight Data from Calibrated Airspeed
 Table of True Airspeed vs. Altitude

Most are obvious in their usage – “Enter one or more altitudes to calculate the ICAO Standard
Atmosphere”, etc…

The Quick Initial Sizing routine allows for rough initial sizing to be done prior to making a new
design layout. It makes an approximate Aircraft Data File (.rdsDAT) using statistics for empty
weight, Cfe for parasitic drag, Oswald's span factor for K, and simple inputs for SFC. After the
DAT file is created, a sizing mission is created from a few inputs or you can exit this routine and
build a better mission in the Sizing module.

Aircraft/Engine Data File and Analysis Input Grid Tools allow you to insert and delete columns
or rows as appropriate, scale data, get geometry from the design TAB file, and much more.
Operation and inputs should be obvious, once you are familiar with the RDS win data input grids.

WriteDataFileForSimulators does just that. It writes the information in the Aircraft Data File
(.rdsDAT) to a text file suitable for loading into simulator programs. This was originally
developed to feed inputs to the famous TacBrawler air-to-air combat model, but should be
adaptable to most such programs. The text file data output includes thrust, fuel flow, lift, drag,
and weights.

When in the Design Layout Module, you can select ScaleWholeDesignLayoutToInputWo to do


just that. Based on the change between current and revised takeoff gross weight Wo, the entire
design is automatically scaled. This is smart enough to scale the wing and tail (holding tail
volume constant), stretch the fuselage, stretch the landing gear legs, resize the tires, and scale the
engine, inlet, and nacelle. But, it isn’t perfect so you’ll still have some work to do.

Curve Fit Tool for Creating Statistical Equations


It is very common in conceptual design to find yourself unable to estimate a parameter, especially
weight, by any means other than statistical. The new Curve Fit routines make it easy, prompting
you for the required data inputs to create statistical equations in various forms. When finished,
they provide a graph of the actual data versus the curve fit results, and list out the resulting
equations in a form that can be copied into computer programs or spreadsheets.
There are three different curve fit routines. First is an X-Y Curve Fit that finds the best fit through
your data for five different equation forms (listed below with sample results):

linear : y= a+b*x = -14.+8.*x


log-log (exponential): y= (10^a)*(x^b) = 1.*x^2.

30
log Y vs X : y= 10^(a+b*x ) = 10^(0.2021+0.2352*x)
log X vs Y : y= a+b*log10(x) = -18.985+64.72*log10(x)
elliptic : y= sqrt(a+b*x^2) = sqrt(-267.35+40.119*x^2

Usually the best equation forms are linear or exponential (straight line on log-log graph paper),
but sometimes the others are useful too.

The second routine allows such an exponential fit to your data, but constrained to a given value
of the exponent C. This is often needed to force a curve fit to a reasonable result, especially when
you have just a few data points.

These first two routines require you to enter your X-Y data each time they are used, so you may
wish to save the data in a separate text file then “cut and paste.”

The third routine is a sophisticated Multivariable Exponential Fit that finds exponential equations
for many independent variables, of form:

Y = b*(X1^C1 * X2^C2 *...)

It is also possible to add a data offset constant term so that the final equation is of form:

Y = a + b*(X1^C1 * X2^C2 *...)

To run this routine* you must have already created an input data file, using a text editor or your
spreadsheet program. Sample files are provided in the RDSUser folder, along with two
explanatory files that can be viewed in any text reader (0Sample_NormalArray.dft and
0Sample_SquareArray.dft). Make sure that they are saved in plain text format, preferably
separated with pipe symbols or commas.

The user often has to “play” with the multivariable curve fit routine to find a useful equation. To
facilitate this, you can enter and fix exponents for any of the independent variables. This is often
used when creating statistical equations for empty weight fraction (We/Wo). A more-realistic
curve fit equation may be created by first finding the exponent C for the case where Wo is the
only independent variable, and then fixing that exponent while the routine looks at other variables
such as aspect ratio or design Mach number. This is a tool, not a magic wand!

File Names
RDSwin uses specific six-letter† filename extensions beginning with ‘.rds’ then D for Data,
followed by two more letters chosen to help you remember the module they are used for. For

*
This is an updated version of the program that Raymer wrote years ago and used to create many of the statistical
equations in his textbook, especially the We/Wo relationships in Chapters 3 and 6.

In versions of RDSwin prior to V10, filename extensions had only three letters beginning with 'D'. Unfortunately,
newer versions of Windows and Windows programs have increasingly claimed the possible three-character
filename extensions including those long used by RDS. Thanks, Bill. The old extensions will still work but
RDSwin will encourage you to change them to avoid confusion, especially when Saving your files. A utility
program is provided to easily change all of your old filenames (RDSwinFixExtensions.exe).

31
example, 'DAA' means 'Data for Aerodynamic Analysis, 'DWT' is used for Weights data, and
'DSN' is for Design files.

Upon entering RDS you are prompted to give a Project Filename which, with the appropriate
extension, becomes the default filename for the various modules' data. For example, if your
project filename is MYPLANE, then your default files are:

Design Layout Module: MYPLANE.rdsDSN


Aerodynamics Module: MYPLANE.rdsDAA
Weights Module: MYPLANE.rdsDWT
Propulsion Module: MYPLANE.rdsDPR
AIRCRAFT DATA FILE Module: MYPLANE.rdsDAT
(Uninstalled jet engine data) MYPLANE.rdsDJT
(Uninstalled turboprop engine) MYPLANE.rdsDTP
Sizing & Mission Analysis Module: MYPLANE.rdsDMS
Performance Analysis Module: MYPLANE.rdsDPA
Cost Module: MYPLANE.rdsDCA
Optimizer Module (Pro only): MYPLANE.rdsDOP
ROAST Trajectory Module (Pro only): MYPLANE.rdsDTR
ROAST Trajectory Script (Pro only): MYPLANE.rdsDTS

When RDSwin prompts for a filename either to read-from or to save-to, it will offer your current
project filename plus the appropriate extension as the default. You may instead choose to enter
another filename. RDSwin uses the standard Windows API file dialog box, so you can change
filenames and directories as you wish.

You can also use filename extensions other than those listed above, but be aware that RDS will
not list files with other extensions when prompting you to input a filename. RDS does check
before reading a file to ensure that it is in fact the correct type of file, i.e., that you haven't told it
to read a Performance Analysis file into the Sizing & Mission Analysis Module.

Do not use additional periods in file or project names. My.Cool.Plane.rdsDAT is not allowed.

You should store all of your design and analysis files in a folder in the Windows User directory,
something like C:\Users\[yourusername]\RDSUser\. Otherwise, Windows Update or System
Restore might “restore” your design files to an earlier date, losing all your work after that date.

Customizing RDSwin-Pro
The Professional version of RDSwin is deliberately coded to allow companies and government
organizations to customize its operation and outputs. Once the program is installed and working
properly, certain Resource and image files can be edited or replaced as desired. Be very careful
- you are “hacking” the operating parameters of the program and if you do it wrong, the results
may be unpredictable. In the worst case, RDSwin simply won’t work anymore!

32
As mentioned above, the Title Block “RDS” logo can be replaced with your own company logo.
Find CompanyLogo.bmp in the RDSuser directory, open it with a graphics program, and paste
your company logo into that file, then save it without changing the name.

If you select “Use My Web Browser” to show and print results, the web page created by RDS
includes the following at the bottom:
RDS-Professional
Licensed to (your company)
Use of results subject to restrictions in license agreement
Visit the RDS-win Website and AircraftDesign.Com
RDSwin is the companion software to Dr. Raymer's
bestselling textbook AIRCRAFT DESIGN: A Conceptual Approach

You can add your own company information, privacy/proprietary statement, copyright
declaration, and anything else you wish. In the RDSresource subdirectory find file
RDSMain2.RTD. Open it with WordPad or NotePad (not Word, which can mess up formatting).

Find the string “{WebShowPix” and add additional text strings below it where indicated. Use
HTML tag <br> to create line breaks, and don’t forget to change the number 3 to the total number
of lines, including the current 3 lines (and don’t change those lines!). When you save, make sure
that the filename isn’t changed, especially the .RTD extension.

These text strings are appended to the HTML source files, so you can use any HTML tags. Note
that a quotation mark will confuse browsers - use &quot instead. You can do fancy website
things here, but be careful! Also, you can only add 18 lines of text.

Some have complained about the non-professional sounding phrase "Fudge Factor" as used in
the RDSwin input grids. You can change that. Use WordPad or NotePad (not Word) to open
resource file RDSMain3.RTX. Under the header {Startup strings} is a text line saying 'Fudge'.
Change it to any 5-character phrase you wish, such as Adjst or Calib, and save. Do not change
the lines FudgeFactorsOff & FudgeFactors On - they will be fixed automatically, along with all
other uses of the word Fudge.

File RDSwinParams.RTD in the RDSresource subdirectory contains most of the internal “magic”
parameters that control mouse operation, font scaling, sizing of displays, and many more. This
file lists the actual internal variable names, which are fairly self-explanatory. A fuller explanation
is provided to their right. The value after the equal sign is the actual value read into the program
upon startup. You can try changing these, but do so at your own peril and don’t ask us to fix it if
your little experiment doesn’t work!

It is even possible to customize the language. RDS win is deliberately coded with text prompts and
outputs contained in non-compiled text files. Changing RDS win to another language is possible if
that language can be expressed with the normal ASCII character set.

Kindly do not attempt this without assistance from Dr. Raymer or his designee. There are many
places where a longer or shorter text string would mess up the formatting, and some modest
reprogramming may be necessary to get it to work and look proper. But it can be done!

33
Limitations and Assumptions
RDSwin employs certain assumptions that may cause erratic operation if the user attempts to use
RDS for unusual designs. Velocity is assumed to be Mach number if values given are less than
10. Thus, one cannot use RDS for an aircraft flying at under 10 kts, and, for other reasons, over
about Mach 5.

Another limitation in RDS is intended to protect the user from obtaining false extrapolations of
data. RDS will only calculate performance within the provided range of the engine thrust data
in the Aircraft Data File. For example, if the engine thrust data only goes up to Mach .8, the
flight envelope will be cut off at that point even if there is still excess thrust-minus-drag. To
ensure that the indicated maximum speed on the flight envelope really is the true maximum, you
must provide thrust data at higher speeds. You can, of course, check if thrust equals drag at the
indicated maximum speed by plotting the 1-g Ps contours.

Also, it is a good idea to provide thrust and SFC data for the entire input grid of altitudes and
velocities, even though the engine may not be rated for, say, high speed/low altitude operation.
If zero values are left in the input grid, RDS may linearly interpolate from real values to zero
values, creating strange looking diagonal lines on the graphs, and possibly creating errors in the
sizing and performance results.

Another thrust limitation is that RDS tests on {T/W > 2} as an indication that instead of T/W and
W/S, the user has provided actual thrust (T) in units of force (per engine) and wing area (S) in
units of area. Therefore, an aircraft with thrust more than twice the takeoff weight must have
thrust input as force (T), not ratio (T/w), and the wing must be input as (S), not (W/S).

The standard atmosphere model in RDS cuts off at 150,000 feet. The highest turning load factor
RDS calculates is 9 g's. Extreme negative values of Ps, fs, and rate of climb are clipped off the
graphs so that the more-relevant values can be read. If a supersonic design has a negative Ps
(thrust-minus-drag) in the transonic regime but a positive Ps at higher speeds, the logic to graph
the flight envelope may be confused. In such a case, the 1- g Ps contours can be used to manually
construct the correct flight envelope showing the "bubble" of sustained supersonic flight.

RDS contains certain analysis approximations used to avoid a large number of additional inputs
and calculations for (usually) a small change in results. These are seen especially in Balanced
Field Length, single engine climb, and certain types of aerodynamics analysis. An ASCII file
(RDSconst.rtd) is used to store these approximation constants. You can, if you wish, view and
edit these constants. Be careful! RDS isn’t smart enough to fix your mistakes – what you change,
it will use. Also, each user can define a personal version of this file. These are stored in
subdirectory RDSUser and are created by copying the original file, giving it a similar name,
adding additional characters just before the period, such as RDSconstDan.RDT.

34
Bugs and Boo-Boos
RDSwin is a very complicated program with extreme flexibility as to user options. Not every
combination of commands, escapes, and data input values could be anticipated, so the program
may get “stuck” in some cases. Problems are most likely when you jump around a lot. This is
permitted as part of the flexibility built into RDSwin but you may go too far, leaving the program
waiting for an input that can’t be properly entered. For example, making a graph from an input
grid, then using the pulldown menu to change the background color, then cancelling the
operation, then clicking somewhere else might leave RDS “hung” with the graph or input screen
showing but nothing happening. If this happens you can usually use JumpTo from the pulldown
menu to go back to the input screen.

Another source of trouble could be Escaping out of options that you have selected. Try to avoid
selecting then cancelling options, and if you must, do so with the Cancel or Exit option presented
on the menu rather than just pressing Esc (unless told to do so, as in many DLM commands).

During development, Escape would sometimes go back to the RDS win main screen but without
doing the necessary redraw. If you are still seeing a grid, graph, or design display but when you
move the mouse around, flowchart buttons mysteriously appear (Aerodynamics, Weights,…),
just select JumpTo…RDSMainPage to force a redraw. All known cases of this have been fixed.

Toggling to another Windows program then returning to RDS win occasionally leaves a gray box
over part of the screen. Certain other programs aren’t “polite”, and RDS is unwilling to fight
them by insisting on being “on top.” Just hover over the RDS pulldown menu area at the top of
the screen, and if that doesn’t work, click on the screen.

Disables in the pulldown menu are very complicated. It is possible that some needed disables
aren’t active all the times they should be. If you click on a command and nothing seems to
happen, first consider if perhaps the command is inappropriate for the module you are in (such
as trying to scale a design component when you are in the Cost Module).

If the program simply stops responding, first look down to the Windows Task Bar for an error
message box. Click on it and select Cancel. Otherwise, first try Esc, then try clicking the mouse
button over the center of the page, then try cursing, then press Ctrl-Alt-Delete to activate the
Windows Task Manager. Highlight RDSwin, press EndTask, and try again.

Do not reset the Display Property of your RDS win shortcut to Full Screen (this can cause conflicts
with the graphic window). If you attempt to run RDSwin but find yourself stuck on a gray screen,
use Ctrl-Alt-Del to exit, and then reactivate ‘Display in a Window’ by right-clicking on the
shortcut, and/or right-clicking on file RDSwinPro.exe.
Also, do not changing the Windows Display text size to something larger than 100%. If the usable
RDSwin screen is smaller than its Window, right click on the desktop and select Display Settings.
Make sure the slider for “Change the size of text..." is set to 100%. If it had been set higher,
restart your computer before running RDS win.

35
Each time it closes, RDSwin updates a configuration file called “RDSconfg.rtd” which is kept in
the main RDS directory (normally C:\RDS-Win). This includes what project the user was
working on, what background image and colors were in use, and the full path names of the various
subdirectories in use. If this file is corrupted, RDS win literally can not “find itself” and will not
be able to run. This should never happen, but if RDS win hangs up and does nothing, perhaps with
a gray screen shown, try deleting this file and starting again. RDS win will briefly flash "No
Configuration file - RDSwin will make a new one." No data files will be lost, but you’ll have to
pick your colors and background image again.

If you experience a bug please email a detailed description to rds@aircraftdesign.com. Explain


what module you were in, what you had just input or done, and exactly what RDS did wrong.
And, please accept an apology for the inconvenience.

Raymer Regional Transport Design created in RDSwin-Pro then exported and rendered in RhinoCAD

36
DESIGN LAYOUT MODULE
DLM Overview
The RDSwin Design Layout Module (DLM) is a fast and powerful CAD program for the
conceptual design of aerospace vehicles. It allows you to quickly create a new design, extract the
geometric information needed for design analysis, and then revise the design based on analysis
and optimization. DLM is a completely integral part of RDS win, coded and compiled with the rest
of the program.

RDSwin DLM is uniquely suited to Aircraft Conceptual Design because it knows what an airplane
is. DLM has dozens of airplane-specific design capabilities to rapidly create, modify, and analyze
your design. RDS-DLM even uses the aircraft industry SAWE RP8A (Mil-Std-1374a) Group
Weight Statement component categories to identify the nature of the design’s various parts and
to simplify the analysis interface.

When you’ve finished with a design, DLM provides a simple data interface to the Aerodynamics,
Weights, and Propulsion Modules and hence to all RDS performance analysis and optimization.
It literally takes under a minute to analyze the design geometry and make it available to the
analysis routines. DLM produces the tabular geometric information required for reports and
further analysis, and in RDSwin-Professional, produces export files to transfer the design to other
CAD and analysis programs. RDSwin-Professional can also automatically modify your design
geometry based on optimization results, changing wing parameters, fuselage fineness ratio,
engine size, and more.

DLM features a unique capability – the airplane can be “flown” around the screen using the
mouse as a control stick, or using an attached joystick game controller much as a pilot flies an
airplane. Also, individual components can be “flown” around the airplane to assemble the
airplane. This can be done in any screen view, even isometric or perspective. The user inputs are
in the aircraft axis system, not in screen coordinates. Design is therefore more three-dimensional
and intuitive. A click-drag assembly method is also available in side, top, and rear views. You
can also assemble the airplane using location commands from the pulldown menu, but it isn’t
nearly as fun.

There has long been a controversy in the CAD world over the relative merits of “parametric”
versus “non-parametric” or “specific” representations of a design geometry. In the parametric
approach, the computer does not store any actual component surface geometry such as the XYZ
points of a cross section. Instead, the design is stored as parameters such as “wing span=x, root
chord=y, etc…”

The parametric approach naturally lends itself to parametric trade studies – by changing one
value, the geometry is changed. For a simple design the parametric approach can also offer
reduced storage space but this becomes problematic as the design gets more complicated and
real-world. Unfortunately, the parametric approach cannot extend to the sort of real-world design
challenges that are found when a design is developed in enough depth for transition to detail
design and fabrication. The parametric geometry simply won’t allow it.

37
RDS-DLM offers the best of both worlds, in that its geometry is stored as mathematical curve
equations or as stacked cross-sections of points, but RDS-DLM also allows parametric
development of typical components and more important, allows parametric modification of them
for trade studies. For example, a wing can be created parametrically as a simple trapezoidal
reference wing then extensively modified to a complicated planform shaping. After that, it can
be parametrically changed with a single input to reflect a new reference wing configuration, and
all the real-world changes that have been made are remembered and incorporated. This is done
with smart mathematics, not a simplified parametric design approach.

For a detailed discussion of the mathematics and modeling used in the RDS win-DLM, download
Dr. Raymer’s AIAA paper at www.aircraftdesign.com/Raymer-ASM2011-AIAApaper-
RDS_Geometry.pdf .

DLM Operation
Like all RDSwin modules, DLM is entered by clicking on its button on the main screen flowchart,
or by opening a new or existing design file (filename extension DSN), or by selecting
JumpToDLM. This activates the many DLM-related commands on the main pulldown menu,
mostly found in the Component, ShapeComp, ScaleComp, and Assemble pulldown menus.
Design displays are selected in the View pulldown menu. Design and Component Notes are
accessed from Edit. The many capabilities in the Drafting pulldown menu are helpful during
design layout for aligning components, checking clearances, and the like.

A new design is created one component at a time, using the NewComponent and NewWingTail
pulldown submenus. These include most of the obvious aircraft components including wings,
tails, fuselages, engines, nacelles, seats, canopies, landing gear, and other required components.
For a component which is not covered by those existing options, NewEmptyComponent can be
selected and the geometry created, one cross-section at a time.

Components are then assembled into a complete design by entering their X, Y, Z and roll, pitch
yaw. Better yet, component placement can be done visually using FlyAssemble or
DragAssemble, as described below. Components such as the fuselage can then be visually
reshaped to wrap them around the internal components and align them as needed.

RDSwin allows “click-drag” with the mouse for shaping lines and surfaces. The user presses and
holds the left mouse button which grabs the nearest point to be used as a “handle”. As the point
is moved, the line or surface is instantly reshaped and shown. This makes RDS win operate more
like other Windows CAD programs, and is very nice in operation.

The double-input method used in previous versions of RDS win is still available and can be toggled
in the Options pulldown. With this, first you click and release the mouse button to indicate the
point that you wish to move, and then you click and release to indicate the desired new location.

This double-input method does have its advantages. It allows toggling to extra-fine movement of
points, lines, and components as the mouse is moved, using the speed controls S-D-F described
below. It allows the user to select a point by its number, or by numerically-entering its location

38
instead of visually with the mouse. Selection by point number is especially useful when several
points are close together or degenerate.

Double input also allows the user to enter the desired final location numerically or via a “ditto”
in which the last location is reused (user presses the quotation mark on the keyboard *). But, the
double input method is slower for the routine “move it here” operations and is confusing to people
familiar with other programs.

There are a number of hot keys in DLM, to speed up options on the pulldown menu. Below is a
summary for your reference. This list can be shown on-screen by pressing H.

DLM HOT BUTTONS AND DISPLAY CONTROLS


Select Components for Viewing V
Select Components for Edit E
Move Screen Image: up-down-left-right Arrows
Rotate view angle in Pitch & Roll: Ctrl-Arrows
Rotate view angle in Yaw: Shift-Arrow or PageUp/PgDown
Zoom out/in: Shift-Arrow or Insert/Delete
Perspective Distance farther/closer: Home/End
Mouse & key action speed: Slow/Default/Fast = S / D / F
Enter FlyView or FlyAssemble Mouse operation: Alt-M
Exit DLM (return to RDS main screen) Alt-J-J-R or Esc

Orthographic View (ends Perspective, keeps angles) O


Isometric View (ends Perspective, changes to Iso) I
Views: 1=Side 2=Top 3=TopUp 4=Rear 5=RearSide
Three-Views (various display formats): 6 to 9 and 0
Zoom image to full screen (press if airplane is lost) Z
Numerical entry of rotation, perspective, & zoom N

Axis display (toggle: none/global/stations/local) A


Trapezoidal Wing (toggle: none/wing/all) T
Mirror across global centerline (toggle) %
Reflect across component centerline (toggle) ^
Show or hide other components in Relative Views (toggle) &
Render Current view (shade with hidden lines) R

Measure lengths and angles (iso & views 1-8 only) M


Find Location (side, top, and rear views only) L
Bitmap of screen image B
Toggle between British & Metric Units #
Toggle between Screen and Printer XY scaling ratios /

Change Display #Lines & Points +


Do Automatic Smoothing of SuperConic Surface Component ~

*
Apparently the use of two vertical lines for ditto, meaning ‘repeat the above’, goes back to cuneiform tablets
from almost 3,000 years ago!

39
DLM Component Geometry
RDSwin-Pro components can be defined in one of three geometry schemes, namely the direct
point storage scheme, the better SuperConic cross section scheme, and the most-powerful
SuperConic surface scheme. All use cross sections stacked in the component local X-direction.
All are easy to design, view, and modify using RDS win commands.

In the simplest scheme, those cross sections are formed by connecting stored points which are
the actual surface definition. This scheme is obvious and robust, and is commonly used for
smaller internal components. It is also used for wings and tails in which case the stored points
are the actual airfoil coordinates at each spanwise location.

figure 13. Point Cloud (connected points stacked in component X direction)

In the two other component geometry schemes, the cross sections are defined by “SuperConic”
curves. XYZ points control the shape and can be moved around to obtain the desired geometry.

SuperConics are modified 4th degree Bezier polynomials with a quartic mathematical
representation* developed by Robert Maier† of Rockwell-North American Aviation. This allows
their shapes to be designed and controlled in a manner similar to the classic conic lofting used
on aircraft since the 1940s, when they were first used for the North American Aviation P-51
Mustang. Unlike conics, the SuperConic curve is permitted to reflex, and the endpoint tangents
don’t have to meet. This makes it much easier to design and modify complicated shapes.

SuperConics are each defined by five control points. The curve has two endpoints plus a point
somewhere along the tangent line from each of the endpoints. The fifth point is called the
"shoulder point" and is on the curve, somewhere in its middle‡.

*
Raymer, D., “Conceptual Design Modeling in the RDS-Professional Aircraft Design Software,” AIAA Paper
2011-161, AIAA Aerospace Sciences Meeting, Orlando, FL, 2011

Maier, Robert., “Quartic Curves”, Rockwell/North American Aviation TFD-78-718 (internal document), Los
Angeles, CA 1978.

This is different from a classic Bezier Quartic Polynomial where the middle point would be floating off the line
and acting like a “magnet” pulling the line to itself. Mathematically placing the middle point on the line makes it
much easier to define and shape the desired curve.

40
Design using SuperConics is very similar to design using Conics as classically done on the
drafting table, but with far more power. The figures below show the two types of curves – both
have start points (A and B) and a shoulder point (S). The main difference is in the control of the
tangent lines to the end points, shown as dotted lines below. For the classic conic these tangents
must meet at the point labeled C, and C itself is used as a control point for conics.

Classic Conic Curve SuperConic Curve

figure 14. Conic vs. SuperConic

For a SuperConic, there are two separate control points, C A and CB. They do not have to meet or
even be close to each other. Also, with a 4th degree polynomial representation the SuperConic
curve can include a reflex – unavailable in a regular conic. Curves such as those shown below
are just as possible and easy to construct as the conic look-alike shown above.

figure 15. SuperConic Shaping

In RDS-DLM, connected SuperConic curves share an endpoint so cross sections always have 5,
9, 13, 17, or 21 points, corresponding to 1, 2, 3, 4, or 5 SuperConic curves. Actually, up to seven
SuperConic section curves are permitted, but normally just 2 or 3 SuperConics will suffice for
even a complicated cross section.

For components defined by SuperConics, RDS stores these control points for each cross section
and generates the actual points shown on the screen only when drawing. When reshaping a cross

41
section, the SuperConic control points are shown and can be moved or otherwise modified, and
the resulting section points are drawn.

An RDSwin component is limited to 30 cross-sections, which is more than enough for typical
aircraft components. For a component defined by surface points, the limit for the number of
points is 100. Generally, wings and tails are the only components defined by surface points.

In the SuperConic cross section scheme, the cross sections designed by the user are
mathematically defined and can be plotted with extreme accuracy. However, in the longitudinal
direction these cross sections are linearly connected. This is normally adequate for aircraft
conceptual design purposes including analysis and viewing, and is provided in RDS win-Student.

figure 16. SuperConic Cross-Sections (stacked in component X direction)

RDSwin-Pro allows a third, more powerful method, the SuperConic Surface Patch. Here the
longitudinal geometry is exactly and smoothly defined by the application of SuperConic
mathematics, just as in the cross-section direction. This allows the design of complicated
geometry with amazingly few inputs, and includes an automatic longitudinal smoothing
command that has to be seen to be believed.

In the field of CAD mathematics, a “patch” is a region of surface geometry that is defined by a
single parametric equation. In RDSwin-Pro, this equation is formed by an extension of the
SuperConic equation described above. Just as five points defines a SuperConic line, five
SuperConic lines define a SuperConic Surface patch (ie., 25 points in all).

A generic 4th degree SuperConic patch geometry is shown below. Note that points 1 through 5
define a single line. A line in the other direction is defined by points 1, 6, 11, 16, and 21. In a
similar fashion, a patch in RDSwin defines both cross section and longitudinal lines.

42
figure 17. SuperConic Patch Schematic

figure 18. RDSwin SuperConic Patch Geometry (surface and slope control sections)

The figure above shows a single SuperConic patch as used in an RDS win-Pro component, seen in
perspective. The same geometry is shown below in side and top view (with center section). Note
that longitudinally, the patch is defined exactly as a single SuperConic is defined, with a start
point A, shoulder point S, end point B, and slope control points C A and CB.

43
figure 19. One RDSwin SuperConic Patch – Side & Top

The difference is, for a surface patch these are entire cross sections rather than single points. The
surface patch starts at the cross section A and goes to the cross section B, passing through a
middle section S. At the start and the end it follows tangent lines defined by the cross sections
CA and CB which create “collars” as highlighted in the next figure.

These collar cross sections are defined by the user, using the same RDS win tools used for creating
and shaping any cross sections. Note that they are NOT on the surface, and instead “hover” over
it, defining slopes at the ends of the patch.

figure 20. SuperConic Patch Collars

44
While this patch is defined with only 25 control points and of those only 9 points are actually on
the surface, it is a full mathematical loft of that region. The figure below shows this, plotting 21
cross sections and 11 longitudinal lines from the control points of a single patch. You could show
more if you wished – the math is fully defined.

figure 21. SuperConic Patch Showing Many Sections and Lines

It is less confusing to show just 3 cross sections and 3 longitudinal lines per SuperConic patch.
This is done using DesignViewOptions-ChangeDisplay#Lines&Points (or use the hotkey, the
plus sign “+”).

That first example above shows just a single surface patch, ie., a single SuperConic in cross
section and exactly 5 of those cross sections. Normally, you would use at least two SuperConics
per cross section (see below), and more if extra-complicated geometry is desired.

45
figure 22. Two RDSwin SuperConic Patches (one longitudinal patch bay)

The examples above have a single longitudinal “patch bay,” ie., a single SuperConic in the
longitudinal direction (defined by 5 cross sections). This is fine for simple components but
normally there will be two or three SuperConic bays in the longitudinal direction, sometimes
more, and each with two or more SuperConics around the cross section. An example showing
two longitudinal patch bays is below.

figure 23. Two SuperConic Longitudinal Patch Bays

Section 5 is the patch ending line for the first bay, and the starting line for the second bay. To
have a smooth continuous surface across section 5, the collar slopes from 4 to 5 and from 5 to 6
must be co-linear. This is assured by the automated smoothing routine described below, or can
be set by the user.

46
The user must also ensure that there are the correct number of cross sections, namely one plus
four times the number of longitudinal patch bays (5, 9, 13, 17,…). RDS win warns you if the
number of sections isn’t correct.

When creating smooth components such as a fuselage (Component-NewComponent), RDS win-


Pro will normally construct them using SuperConic surfaces. Two SuperConics per cross section
are used, and you are prompted to pick 1, 2, 3, or 4 SuperConic bays in the longitudinal direction.
Having more bays allows more complicated geometry but takes more design time. If you wish,
you can insert four more cross sections later, making an additional SuperConic bay.

When creating new components you can have them defined as SuperConic Section instead of
Surface components, but why would you want to?

RDSwin has a powerful automatic smoothing routine that will instantly set the slope control cross
sections using the Method of Akima*. This mathematical technique was developed under contract
to the US Department of Commerce to pass credible curves through statistically-noisy climate
data. Akima has the unique built-in ability to “recognize” colinear points and make the curve
straight in such regions, without any user input.

This automatic SuperConic Surface component surface smoothing routine is called from the
ShapeComponent pulldown menu. It can also be called by pressing hot key “~” (looks like a
curve) when a SuperConic Surface component is active for editing. The figure below shows a
typical result. These are exactly the same surface cross sections (1, 3, 5, 7, 9) as in the figure
above. Only the slope control sections (2, 4, 6, 8) have been changed, in a fraction of a second.
This shape is obviously far smoother – if that is what the user intended.

figure 24. Automatic SuperConic Smoothing (Akima)

The next figure shows a fuselage such as for a cargo aircraft. The top geometry uses typical CAD
smoothing from the given cross-sections. Below that, the Akima-based AutoSmooth routine in

*
Akima, H., 1969, A Method of Smooth Curve Fitting, ESSA Tech. Rep. ERL 101-ITS 73 (Washington, D.C.:
U.S. Government Printing Office)

47
RDSwin-Pro has automatically made a constant cross section region since the middle three cross
sections were found to be identical. And, it has smoothly faired that straight section to the
compound curves of the nose and tail. This took less than a second, with no user input other than
pressing the hot key [~].

figure 25. RDSwin’s AutoSmooth Recognizes Straight Segments

This Akima-based automatic smoothing routine can also be applied to just a single slope control
(collar) cross section, using Shape-AutoSmoothSingleCollar. This prompts you to select an
appropriate section. Normally you’d apply it to both sides of a patch boundary cross section (5,
9, 13,…), but this isn’t done automatically. When you are using StretchCrossSections and have
already selected a collar section to stretch, the “~” hot key will automatically stretch it based on
the Akima result.

Sometimes you may have shaped a collar cross section to give you the right surface shape on one
side of a patch boundary cross section (5, 9, 13,…), and want the collar on the other side to match
it, ie., make the slopes the same in the other direction. This is done with the command
MatchSuperConicSurfaceCollarSlopes. Pick a slope control collar section and it will be matched
to the collar on the other side. Note that if you pick the first or last collar on the component,
nothing happens because there is no opposite collar to match.

For SuperConic Surface components you can auto-smooth an entire single longitudinal line using
Shape-AutoSmoothSingleLongitudinalLine. This prompts you to select a longitudinal line,
which then has its slope control points changed based on the Akima result. When you are using
ShapeByLongitudinalLines and have already selected a line to shape, the “~” hot key will
automatically smooth it the same way.

Note that no matter how it is called, the automatic smoothing routine changes the longitudinal
slope control points in both top view (Y) and side view (Z). This may be unexpected when using

48
the hot keys in StretchCrossSections or ShapeByLongitudinalLines, since those are normally
working only in side view or top view.

When listing perimeters and areas for SuperConic Surface components, RDS win creates and
displays a number of cross sections from the patch geometry. These always include the three on-
the-surface control sections of each patch (odd numbered cross sections).

There is a routine (ComponentTools) to convert a SuperConic Surface component to points,


typically done before cutting out fuel tanks and the like. Another tool converts a SuperConic
Sections component to a SuperConic Surface component, by inserting and smoothing slope
control collar cross sections. It is wise to reduce the number of cross sections before doing so,
and there should be an odd number of sections so that no sections are left over when creating
patches.

There is a potential problem when using SuperConic Surface components. Rendering might be
slow or impossible due to the huge number of render elements generated by the SuperConic math.
To prevent this, reduce the number of section points per SuperConic using View-
DesignViewOptions-ChangeDisplay#Lines&Points. 20 is usually enough.

Non-Planar, Non-Parallel Cross-Sections


Most components used in aircraft design can be defined by stacked parallel cross-sections, where
every point in the cross-section has the same X value. This parallel section format is the RDS win
default for geometry storage, and it simplifies commands, speeds up memory access, and reduces
computer data storage by nearly 1/3.

In certain cases such as the front face of an inlet duct, the usual parallel cross-sections cannot
properly model the desired canted shape. RDS win allows components to be defined with non-
parallel and even non-planar cross-sections. The illustration below shows an F-86-ish fuselage
with a complicated 3-D curve for the first section and a simple planar cant for the last section.

49
figure 26. Non-Parallel and Non-Planar Cross Sections

Another good use of planar canted sections is to make the root airfoil section vertical even if the
wing has substantial dihedral. This is especially useful for flying wings.

A non-parallel component is just like any other component except that every stored point (actual
or superconic) has an X value as well as the usual Y and Z values. The cross section still has a
'nominal' X-location which is shown as a dotted line in certain views and used for selection. If
you later disallow non-parallel cross-sections, all the points' X values are reset to their nominal
X-location.

Commands to design with non-parallel cross-sections are in the CompShape pulldown menu.
CantCrossSections will cant the selected cross-sections by an input angle, about the top, bottom,
average, or origin location. Canting is done by stretching, not rotating the cross-section. The Y
and Z values of the cross-section remain the same. If you give a zero (0) cant angle to any section,
all of its X values are returned to the nominal X-location. Any cant angle or non-planar geometry
is removed.

Caution: the Cant command works by sliding the points of the cross-section in the X direction,
based on the distance calculated to create the commanded cant from a section with no previous
cant or non-planar X positioning. It doesn’t “remember” previous cant angles so, if a section has
already been canted, first remove that prior cant by giving a zero value as described above.

Also, it is dangerous to reshape a section that has already been canted. If you move its points in
Y and Z, the X value is NOT corrected to keep the section planar. It is better to first remove its
cant angle, reshape in Y and Z as desired, then cant it again. The canted section capability should
be considered to be a last-minute adjustment, for geometry that just cannot be modeled with the
normal stacked parallel cross-sections.

50
Another potential source of confusion - when reshaping a canted cross-section, you are looking
down the X-axis, not at a true-view of the canted section. Furthermore, if you view a Slice
through all components, that slice takes place at the Nominal-X location and is perpendicular to
the component X-axis, not through a true-view slice of the canted section. To see such a true-
view slice, get a CutPlane component, place and orient it with the canted section, then do View-
Slice With Cut Plane.

For a non-parallel cross-section component, the powerful ShapeByLongitudinalLines command


allows you to move the points in the selected longitudinal line in X as well as in Y (top view) or
Z (side view). As with the shaping of a single cross-section, slope control points are moved along
with the point whose slope they control.

In ShapeOneCrossSection, numeric input for moving a point (press N after selecting the point)
will allow the entry of an X value as well as the Y and Z value. These X values are in the
component axis system, not “relative” to that cross section. Be careful! Also, do not enter a blank
for X because it will be read as X=0, which is probably not what you wanted! Note that you won't
see any effect of an X move in cross section shaping because the view is down the X-axis.

When first creating a new component it isn’t necessary to decide whether nonparallel cross
sections are needed. Any component can be changed to allow nonparallel cross sections at any
time, using ComponentTools. Also, certain obvious tools such as CantCrossSections will
automatically convert the component to allow nonparallel cross sections.

DLM Axis System and Symmetry

figure 27. DLM Axis System

The RDS-DLM global axis system is shown above. Following the classic drafting table practice
seen at many companies, the X-axis points out the rear of the airplane, Z is up, and Y is out the
left wing. X=0 does not have to be the nose of the aircraft but it often is, at least in the first layout.

51
To meet the expectations of pilots and other airplane people, rotation directions are positive for
right and up. Yes, this gives RDS-DLM a left-handed coordinate system! Don't worry, it doesn't
affect anything and is easily revised when interfacing to other software where it may actually
matter.

A DLM design consists of a number of components, each positioned in the aircraft by the location
and orientation of its own local axis. Components can be positioned, moved, and rotated in
several ways including pulldown menu Assembly, FlyAssemble, and Component Parameters.
Component location is defined by the origin of its axis system, normally at or near the front of
bodies. For wings and tails, the component axis system origin is normally at the wing root and at
the 0.25 MAC location.

To display local axis systems see DesignViewOptions. You can also choose to display the
trapezoidal geometry of wings and tails, showing the 0.25 and 0.4 MAC locations. This makes it
easy to position them for stability considerations.

Components such as wings, tails, and tires are "pre-rotated", where the local component X-axis
is aligned with the global Y axis for wings, Z axis for tails, or -Z axis for ventral tails. Further
component rotations are in addition to these. In other words, a Wing component with zero values
for roll, pitch, and yaw actually has an initial yaw of 90 degrees, and the local X-axis will point
out the global Y-axis. This is automatically set when such components are created, and can be
reviewed and changed in ComponentParameters-Axis Prerotation.

RDS-DLM components can have either of two types of symmetry, or both types. Components
themselves can be symmetrical about their own centerline, so the designer creates only the left
half which is duplicated on the right half*. The other type of symmetry mirrors the entire
component to the other side of the aircraft, across the aircraft global centerline. These are
illustrated below.

CL Mirror + L-R Symmetry CL Mirror + No L-R Symmetry No CL Mirror + L-R


Symmetry

figure 28. DLM Symmetry Options

*
Components which are NOT symmetric about their own centerline are automatically “closed,” with the last point
connect to and moved with the first point. In rare and strange cases the user may wish to violate this, which can be
done by entering the text “<open section>” in the Component User-Defined Information.

52
A final type of symmetry is only for wings and tails. These are normally mirrored across the
aircraft centerline forming left and right surfaces. As an option for special design applications,
they can instead be mirrored in the component X-direction across the component’s root chord
(local X=0).

The figure below illustrates this. In the left illustration we see normal mirror-image duplication
of the tail across the aircraft centerline - the trapezoidal planform root chord is exactly at the
centerline. This is typical for wings and tails, and is assumed in classical aerodynamic analysis
including the methods in the RDS Aerodynamics module.

The center illustration shows a tail that is mirrored in the normal fashion but is moved off the
aircraft centerline. This might be used for an aircraft like the F-15, where the fuselage is so wide
that the effective tail area should not extend all the way to the aircraft centerline. When the tail
is moved out in Y, a gap appears between the roots of the left tail and the right tail.

The right illustration shows the use of root-chord mirroring as might be used for an asymmetric
aircraft such as Burt Rutan’s Boomerang. The Y offset is the same as in the middle illustration,
but the tail is mirrored across its root rather than across the aircraft centerline.

When using root-chord mirroring, yawing the wing or tail will create an oblique surface.
However, the airfoils will no longer be defined in the freestream direction so you must work
carefully to ensure that the analysis produced from such geometry is correctly modeled. The
effective aspect ratio, span, and sweep will be different from the values stored in the RDS-DLM
component, so the aerodynamics will be entirely different!

Mirror Across Mirror Across Mirror Across


Global X, Y=0 Global X, Y≠0 Root Chord Y≠0

figure 29. Wing Mirroring

For a truly wild design, completely different left-right wing panels can be separately created and
placed. Create each separately, selecting "One Side of Global CL" when prompted for symmetry.
Enter desired areas, aspect ratios, and taper ratios as if each wing panel would be reflected across
the global centerline. In other words, if you are creating the left panel which is to have an area of

53
50 by itself, enter 100. When creating the wing panel for the right side of the aircraft, again enter
double the area, but use a negative value when entering aspect ratio. This will invert that wing
panel to the other side of the aircraft. You can instead use positive aspect ratio when creating the
right-side wing panel then later scale it by X=-1. Another approach - create the left-side panel,
copy it, scale it by X=-1, then make whatever other changes are needed.

The reason for treating these one-side wing panels as if they were part of a complete wing is to
allow converting from reflected to nonreflected and back again without changing the wing
trapezoidal geometry. For weights and aerodynamics analysis you must review and revise the
geometric values read from the design into those input grids. It is suggested that the wing
geometric inputs be defined assuming an equivalent total trapezoidal planform based on the total
wing area and total span, the total exposed wing area, and an averaged sweep, taper, and
thickness. However, the classical analysis in RDSwin will not fare well for such unusual
geometries.

Imported STL Components


There is one more component geometry scheme now available in RDS win, namely
stereolithography format. STL files are just a collection of triangular panels, widely used in 3-D
printing and other applications. Most CAD programs including RDS win can export STL files.

In RDSwin, STL files can also be read in to allow importing of components from other CAD
programs. The GetComponentFromFile command, normally used to grab components from other
RDSwin designs, is used. Change the file type to Import STL File and find the desired file. The
selected STL file must have been saved in ASCII form, which you can verify by opening it in
Notepad. It should begin with the word "Solid." If not, open it in another CAD program like
RhinoCAD then Save selecting ASCII format.

Once imported into RDSwin, the STL geometry is stored as a single “component” even if it
actually has many components. This has the normal RDS win component header including name,
location, etc., followed by the STL file’s triangular panels, one line each.

STL components, once read in, and can be Moved, Rotated, Scaled, Copied, and Instanced, but
not redesigned or reshaped otherwise. For that you must create a blank RDS win component and
shape it around the STL component, creating the cross sections using Slice.

Wise users will use this STL import capability sparingly since they take up so much data and will
slow down redraw times for many operations. For example, a simple lofted sphere takes only 2k
of memory in the RDSwin file format whereas it takes 3,821k in STL format!

There is a maximum of 4 million panels per STL component, but it’s better to keep them under
100k panels. If you have too much STL data in your design, there may not be enough panels left
over for rendering and slicing through other RDSwin components.

54
There are many websites today where you can download STL files. Unfortunately, most of their
files are huge. A STL file with only 500 triangular panels * (polygons) is provided in the
RDSsamples folder in STL-ASCII format, and also converted into an RDS DSN file. Enjoy.

Component Selection for View and Edit


DLM design commands need to know which component they should be applied to. Rather than
prompt the user each and every time a command is given, DLM keeps a list of the current “active”
components – potentially more than one since some commands such as Scale can be applied to
many components at the same time.

In fact, there are two lists – one for viewing, and one for
editing. Normally all components are shown, but if you
go to View-SelectComponentsForView, a pick-menu
pops up with all the components listed. Next to each
component is an “O” or an “X”, for “show” or “don’t
show.” Double-click on components to toggle from O to
X, or highlight several at once and click on
“RefreshPicks.” When the O’s and X’s are correct, click on DonePicking †. Note the useful
SelectAll, DeSelectAll, and InvertSelections options.

Yes, this is quirky, but you quickly get used to it and it lets you do things like invert the whole
view list, clear it, or select a range of components instantly. Check boxes would be much slower.

Similarly, active components for the various Edit options (Scale, Shape, Assemble,…) are
selected in Assemble-PickActiveComponents, which works exactly the same. If you pick more
than one active component, you will be prompted to pick the “Leader.” Commands which only
work on one component, such as Shape, will work on the Leader. Commands such as Scale,
Assemble, Component Parameters, and others will be applied to all chosen components.

You can also pick components for Edit by simply clicking on them with the mouse in any single
view including isometric. To select several components, pick one then hold down Ctrl or Shift.
The first one picked is the Leader. Clicking an already-selected component will de-select it. Note
that the routine is looking for the nearest component point, not checking the lines, so you should
click near a cross-section.

In RDSwin-Pro, you can define and name a collection of components as a Group. This lets you
quickly select multiple components that are often viewed or edited together, such as the landing
gear wheels and struts. Group lists are stored with the design layout for later use.

If you select a Scale or Shape command when you have not yet selected an active component,
DLM will automatically take you to the appropriate menu to choose one. After you finish the

*
The Thinker (Le Penseur), 500 polygon STL file courtesy Windham Graves, Montgomery, AL

You must double-click or select RefreshPicks before using DonePicking. A component which is highlighted does
not change its status when DonePicking is selected.

55
command you selected, the active components will remain active for a further command. If you
want to change it for the next command, just go to Assemble-PickActiveComponents again.

The active components are shown in a different color, chosen in the Options menu. This
continues until you deliberately Clear the active component list. Note that sometimes in a side
view the active components are drawn in the proper contrasting color but then RDS draws the
mirror image right on top of it, covering up the contrast so that it appears to have not been
selected. To make sure it has been selected, press I to see the design in isometric, which will
show the proper contrasting color.

Viewing Your Design


DLM makes it easy to view your design in the side, top, and rear directions typically used for
aircraft. There are also five different three-view displays plus orthographic, perspective, and
isometric views. These are all available from the View pulldown menu, where you can also zoom
displays and select from a number of display options.

One peculiarity – if you are already looking at a perspective view and you select orthographic,
you get a view from exactly the same direction but with perspective distance set to “infinity”,
i.e., no perspective distortion of the image. This might be too subtle to notice, and you’ll wonder
why nothing happened. Similarly, if you are in a side, top, or rear view, and you select
orthographic, the drawing will be exactly the same as before until you rotate it. After all, a side
view is just an orthographic view from the side! Select isometric if you want to see the design
rotated to the “looking-down-from-the-front-left” view you were probably expecting.

ViewMoveAndRotate allows you to slide the image around the screen and change its rotation
angle and perspective distance by preset increments. The “speed” of those increments can be
changed – select Nudge, Move, or Jump.

These pulldown menu view commands are easy to use and perfect for beginners and occasional
users, but design experts will get tired of scrolling up and down through menus to change the
view. RDSwin DLM allows changing the view with single-stroke hot key commands. These are
admittedly arcane, but aren’t that difficult to learn. Pressing numbers 1 through 5 produces a
single view, namely side, top, top-up, rear*, and rear-up. Pressing 6 through 0 produces various
three-view displays. Don’t remember? Just press a number!

Obviously, I is for Isometric, O is for Orthographic, P is for Perspective (not Print, as in input
grids), and Z is for zoom (fill screen).

The most obvious – arrow keys can be used to move the display up, down, left, or right. The
arrows are also used to “fly” the airplane in roll, pitch, and yaw. Holding down CTRL while
pressing an arrow key controls pitch and roll, just like the pilot’s control stick. Pressing the down
arrow, which points towards you, produces nose-up. This is obvious to any pilot but perhaps
unexpected for others!
*
Front and Rear views are the same in wireframe viewing, but are obviously different in the real world. To
quickly get a front view when Rendering, press [`] – the button to the left of the number one.

56
Holding down the Shift key while clicking left or right arrow works like rudder pedals,
controlling yaw. Shift-up/down controls zoom. These options and more were listed at the
beginning of this section and can be seen on-screen by pressing H.

Note that these arrow rotations are always available in DLM, but similar rotations using the
mouse are only available in FlyView as discussed below. This is required so that the mouse can
still be used in the pulldown menus.

As described below, a game controller joystick can also be used to “fly” the airplane display
around the screen, or to “fly” individual components into position. This works in any display but
will be noticeably slower if you are not in FlyView, because RDSwin has to check a lot of other
things for each redraw.

The orthographic and perspective viewing direction is normally set by your numeric inputs for
roll, pitch, and yaw, or by “flying” the airplane using arrow keys or a joystick. You can also see
your design from a specified location. This acts just like positioning a camera then snapping a
picture.

To make this easy and amusing, there is a “camera” component available in


RDS_CompBank.rdsDsn called “CameraForViewing.” It looks vaguely like the Hasselblad that
the astronauts took to the Moon. Get it, make it the active component for edit, and then position
it as desired and change its angles to point it at the desired scene.

Next, select View-Relative-Rear. You’ll see a wireframe close-up of the back of the camera.
Zoom out using View-ZoomOut or by repeatedly pressing the [Insert] button until the whole
image is shown. Press [R] for a Rendered image (see below). Render does not show the camera
since it is identified as a 'non-real' Component Type. To hide the camera in a wireframe image,
Scale it in XYZ by 0.001 (then use Ctrl-Z to restore its size).

The Camera's distance from the geometry being viewed does NOT result in a Perspective image.
Relative View always shows an image from infinity, ie., an orthographic projection. To get a
Perspective image, repeatedly press the HotKey [END]. This makes it appear that the camera has
moved closer, and the image is more distorted by perspective. Pressing [HOME] moves the
camera farther away, reducing the amount of perspective distortion.

You can even move or rotate the camera while in this Relative-Rear view, using the Assembly
pulldown menu options or FlyAssemble. This is a bit confusing, though, because the view is
always relative to where the camera is right now. It appears stationary on the screen while the
airplane seems to move in the opposite direction.

These instructions are available in the Component Notes of the CameraForViewing.

One special component is viewed in its own unique manner. A center of gravity component, as
defined by SAWE Type Code (Non-Physical Component–Center of Gravity) and available in the

57
Component Bank, is actually defined as a small sphere. However, when it is drawn by RDS, a
traditional CG symbol is superimposed upon its location. This looks much nicer.

Sometimes it is desirable to prevent certain components from appearing in all views. For
example, if 200 seats rows are used for an airliner, it would be a big waste of time to redraw each
seat in rear view. Similarly, a wing box fuel tank is usually needed only in top view.

To allow for this, each component has its own ViewingCode which can be changed in
ComponentViewOptions. When selected, RDSwin asks if you wish that component shown in side,
top, rear, isometric, and in cross section cuts. Next it asks if you want to cap the ends of the
component (otherwise, a rendering of a wingtip shows the insides, and a section slice doesn’t
close out the shape). Following that you are given the options of specifying the color used when
rendering that component, instead of the default color selected by RDS win which is simply based
on the current background color.

figure 30. Slice through airplane with and without Component End Caps

The actual component ViewingCode as stored with the geometry can be seen and changed in the
AllComponentParameters display box. It’s a text string with 6 digits, either 1 or 0 (show or don’t
show), corresponding to side, top, rear, isometric, and in cross section view. The word “cap” is
appended if the component is to be capped when rendering, and if you’ve selected a color for
render, its hue is displayed (for example, 11011cap hue 40). You can edit this directly once you
know the code, but if you mess it up, your component may disappear!

Internal Programming Note: Viewing and component rotations are based on Homogeneous
Coordinate Transformations, with ordering Roll-Pitch-Yaw. This form of rotational mathematics
is more intuitive for aircraft designers than the 2-parameter Quarternions of many CAD systems.
When the aircraft's nose is towards the left and it is substantially upright, the views produced by
changes in roll, pitch, and yaw look as expected, and feel like you are flying the airplane.
However, when the airplane is already upside down or pointing at some extreme angle, changes

58
in the roll, pitch, and yaw display parameters may produce unexpected results. If you get
confused, just press 1 for a side view, or I for an isometric view.

FlyView
FlyView mode allows moving and rotating the design view display via the mouse, the way a pilot
flies an airplane. When you enter FlyView, the cursor changes to a 4-arrow cross indicating
motions of your “control stick” and is trapped on the upper-right edge of the screen.

Motion of the mouse directly “flies” the airplane. Moving the mouse by itself slides the display
around the screen. With the Ctrl key held down, the mouse becomes an aircraft control stick,
pitching and rolling the plane around its global axis system. With the Shift key * held down, left-
right mouse movement yaws the airplane, and up-down motion zooms the display in or out.

Press S for Slow, D for Default, or F for Fast to change the mouse sensitivity during FlyView.
You can press S or F multiple times to get extra slow or fast. These controls are shown in figure
31, below. Note that Ctrl-MouseDown rotates the nose UP, ie., positive pitch. This looks odd in
print but to a pilot, is the expected response. As the old pilot joke goes, “flying is easy – just pull
back and the houses get smaller.”

figure 31. FlyView Controls

The arrow keys can also be used in FlyView, with Ctrl and Shift for rotations and zoom. Most of
the display hot keys also work, such as I, O, A, T, B, and the numbers 0-9. Pressing H from
FlyView brings up a list of available options.

*
If you are transitioning from RDS-DOS, note that the Shift key is held down to enable yaw rotations, not the Alt
key as before. Alt is reserved by Windows for other things whenever a Graphics Window is in use.

59
A joystick game controller can also be used to “fly” the airplane display around the screen, or to
“fly” individual components into position. A typical multi-function joystick is shown below. This
has a two-axis control stick motion plus twisting, normally used for rudder. The “trigger”, used
in DLM for rotations, is under the index finger, while the thumb can click on a variety of buttons.

In the Design Layout Module, the joystick will translate the airplane around the screen in the
expected directions (left-right-up-down). Joystick twisting is used to change the perspective
distance in and out. If you are not in a perspective view, you can make it perspective by quickly
twisting the joystick all the way then releasing it.

By holding down the trigger, joystick motions become rotations in pitch and roll, and twisting
provides yaw. RDSwin “thinks” like a pilot, so nose-up is provided by joystick “down”, ie., back.
Note that these can all be done with a single hand on the joystick, whereas with mouse or arrow
keys, you need to use the other hand to press Ctrl or Shift for some options.

The display is zoomed in and out by moving the extra control paddle (commonly used as the
throttle in flight simulators). As shown in the illustration, top buttons can be pressed for shaded
rendering and cross-section cuts. These are described below.

figure 32. Joystick Controls

FlyView is entered either from the View pulldown menu, or by clicking on the button at the
bottom of the DLM screen. Alt-M can be used to enter FlyView mode but ONLY if components
have not been selected for Assemble. To get out of FlyView, use Esc or Alt-M. Note that FlyView
“traps” the mouse cursor and may stop other Windows programs from working properly, so exit
it before switching to another program.

60
Relative Viewing
A powerful display feature is Relative viewing, offered in the View submenu. This requires that
an active component be selected, then the desired view is drawn “relative” to that component,
i.e., in its own local axis system.

For example, if the wing is selected for a Relative Side View display, the side view of the wing
will be drawn. Since “side” means an X-Z view, the wing will be shown with its local X-axis to
the right and its Z-axis up. In global terms this is an aircraft front view. Furthermore, the aircraft
will be rotated to the wing’s dihedral angle so that the left side of the wing is shown flat to the
screen (see below). This allows making measurements and doing various design tasks with the
rest of the aircraft visible and properly oriented – a powerful feature indeed.

figure 33. Relative Side View of Wing

Relative Views can be confusing. Components such as the fuselage or engine usually don't have
any axis system rotation so the relative view looks “normal.” However, if the component has a
non-zero location (X,Y,Z) then any Locate or Measure will give results in the local axis system.
These are different values than in the global axis system.

Using the provided DR3_win.rdsDSN as an example, the third cross section of the fuselage is at
X=4.92 in its own axis system, but the fuselage itself is at Xglobal=-3. So depending upon what
view is active, Locate will give X=1.92 or X=4.92. Both are correct!

To help avoid confusion, RDSwin places a faint letter “R” at the upper-right corner of the screen
when you are seeing a relative view. To get out of a relative view, select any other view (quick
method – press a number).

Warning - Component Shape commands begin by automatically showing a relative view. When
that command is finished, it stays in that relative view until you deliberately get out of it. The
easy way is to press “1” for a side view, but you can use the View pulldown menu if you wish.

61
Relative Views with Overlapping Airfoils or Sections
Relative viewing also allows use of an old drafting table trick – superimposing a true view of a
wing’s airfoils on top of the true view of the wing’s planform. The airfoils are rotated and “laid
flat” on the wing. This gives a visual representation of the current status of the wing design, and
is very useful in rigging the airfoils up or down to straighten out the hinge lines and spar caps.

This unique view is selected in the Relative Views submenu, as a special case of
RelativeTopViewUp. “RelTopUp:Wing+Airfoils” shows ONLY the active component (which
must be a wing or tail). To zoom or position the display, first use RelativeTopViewUp and adjust
as desired, then do RelTopUp. To create the best display, you may wish to delete or interpolate
some sections before making this view, as was done on the illustration below.

figure 34. Relative Top View (Up) of Wing with Overlapping Airfoils

The similar command RelSide:Body+Sections shows a side view of a body such as the fuselage,
with its cross-sections rotated and superimposed in true view.

figure 35. Relative Side View of Fuselage with Overlapping Cross-Sections

Render – Hidden Lines and Shading


For rapid visualization of your design, the RDS Design Layout Module has its own shaded
rendering capability. This quickly shows a 3-D surfaced image of the components currently
selected for viewing. RenderCurrentDesignView is selected in the View pulldown menu, or you
can press the Hot Key “R” (render).

62
RDSwin is not intended to be a realistic rendering tool. Its focus is upon design, and that is
normally done in a traditional wire-frame view. When designing an airplane you are shaping and
arranging component cross-sections, so those cross sections should be fully visible, ie., wire
frame. The rendering in RDS is mostly intended to help the designer visualize the emerging
design, and to determine if components are defined properly.

Fancy rendering is better done in other programs, some of which make images so realistic that
they are almost indistinguishable from photographs. The Professional version of RDS permits
exporting the design geometry to other programs including high-end rendering software.

figure 36. RDSwin Rendering

The render color used by RDSwin for components is based on the current background color as
selected in Options-SolidColorBackground, or as created when you select a new background
image. To make a nice contrast with the background, the component render hue is defined as 30
less than the background hue (using the Windows HSW color scheme). Saturation and Whiteness
are also adjusted to tone down the “clown” look. The render routine then changes the color of
the individual component panels to create a 3-D effect, making them lighter for panels that are
nearly-flat to the view direction, and darker for panels that are nearly edge-on. It isn’t perfect,
but it looks pretty good for a quick rendering.

You can set the rendering color directly (ignoring the current background) using one of two text
files in your RDS User directory. File RDSrenderRGB.rtx sets color by the Windows-standard
Red-Green-Blue scheme, whereas RDSrenderHSW.rtx uses the Hue-Saturation-Whiteness
scheme. Open either with a text editor such as WordPad, change the values as desired, change
the second line to ON, and re-save as a text file. Make sure that the extension is still [.rtx], not
[.txt] or [.rtx.txt]. If you have both of these files turned ON, the RGB scheme has priority. Once
turned ON, these files are ALWAYS used by RDS win until you turn them OFF again.

63
There is also a secret hack to set the render color. From the Options menu select “Enter
Background Color using HSW” and then, instead of the prompted numbers, enter a color name.
Options include Red, Yellow, Green, Cyan, Blue, Magenta, Gold, Copper, Aluminum, or Rust.

You can specify a different hue for individual components using ComponentViewOption. After
other options are presented, a menu of typical colors is offered. The hue can also be changed in
the AllComponentParameters display box. If you’ve selected a color for render, its hue is
included in the component ViewingCode (for example, 11011 hue 40).

Edit this to enter the desired hue, on the 0-360 HSW hue scale (0=red, 60=yellow, 120=green,
180=cyan, 240=blue, 300=magenta, and back to 360=red). Or, you can type in the desired color
(for example, 11011 green) which gets converted to hue when you are finished with the
AllComponentParameters display box. In addition to the colors just listed you can use gold,
copper, aluminum, and rust as color names.

If you select DesignViewOptions and then AlwaysRenderDesignView, all subsequent views will
be rendered until this is toggled off. This may be undesirable because it slows down viewing and
hides all but the front-most surfaces. AlwaysRenderDesignView is automatically turned off
during most component shaping options.

If you have not selected AlwaysRenderDesignView, any change to the view direction will erase
the render and go back to the wire-frame view (e.g., pressing an arrow key, the letter “I”, or a
number key). This can be used as a quick way to get rid of the rendered view.

If a joystick game controller is in use, rendering can be done by pressing a top button as shown
in figure 32. Relative views can also be rendered.

Extra graphics such as the trapezoidal wing geometry and the axis system are covered up in a
rendered view unless they stick out past the rendered components. It usually looks better to turn
them off for a render.

Perhaps the most challenging aspect of rendering is finding the exact intersections where one
component sticks into another. It requires a tremendous amount of computational time to get this
perfect. Since rendering is not its main purpose, RDS uses a quick method. It doesn’t try to find
the exact intersection line, and instead just shows the panels that are closest to the viewer. This
does a great job of showing a component that is completely in front of another, but if they join
each other, small jagged “junk” may be left at the intersection.

If you see an extreme amount of this Render “junk” it is probably caused by having very few
cross-sections on intersecting components. The Render routine automatically inserts more, but
isn’t smart enough to always make enough. The solution is easy – insert more sections by
interpolation, in those areas. A common example would be at the wing root, and can be fixed by
interpolating more sections (airfoils) at the wing root and also in the fuselage, where they meet.
Normally this is not a problem.

64
Components designed in RDSwin-Pro using SuperConic Surfaces have much better longitudinal
surface control so they usually look great when Rendered. They have more render panels so the
render intersection “junk” is almost non-existent.

When RDS renderings are used for presentations, render “junk” can be cleaned up in Powerpoint.
Simply add a curve to cover an ugly intersection. In the example below, a semi-transparent gray-
green curve with weight of 2.25 points was placed over the slightly-jagged intersection between
fuselage and canopy. It looks great, and took very little time.

figure 37. Rendering Clean Up via Powerpoint

Like many programmers, the author of RDS win amused himself by hiding various fun but not
particularly useful routines in the code. As a reward for reading this far, here is a test routine that
was left in. In any Design View, pressing the Underscore “_” (looks like a slicer) will render that
design….but slowly. You’ll see it start from the farthest away point, drawing every panel of the
display as it moves forward, including all internal components. On the sample V-Gull design
you’ll see Digital Dan appear and then get covered up by the outer skins. That is how the render
routine always works, but normally only the final results are shown. Pressing “_” again will pause
the slicing so you can make a screen save such as this one.

figure 38. Slow Render (Caught half way with Alt-PrtScn)

65
View Cross-Section Cuts
RDSwin lets you view the actual cross-sections of the component that you are designing, using
View-ComponentCrossSections, and also allows taking “slices” through all of the components
at various orientations. This is one of the key capabilities required for serious aircraft
configuration design - shaping the external skins to make sure that all the internal components
actually fit inside, while providing a smooth external shape that is good for aerodynamics. Being
that it is so important, RDSwin makes this easy and instantaneous.

The ShapeOneCrossSection routine, described below, lets you see a cut through the entire aircraft
as you are shaping one cross section. Other “slicing” routines are in the View pulldown menu.
SliceViews instantly shows 10 slices through the entire aircraft, showing all the components
currently being viewed. Three options are provided for slice orientation, namely Cross-Section
(global Y-Z), WaterLine (X-Y) and Buttock Plane (XZ). The oddly-named Buttock Plane cuts
are commonly used to visualize whether your fuselage is smooth. In ship design, Waterlines are
used for the same purpose but do a poor job of showing the wing-fuselage fairing, hence Buttock
Plane cuts are preferred.

figure 39. Stacked Cross-Section Cuts of Fuselage and Canopy (Y-Z Slices)

66
figure 40. Buttock Plane Cuts of Fuselage and Canopy (X-Z Slices)

figure 41. Cross-Section Cut Through Whole Airplane at One X-station (Y-Z Slice)

Note that these SliceViews are based upon the selected components and the current View options.
If your DesignViewOptions options are set to ReflectSymmetricalDesign, you won’t see very
many “slices” in a Waterline view because it is actually showing slices from the right wingtip all
the way to the left wingtip, so half the slices are duplicates. To see more slices in a Waterline
view, uncheck the ReflectSymmetricalDesign option.

The ViewSliceWithCutPlane option uses a non-real component to orient the desired cutting
plane. Cut planes are available in the cross-section, waterline, and buttock plane orientations,
plus an arbitrary orientation cut plane component is available. These are simply rectangles, so
you can make your own if you wish (make sure you pick the correct SAWE Type Code (Non-
Physical Component - Cut Plane). Normally, though, you will get a cut plane component from
the Component Bank. Select it as the active component for Edit/Assemble, move and orient it as
desired in FlyAssemble, and then select View-SliceWithCutPlane to see the slice.

If you don’t have a Cut Plane component in the file, you will be prompted to get one. If you have
more than one of them, you will be prompted to pick one of them. The resulting slice image is
sized to the cut plane component, so you may wish to Scale Component to make it larger or
smaller. Or, you can first select View-RelativeRear, zoom it as desired, and then select
ViewSliceWithCutPlane.

The figure below shows the V-Gull being sliced using the cut plane component shown on the
right in red (Relative Side View). The resulting slice is to the left. The blue lines were added to
show that the slice really is a true projection - done in less than a second!

67
figure 42. Angled Cross-Section Cut Using Relative View

If you slice through the tip of a rectangular wing it will normally be “open,” having no final cap
rib to close it out. You could copy the tip airfoil a thousandth of an inch past its location and
scale that section down to zero, but RDSwin has an easier method. Simply use
ComponentViewOptions to indicate that you wish to cap the ends of the component. This is
especially useful when using a color flood to measure areas – without a cap, the flood escapes to
the rest of the screen!

In RDSwin you normally design the major components individually to each attain a smooth shape,
and then stick them together. This can be seen above where the canopy bottom edge does not
exactly fit to the fuselage, but instead deliberately goes into it. During early conceptual design,
everything is changing on an hour-by-hour basis so it would be a waste of time trying to exactly
fit the canopy to the fuselage by cropping its bottom edge, and would actually result in a poorer
loft to the canopy.

Later on as you firm up your design you may wish to come back and do this cropping so that the
volume and wetted surface area calculations are more accurate. It is suggested that you do this
with a copy of the design geometry, not the original, so that any further changes can be done on
the smooth original shape. It might be better to convert the copies from SuperConic to Surface
Point geometry so that you can crop and move the points at will. However, this all takes time and
may not be worth the trouble.

Here is another hidden test routine that may amuse you. In any normal Design View, pressing
the BackSlash “\” (also looks like a slice) will allow you to see a cross-section cut in that view’s
orientation - even from an isometric or perspective! You are prompted to enter the cross-section’s
location as depth in the screen view - ie., distance “into” the computer screen. This is given as
percent of the total depth in that view, where 0% is closest and 100% is farthest away. From a
top view display, 5% will probably show the top of the tail and 95% will probably show the
bottoms of the tires. In a rear view display, 5% will show the back of the airplane. Entering 0%
or 100% is usually a bad idea - it may show nothing or perhaps just tiny dots.

68
The secret slicer (“\”) works a bit differently if you are already in a Relative View of a component.
In this case, it slices through the whole airplane at the origin of that component, and in its local
Y-Z (ie., cross-section) plane. Thus, if you get one of the Cut Plane components from
RDS_CompBank.rdsDsn (in RDSresource directory) and orient it as desired, you can instantly
see where it cuts through your design instead of using the Pulldown menu.

While the pulldown menu cut plane slice routine carefully checks that you are using a cut plane
component, the secret slicer doesn’t care. It takes whatever component is currently “active” and
uses its local axis system (Y-Z at X=0) to define the slice. This can be useful. Tires are normally
defined with the tire centerline as X=0, so by making the tire the active component, you can
instantly see if it fits without the bother of getting and orienting a cut plane. Just show a Relative
Rear View, then press “\”.

Underlay Image
RDSwin Professional has a unique and powerful capability for creating geometry of existing
aircraft and their components. A scanned photograph or line drawing can be placed on the screen
as an underlay. This is useful for creating an RDS representation of an engine or missile, and can
also be used to quickly model an entire aircraft in RDS for performance analysis and derivative
design. Companies do this for competitive analysis purposes, and certain government agencies
do it for their own reasons.

In the Design Layout Module, go to the Drafting pulldown menu and select Pick Underlay. Select
the desired image file (bmp). It will appear on the screen, underneath any current RDS win design
components. Next, go to a relative view of a component you wish to Shape to match the underlay
(or do this first).

To scale the underlay image to the current screen scale, find an obvious dimension on the drawing
such as wing span or fuselage length. For accuracy, use the longest dimension you can find.
Select Match Scale in the Vertical, Horizontal, or Diagonal direction then enter the correct
distance for that dimension, then click-drag that dimension with the mouse. The underlay will
scale larger or smaller to match that dimension. You can use Move to slide the underlay image
to the correct location versus the component you are shaping, and can also use Flip Left-Right if
the underlay points in the wrong direction.

Note that this only works in single views (relative side, top, or rear). If you pick an underlay
image when in a 3-view, it won’t appear until you change to a single view. Once you pick an
underlay image it will continue to appear until you select Remove Underlay.

New Component Creation


DLM has many routines for creating new components including fuselage, engine, wing, tail,
wheel, gear shock strut, seat, and more. Generic shapes such as sphere, box, and cylinder are also
available. All are called from the Component pulldown menu, and are fairly obvious as to inputs.
Try them – you’ll figure it out. To assist the occasional user, most of them pop up illustrations

69
depicting key inputs. Some of them will optionally calculate the needed geometry using statistical
inputs.

After selecting the desired type of component,


RDS prompts you to enter a name then to select
the component type from a menu. Component
type is stored as a numerical code based on the
aircraft industry SAWE RP8A (Mil-Std-1374a)
Group Weight Statement component categories,
with three additional digits added by this author
to further clarify component type. These
component type codes are used mostly to
identify whether each component should be
included in the aerodynamics or weights
analysis, and which analysis method should be
applied. You don’t have to learn or memorize these codes – just pick from the presented list when
you create a new component or change a component’s type using Edit-Comp Parameters.

For example, a component of type [031-000:Fuselage] will be included in the aerodynamics and
weights calculations and treated as a fuselage. A component of type [031-009:Payload Bay] is
identified as a part of the fuselage and can be so grouped in later detailed design efforts, but in
the RDS analysis is automatically ignored. This is correct in the aerodynamics calculations – the
payload bay is inside and has no effect. However, in the weights calculations the statistical
equations used by RDS do not have an input based on payload bay existence and geometry, so
the user (you!) must carefully consider how to modify the RDS results to account for it, probably
by applying a fudge factor or adding an estimated amount to the We-Misc category in the input
file.

For retractable landing gear, the down position copies of the components should use one of the
available "AltPos" codes (alternate position) so they are not used twice in the analysis. The “up”
position components should get the regular component type codes so that their locations are used
in center of gravity calculations.

A complete listing of these component type numbers can be seen in file RDSSAWE8.RTX.
Suggestions for additional types can be emailed to rds@aircraftdesign.com.

Continuing, RDS will prompt you for the desired symmetry option as described above, namely
left-right symmetric in the component axis system, then mirrored or not across the global aircraft
centerline or wing root.

Finally, RDS will prompt you for the specific inputs required for the type of component you are
building. For example, to make a sphere you will be prompted to enter radius. More complicated
components require more inputs – just enter the values requested. For Tire components you can
enter the desired size, or enter aircraft weight information and a statistical routine will size the
tires for you. For propeller diameter you can enter diameter, or give the number of blades and the
engine power and let RDS figure it out. The creation of wings and tails is described below.

70
If the component you need is vastly different from the available options, you can create it by
making an “empty” component. After that you should go to Shape Component and enter cross
sections, one at a time. You can create a single cross section for the new component, copy it to
other locations, then stretch, scale, and reshape those sections as desired. Or, you can make a
new component the "hard way", one cross section at a time, using Shape Component - Insert
Section. You will probably use the numeric (“N”) entry option a lot. However, this author usually
prefers to start with some sort of simple shape such as a cylinder and modify it to the desired
component shape rather than start with a truly empty component.

Some of those new component routines create rather simplified components, suitable mostly for
an initial design layout. For example, a piston engine is represented as a rounded box of the input
length, width, and height, with a propeller shaft sticking out the front. That is all you really need
when first putting a design together, but later the designer may wish to spend more time and
create a more-complete representation. RDS-DLM has a full set of design tools to create
complicated cross sections and components.

Wing/Tail Creation
Since wings and tails are so important to
aircraft design, the RDSwin DLM has a
number of capabilities specifically for
their construction and modification.
After the name and type are defined as
above, the design of a wing (or tail)
starts with the input of the trapezoidal
reference geometry, normally by
inputting wing area (S), aspect ratio (A),
and taper ratio. DLM can actually
determine the wing planform geometry
from any combination of three inputs of
S, A, taper ratio, span, root chord, or tip
chord. Select a parameter from the
offered list, and then enter its desired value. There are a few silly combinations which RDS
watches out for – you can’t define a wing with only taper ratio, root chord, and tip chord! This
capability is especially useful when you are trying to model an existing wing - you may know
the span and chord lengths, but not the trapezoidal wing parameters.

71
figure 43. Selected Airfoil and Resulting Initial Trapezoidal Wing

After the trapezoidal planform parameters are input, RDS lists available airfoils and prompts you
to pick one. The selected airfoil is drawn twice for your approval – once in actual proportions,
and then a second time with the vertical axis stretched. The points are slowly plotted. They should
start at the rear, go forward over the top, wrap around the front, then go down the bottom back
to the rear again. While you can do most design work with airfoils that are defined another way,
certain RDS routines may be fooled and produce strange results. In RDS win-Pro, the geometric
data exported to other programs may be unusable if the points aren’t defined in this standard way.

The file RDSAF.rdsDAF contains the RDS default airfoils and describes their format. Airfoils
can be added to the end of that file, but be careful to exactly match this format. Use a simple text
editor such as NotePad rather than MS-Word, which may add special symbols that can’t be read,
even when storing in “txt” format.

Some of the airfoils provided as a courtesy on the RDS program disk were obtained from the
University of Illinois airfoil website and may be covered under the GNU license, which affects
redistribution (you are free to use them for designs). For details see GNU_License_UIUC.pdf on
the RDS program disk (may be abbreviated GNU-Lice.pdf which is funny when you say it).

When selecting the airfoil for a wing or tail, RDSwin-Professional allows importation of airfoils
from outside data files in a variety of formats. Thousands of airfoils can be found at the University
of Illinois airfoil website. Most are in the “Selig” format named after noted UI professor Dr.
Michael S. Selig. The website can currently be found at:

www.ae.illinois.edu/m-selig/ads/coord_database.html

72
RDSwin-Pro can read most of the airfoil formats in common use. When importing from other files
you will be prompted for the format, as follows:

1. Selig* TE top to LE to TE bottom {X Y}


2. VSAERO TE bottom to LE to TE top {X Y}
3. Lednicer Top LE to TE then bottom LE to TE {X Y}
4. Abbot & vonD LE to TE {UpperX UpperY LowerX LowerY}
5. RDSAF.rdsDAF (like #4 with 2nd line providing number of point pairs; lines 3 & 4
are null)

If the selected airfoil has more than 100 points, RDSwin-Pro will automatically reduce the number
of points, with bias towards leaving denser points at the leading edge. It does not interpolate or
change them in any way, it merely deletes some of them towards the rear.

There is also a Manual airfoil entry option in RDSwin-Pro. This prompts you to enter (Y,Z) values,
starting at the trailing edge. Points must go forward following the upper surface, wrap around the
leading edge, and return to the trailing edge along the bottom surface.

RDSwin-Pro also has the ability to create custom airfoils† of the NACA 4-digit and 5-digit families
(including Modified), the 1- and 6- series (16, 63, 64, 65, 66 & 67), as well as biconvex airfoil
sections. Refer to the book Theory Of Wing Sections (Abbott & Von Doenhoff) and to NACA
Report 824 if you are unfamiliar with the parameters which define those classic NACA airfoils.
Note that RDS always saves the airfoil coordinates created by this routine into your current
project directory in an airfoil-named file with extension .NAC, such as N58112.NAC. These
airfoils can be used later, or you may wish to occasionally delete them.

After you have entered or imported an airfoil, you can save it in your own airfoil data file. This
file must have a filename extension of (.rdsDAF), which tells RDS that it is a multi-airfoil archive
much like the default file RDSAF.rdsDAF. Files with a single airfoil can have any filename.

Another option for airfoil selection in RDSwin-Pro is to use the points from the last cross-section
seen on the screen. This is a tool to allow experts to “grab” airfoils, but be careful - it isn’t very
smart. The option appears at the bottom of the SelectAirfoil menu, but only if you have already
viewed a cross-section in either View-Component Cross-Sections or ShapeComponent-Shape
One Cross-Section. The routine doesn’t know if that remembered cross-section is, in fact, an
airfoil, so make sure that the last thing you did was to view the airfoil you wish to use.

Also, this tool does not fix the airfoil back to its original condition, so if you have shaped it,
twisted it, or translated it vertically, it will be used that way. This can produce unexpected results.
It is best to make a dummy copy of the component with the airfoil you wish to “grab” and then
carefully view and fix one of its cross-sections, removing any twist and moving it vertically so
that the leading and trailing edges are both at Z=0. Don’t worry about the Y positioning or airfoil
scaling - the Wing routine will fix those as it places the airfoil section to form the wing or tail
you are creating.

*
FYI, RDS uses Selig format internally. Airfoils in other formats are automatically converted before use.

Code modified from an airfoil generation program originally written by David Lednicer, used with permission.

73
It is fairly common to use a different airfoil at the root and tip of a wing. This can be easily done
in RDSwin-Pro. After you’ve selected an airfoil, you are given the option to use that one as the
root airfoil and then to select or define another as the tip airfoil. These MUST have the same
number of points. You’ll be sternly correct if they don’t. If you select them from a family of
airfoils that should be no problem. Note that in modern aircraft design practice, the aerodynamics
department will eventually redesign all of the airfoils using high-end CFD, so this may not be
necessary.

After selecting an airfoil or airfoils you are prompted to input the desired airfoil thickness ratio,
ie., t/c. The default is the t/c of the airfoil you’ve selected and should almost always be selected.
The airfoil t/c adjustment is done by simple vertical scaling of the selected airfoil so be advised
that the mean camber line is scaled as well.

You can taper the thickness ratio so that the tip chord has a different airfoil t/c than the root
airfoil. Normally you would input the desired “nominal” or average t/c, which is applied to the
mean aerodynamic chord, and are then prompted for a ratio between that nominal value and the
tip value. For a thicker tip, you may, for example, input 1.2. Alternatively, you can input the root
t/c and the tip t/c, and RDS will determine the nominal t/c.

RDSwin-Pro next offers the option to twist the wing from root to tip. These airfoil twist rotations
are done by sliding the airfoil points up or down in Z, without changing their Y location. This
method preserves chord length. This is fine for normal amounts of wing twist and incidence (~5
degrees or less), but would produce strange results if applied to a propeller or rotor blade where
twist at the root can approach 90 degrees. For such design work, you should instead use the
rotation command in Component Shape. This is a true rotation of Y and Z about the component
origin.

Once you have created the trapezoidal wing you can use any Component Shape command to
reshape it to the desired geometry. Stretch is especially useful in shaping the planform and
wingtips – see below. You can also change the wing trapezoidal planform parameters such as
area, aspect ratio, and sweep, and RDSwin–Pro will instantly and automatically revise the entire
wing geometry to match, even non-trapezoidal shaping such as wingtip rounding and wing root
strakes and kicks. This can also be applied to any components derived from the wing (or tail),
such as a wing box or ailerons.

RDSwin–Pro also lets you replace the airfoils on a wing or tail, even after non-trapezoidal shaping
has been applied. After you select the new airfoil, this powerful routine prompts to replace all
the spanwise location airfoils at once, or replace them individually. Twist and airfoil thickness
are preserved and applied to the new airfoils. You can also select a different airfoil at root and
tip, and the intermediate airfoils will be interpolated.

Note that DLM will be unhappy if you fail to specify one and only one reference wing
component. If you have two or more wings, only one can be the “reference.” If you do not have
any wings, such as a lifting body or airship, you should define a “fake” reference wing
component. Give it Sref=1 which will cause drag results to be expressed as drag area (D/q). When
you are working on the Aerodynamics input file, give this fake component an exposed area

74
(Aexp) of .001 so that the fake wing doesn’t produce real drag. You should not leave a zero
exposed area (Aexp=0) because RDS will assume that you simply forgot to provide this term,
and will use the Sref value for Aexp.

RDSwin also includes a parametric Winglet creation routine which prompts for key parameters
then creates and places a winglet at the wingtip of your reference wing. The default geometry is
the original Whitcomb arrangement but the user can put in other values. RDS win does not create
the exact Whitcomb airfoil or twist geometry, just the winglet planform and location.

RDSwin only creates the top portion of the classic Whitcomb geometry. The bottom piece seen in
Whitcomb’s original patent can be created as a second winglet, as follows: When prompted for
area, type *0.1788 after the default presented (example – if the default is 10.43, modify it to read
10.43*0.1788 without a space). Then enter an aspect ratio of 1.07, a taper ratio of 0.4, a sweep
of 52 degrees, and a dihedral -144 degrees (off vertical). You’ll have to use FlyAssemble to move
that portion forward until its leading edge is right at the leading edge of the wingtip.

Scale Component
Once components have been created, various RDS-DLM design tools are available to rapidly
change their geometry as the design evolves towards its final form. Component scaling options
are selected from the ScaleComp pulldown menu, and are also available through the Shape button
at the bottom of the DLM screen. Component Scaling can be done in any axis or in combinations,
including an option where length is stretched but cross section is reduced to maintain total volume
(good for tanks).

If you select a Scale option when you have not yet selected an active component, RDS will take
you to the appropriate menu to choose one (or more). If multiple components were selected, you
will be asked if you want the others to be scaled by the same factors as the leader you selected.
If you reply “yes”, this will be done and in addition, the (X,Y,Z) location of the other components
will be scaled so that the collection of components keeps its relative geometry. For example, if
you have selected the fuselage as Leader and also select the tails, Scaling by 1.5 will
automatically move the tails rearward so that they maintain the same alignment with the fuselage.

The Scale and Shape pulldown menus both offer a useful but slightly confusing command,
MoveComponentPtsInLocalAxisSystem. This is used to reposition the entire component within
its own axis system. For example, some companies prefer that the absolute nose of the final
design layout be located at exactly X=0 (why?). If you’ve decided to stretch the nose forward a
bit, it is now at a negative X location. This command lets you move every point by your input
X,Y,Z values. Unlike the Scale commands which this resembles, use an input of 0 to cause no
change on a particular axis.

Shape Component
The powerful ShapeComp routines offer many ways to reshape a component’s cross sections.
They can be scaled, stretched, moved, and changed by direct point manipulation, and this can be
done in side view, top view, and of course in cross section (rear) view. Section points can also

75
be moved by selection of longitudinal control lines then direct manipulation in side or top view.
ShapeComp is selected from the pulldown menu, or from the Shape button at the bottom of the
DLM screen, included there since Shape is probably the most commonly used capability for
design.

Component Shape options are always done to the Active component (Leader if more than one
component is active), and in that component’s Relative view. If you are not already in a Relative
view, i.e., with respect to that component’s local axis system, RDS will show a relative view
when a SHAPE option is selected. Or, you can make a relative view first, and zoom or translate
the display as desired, then enter the SHAPE option desired.

While in the Shape routines, you can hide or restore other components in the display by pressing
the ampersand (&). Remember this hot key as “show Leader AND (&) other components”.

Shape allows you to, from a side or top view, either Stretch, Scale, Crop, Move, Rotate, Copy,
Interpolate, or Delete the selected Cross-Sections. Generally you indicate one or more cross
sections first, either by location from a pick menu or using the mouse. Then you enter a value or
indicate a location to perform the operation.

Stretch CrossSections is a powerful tool. It allows you to stretch cross sections from a side or top
view using mouse inputs. This lets you quickly shape a fuselage or other body to create the overall
shape, after which you can modify the cross sections as needed. When stretching, you can do so
proportionally so that the section scales in Z and Y by the same amount, or stretch only in the
view you are seeing.

An option in RDSwin-Pro, “Stretch Front or Back” (or “Stretch Top or Bottom” depending upon
the view you are in), stretches only up to the maximum height or width of the section. This is
described below as it applies to airfoil stretching.

Stretch CrossSections is normally done with “click-drag.” The user presses and holds the left
mouse button which grabs the nearest point to be used as a “handle”. Previous RDS versions use
a double input method, which is still available by de-selecting Click-Drag in the Options
pulldown menu. For this, first you click and release the mouse button to indicate the point that
you wish to stretch or move, and then you click and release to indicate the desired new location.

76
figure 44. Stretch Sections using Click-Drag

ShapeComp has another useful capability – “dittoing” the last move or stretch input. After you
have made one such a change, the next time you click to move or stretch a section you can enter
a quotation mark (often used to mean ditto) while still holding down the mouse button. This
causes the previous value to be reused.

This is especially useful if you wish to do something like move the nose of a fuselage to the left
to extend the fuselage, while preserving the shape of the nose. Move the first section to the left
the desired amount, then ditto-move the remaining sections of the nose. When using ditto for
section stretch, all sections are stretched to the same point input for the first section. This allows
you to, for example, stretch all wing airfoils to the same location to make a straight trailing edge
on the inboard part of a wing.

Since it is difficult to hold down the Shift key and press [“] while holding down the mouse button
at the same time, you can press that same key without using Shift. In other words, just here
RDSwin will assume that [`] or [‘] are meant to be [“].

If you have turned off Click-Drag shaping, you can enter a ditto [“] instead of clicking a second
time on a move-to location.

Previous dittoes are always zeroed when you change views.

For SuperConic Surface Components, the Stretch command allows applying the automatic
smoothing routine (Akima) described above, to a single selected cross section. After selecting a
slope control cross section to stretch (section number 2, 4, 6, …), press the hot key for curve
smoothing (~). Just that cross section will be modified to the shape it would have if you ran the
automatic SuperConic smoothing routine for the whole component. All other cross sections are
left unchanged. To make the slopes match where SuperConics join each other (sections 5, 9,
13,…) do the same to the slope controls on both sides.

Another useful Stretch tool for SuperConic Surface Components simply takes the slope control
section you have selected, and aligns it with the slope control section on the other side of the

77
adjacent longitudinal patch bay cross section. This is done by pressing the equals sign (=) after
selecting a section for stretching. For example, if you select cross section number 4 then press
“=”, cross section 4 will be changed so that it is aligned with cross section 6, and there will be a
smooth surface in the longitudinal direction going past section 5.

The Stretch Cross-Sections command is especially useful for wing shaping. You can view the
wing in a true top view and use mouse inputs to stretch the sections in chord length to get the
desired wing shape. Using the Stretch Proportional option will preserve the airfoil shape and its
thickness ratio (t/c), scaling the entire cross section proportionally based on the user’s input point.

In RDSwin-Pro, the “Stretch Front or Back” (or “Stretch Top or Bottom”) option is uniquely
powerful. It stretches the cross section to the user’s input point, but only stretches the section up
to its point of maximum width or height. When used for wings it allows you to stretch the wing
in top view but only from the point of maximum thickness. This avoids an unwanted change in
the sweep of the line of maximum thickness which is created when the wing is shaped by regular
section stretching. This is illustrated below. The top image shows the original airfoil (shaded)
and the same airfoil, stretched forward to an input point. This proportionally stretches the entire
airfoil so the point of maximum thickness is moved forward as shown by the arrow, and the back
half of the airfoil is stretched out along with the front of the airfoil.

figure 45. Stretched Proportional vs. Stretch-Front

The bottom illustration shows stretching to the same input point but with “Stretch Front or Back”
selected (since a front point was selected, this is “stretch front”). All stretching is done in the
front, forward of the point of maximum thickness (black dot), and that point is unchanged in
location. The airfoil is unchanged from the point of maximum thickness back to the trailing edge.
This does change the airfoil shape so please consult with an aerodynamicist!

After shaping the wing in planform, the original trapezoidal planform can be shown if desired
(DesignViewOptions-ShowTrapWing). The display includes the mean aerodynamic chord and
lines showing the 25% and 40% MAC locations to facilitate positioning the wing on the aircraft.
It is not necessary to save an unmodified trapezoidal wing – DLM remembers.

One unique tool allows trapezoidal planform revision of wings or tails, and of any components
derived from them. This is done by inputting the desired new area, aspect ratio, taper ratio, sweep,
t/c, and/or dihedral. Even if you have extensively reshaped the wing such as modifying the
planform, cropping the root, rounding the tip, or modifying the airfoil in some way, those changes
will be preserved as the wing geometry is morphed to correspond to the new trapezoidal wing
planform.

78
RDSwin-Pro has another way to scale the planform of a wing or tail that is especially useful for
modeling existing aircraft, or when trying to align certain geometric features of a special design.
This option (Reshape to ref. planform defined by LE-TE-Tip) lets you define the leading and
trailing edges by inputting two points each, one near the desired root and one near the tip. These
don’t have to be at the exact root and tip locations. A fifth point defines the desired span. From
these inputs, the trapezoidal wing or tail is calculated and all existing geometry is scaled to match.
Also, the component X-location is changed as needed so that the new trapezoidal geometry aligns
with the input points.

In RDSwin–Pro there is also a special routine for revising the trapezoidal reference planform of a
wing or tail without changing the actual geometry, as described in the next section.

When Component Shaping is done to a wing or tail, the airfoil thickness ratio (t/c) may be
changed. After shaping, RDS checks the averaged t/c of the wing. If it no longer matches the
stored “official” t/c, RDS asks if you wish to change the stored value to match the reality. Note
that when you scale a wing or tail by inputting a new t/c, it is scaled by the ratio of your input
new value to the stored “official” value. Again, if the reality is far from the stored value RDS
will prompt you to fix it before scaling.

Warning - When putting control surfaces on wings and tails, do not crop away that portion of the
wing. Just create the surface as a separate component. RDS ignores control surfaces when
calculating areas of the wings and tails.

Fixing the Reference Trapezoid Wing or Tail (-Pro only)


Sometimes you modify the actual geometry of a wing or tail so much that you aren’t certain if
the original trapezoidal planform is still a reasonable representation for aerodynamic reference.
If you compare CLmax for your new design with the CLmax for existing similar designs, the results
aren't meaningful because they are referenced to the trapezoidal geometry, and yours is far from
the actual geometry.

RDSwin–Pro has two ways to revise the reference trapezoid wing to make it a better representation
of your actual wing planform, namely automatic and visual. Either can be done in seconds and
can be found under Component-WingTailPlanformRevision.

The automatic method, RedefineReferencePlanformAnalytically, calculates a reference wing


geometry that should be a better representation of the aerodynamics of the actual planform. Wing
area is found by adding up the area of the actual panels, and then extrapolating to the wing
centerline. Wing taper ratio is found by a least-squares curve fit of the chord lengths. Sweep is
found as an area-weighted average using a cosine transformation, based on absolute value so that
panels swept forward do not cancel out panels swept to the rear.

These calculated values for the reference wing parameters are presented to the user before they
are used, allowing them to be changed. In fact, you can run this routine and ignore its results,
replacing all of the parameters with your own preferred values.

79
The visual method, RedefineReferencePlanformByLE-TE-Tip, shows a top view of the wing and
prompts you to click-drag a leading edge line, then a trailing edge line, then the wingtip location
to define the new reference trapezoid for your wing or tail. You are prompted if you’d prefer to
define the span using exactly the outermost airfoil location rather than the location you entered
with the mouse. The reasonableness of the resulting planform is up to you.

figure 46. Reference Wing/Tail Revision

Neither of these reference planform revision methods changes the actual wing geometry that you
have defined. If you don’t have ShowTrapezoidalWing turned on, you won’t see anything
different! Also, these methods automatically change the X-location of the component to take
into account the new location of the quarter chord of the MAC, and then slide the airfoils in the
local Y-direction accordingly. This is not visible unless you have ShowLocalAxis turned on.

Shape One Cross-Section


Shaping of a single cross section is one of the most important tasks in design. In DLM this is
done from the Shape pulldown menu or selected after clicking the Shape button. A pick menu
appears with all cross sections listed for selection, or you can pick a section using the mouse. The
selected cross section is then drawn. If the component is defined using SuperConics, the control
points will be shown as well, with straight lines indicating the end tangent angles. Note that each
SuperConic is defined by five such control points (see above) and that connected SuperConics
share an endpoint.

A pick menu appears to the right, offering various shaping and viewing commands. You can
select Move&ZoomView to get the view you want before you start changing the cross section.

80
Often you will want to see other components as you work. ShowSliceThroughAllComps does
just that, using the same “slicing” routine as in the View menu. The slice is automatically done
using that cross-section’s location and orientation for the cut plane. Once Slice is selected, the
menu changes to ShowOnlyThisSection which gets rid of the slice. As you reshape the cross-
section, the slice will still show the old geometry for comparison (see figure below).

figure 47. Cross-Section Shaping With Slice Through All Components

You can also select ShowOtherComponents. This superimposes a relative rear view of all the
visible components of the aircraft, including the rest of the component being shaped. This is
useful for shaping skins to envelope several smaller components but can be very cluttered. If so,
exit from Shape and use SelectComponentsForView to reduce the number of components being
seen.

You can then select any of the cross-section reshaping options in the menu including Move Point,
Insert Point, Add Point (to end), and Delete Point. The RDS win Design Layout Module now uses
“click-drag” for shaping lines in cross section. The user presses and holds the left mouse button
which grabs the nearest point to be used as a “handle”. As the point is moved, the line or surface
is instantly reshaped and shown – see below. By holding down the Ctrl key, the point is moved
only horizontally or vertically.

81
figure 48. Move Points in Cross-Section using Click-Drag

Previous RDS versions use a double input method, which is still available by de-selecting Click-
Drag in the Options pulldown menu. With double input, first you click and release the mouse
button to indicate the point that you wish to move, and then you click and release to indicate the
desired new location.

This method does has its advantages. It allows the user to select the point by its number, or by
numerically entering its location instead of visually with the mouse. You first pick a point using
the mouse, or you can press P to enter the desired Point number, or press N to Numerically enter
a location (the closest point will be selected). Next, you enter a second point to Move. Entering
N for numerical entry is also permitted here.

Selection by point number is especially useful when several points are close together or even
degenerate. The double input method also allows the user to enter the desired final location
numerically or via a “ditto” in which the last location is reused.

Locate Point finds the closest point to your mouse or N entry. P is also permitted. Move, Scale,
Stretch, Crop, and Rotate Section all require two mouse inputs to perform the indicated action.

A powerful and potentially dangerous tool is Point Renumber. Sometimes when working on a
cross-section you wind up with too many points, or points in the wrong order. Renumber lets you
click on the points you want to keep, in the desired order. All points not selected are thrown
away, so be careful! You actually can select the same point twice, but this is probably not useful.

You can reshape cross sections of a SuperConic component by simply moving points, and by
using Move, Scale, Stretch, and Rotate Section. Crop is not available unless you first convert the
component to points. SuperConic-specific shaping options are also available including Add
SuperConic, Reset SuperConic Tangent, and Reset SuperConic Rho.

82
Original Same Tangent Angle New Tangent Angle

figure 49. SuperConic Fast Cross-Section Shaping

When Shaping a SuperConic cross-section, revise the geometry by moving the SuperConic
control points as described above. The resulting lines are then redrawn. If you move the tangent
control points you are asked if you really wanted to change the tangent angles, or if you just
wanted to move the point farther in or out along the existing tangent angle. Since these control
points act as “magnets,” moving the tangent control points farther out will preserve the tangent
angle and reduce the curvature at that endpoint. This makes the curve follow that tangent line
more closely (see illustrations above). Alternatively, you can numerically enter the desired
tangent angle. When you move a SuperConic endpoint, the adjacent tangent points are
automatically moved as well, preserving the tangent angle.

Another option to shape a SuperConic section lets you reset a curve’s “Rho” value. If you are
unfamiliar with this conic lofting parameter, see Raymer’s book or study the illustration which
pops up. Normally when you select this option and enter the desired new Rho value, the selected
shoulder point and its adjacent tangent control points will be moved to provide a conic with the
Rho value you input.

If you give a negative value for Rho (say, -.4142), the shoulder point will be moved correctly but
the tangent control points will be left alone. This is sometimes useful, but note that the resulting
curve is probably not a true conic.

Be careful when adding or deleting points, or when renumbering points in a SuperConic cross-
section. You must maintain the proper number of points (5 for the first SuperConic, and 4 more
for each additional SuperConic). If you add or delete points you will see strange lines until the
proper number of points is re-attained. If renumbering points in a SuperConic cross-section,
remember that every other point is a tangent control point that is not actually on the curve.

Note that the cross-section geometry you are changing is a temporary copy which is uploaded to
the current working version of the aircraft design only when you exit Cross-Section shape. You
can select UndoSectionEdits during cross-section shaping, and can always use Undo afterwards
to get rid of a bad redesign on a section.

83
Those who have used other CAD systems have probably seen curves where one or more middle
points “float” around and are used to shape the curve. These are typical of a “Bezier” curve which
like a SuperConic, is a subset of the generic “NURBS” mathematics. For comparison and
educational purposes, RDSwin can show the equivalent Bezier middle point in cross-section edit
(Move&ZoomView – ShowBezierMidpoint). Imagine trying to shape by moving that weird
floating point around! The shoulder point of a SuperConic is much better.

Shape Cross-Sections by Longitudinal Lines


DLM has another powerful tool for reshaping cross-sections, but this tool doesn’t work in a cross-
section view. “Shape By Longitudinal Lines” works in component side or top view and permits
smoothing the entire component from nose to tail.

A pick menu lets you select one single longitudinal control line, which is a line connecting the
same cross-section point in each section from nose to tail. Obviously, this requires the same
number of points in each cross section. Once you have chosen the line from the pick list or by
mouse, the component is redrawn with that line highlighted. Click-Drag points from nose to tail
until you get a smooth line. Repeat for other lines, repeat for the other view, and check cross
sections to ensure a smooth shaping.

This back-and-forth from longitudinal lines to cross-section shaping is the very essence of
classical aircraft configuration layout. RDS-DLM makes it easy.

figure 50. Shaping by Longitudinal Line

For SuperConic Surface Components, the Longitudinal Line Shape command allows applying
the automatic smoothing routine (Akima) as described above. This routine is available in the
menu for ShapeByLongitudinalLines, and when you’ve already selected a single line, pressing
“~” will smooth just that line. The points on the surface (1, 3, 5,…) will be unchanged, while the
slope control points (2, 4, 6,…) will be moved in both Y and Z, regardless of which view you are
currently seeing.

84
Component Instances (-Pro only)
RDSwin-Pro allows the creation and placement of component Instances. These are like copies,
but rather than creating and storing a complete copy of the component’s geometry (points or
SuperConics), an Instance uses the geometry of its “parent” component. An Instance can be
repositioned like a normal component, and it has its own component name, symmetry, viewcode,
and SAWE8 type. It just doesn’t have its own geometry, so it can’t be Shaped or Scaled. Instances
are created using the Component-MakeCompInstance command, which prompts you for the
Instance location as delta increments from the parent’s location.

Instances save on data storage, and are useful because when you reshape the Parent, all of its
Instances are changed as well. A typical use of Instances is the passenger seats, which are all the
same except for location. Instances can also be used for tires of a multi-bogey design, or for
external stores, engines, and nacelles.

The "Enter Instance Delta X/Y/Z" prompt also allows optionally entering how many instances
you would like (default is one). All the new Instances are offset by the Delta X/Y/Z values you
enter so, for example, entering 2 0 0 3 would create 3 instances, with the first one 2 ft or meters
behind the parent, the next one 2 behind the first, etc... The 0’s are the Y and Z offsets.

This is very useful for defining a passenger compartment. Make or get a single seat, change its
symmetry to reflect it across the centerline, then position it where you want the first row. Make
instances for the rest of the first row using, for example, 0 34/12 0 2 to create a total of six seats
across (3 on each side of the airplane), each offset laterally by 34 inches (center-to-center, not
gap between). Next, pick the parent and create, say, a total of 40 rows with 3 ft pitch by entering
3 0 0 39. Repeat this for each front-row instance.

Since an Instance uses the geometry of the previous component in the file, they are always
immediately after the Parent in the component list. Don’t try to change this. If an Instance
becomes corrupt, it is probably because it has somehow “lost” its parent. Delete the instance and
make another. Be extra careful with Instances when re-ordering the components!

If you ever find that you must reshape an Instance to be different from the parent, make a copy
of the parent and change the copy’s parameters to match the instance’s parameters (type them
in), then delete the Instance.

Assemble Components
The locations and rotations of components can be changed by entering new values in
ComponentParameters. This is suitable for initial positioning, but more interactive methods are
found in the Assemble pulldown menu options. One rather-clumsy method is to select Move or
Rotate then the appropriate option, such as +Y or –Roll. Note that position values (X, Y, and Z)
are all in the Global axis system, not screen coordinates. You can Move or Rotate the active
components in any display view but be careful – if you are looking at a rear view and select +X,
you won’t see anything happen in that view.

85
The “Speed” of Move and Rotate can be changed using Nudge, Move, or Jump. The desired
Move or Rotate can also be entered numerically as changes (delta) from current values.

If you select a pulldown menu Assemble option but have not yet selected an active component,
RDS will take you to the appropriate menu to choose one (or more). If multiple components were
selected, all will be moved or rotated. When rotating multiple components around a Leader, the
XYZ locations of the other components are adjusted so that they stay in the same relative
position.

It is better to get out of Relative View before using any Assemble option. Since the view is
recreated after each move, a large component being moved may appear stationary as the rest of
the airplane appears to move in the opposite direction!

DragAssemble
DragAssemble allows you to assemble components into a design using mouse click-drag in the
screen view. It is entered from the Assemble pulldown menu or by selecting the button at the
bottom of the DLM screen. If you haven’t selected the components to be assembled, you’ll be
promoted for them.

If you aren’t already in one of the various single views (side, top, rear) you’ll be prompted for
that. Once in Drag Assemble, simply click-drag to move the selected components. You can also
Click on a location then, while holding the button down, press N for numeric entry. The point
you first selected will be moved directly to the input location.

While in Drag Assemble you can also change the view by pressing a number hotkey (1-5) and
you can zoom (Z). Other commands are disabled until you exit by pressing ESC. When you exit
you are asked if you wish to save the moves you have made.

Drag Assemble is different from FlyAssemble as described below. Drag Assemble works in the
current screen view, whereas FlyAssemble works in the aircraft global axis system regardless of
the screen view. FlyAssemble is very powerful, but sometimes confusing!

FlyAssemble
FlyAssemble allows you to assemble components using commands and controls similar to those
used in FlyView. In FlyAssemble, the arrow or mouse inputs, along with Ctrl or Shift, “fly” the
selected components into position. This is fast and intuitive, but takes some getting used to.

Unlike DragAssemble and most other CAD programs, the RDS win FlyAssemble is view-
independent. The components are moved in the global axis system regardless of the view in use.
For example, pressing the right arrow or moving the mouse to the right ALWAYS makes the
component X location value a little larger. You can select FlyAssemble when in any view
including single views, three-views, isometric, and even perspective!

86
When you enter FlyAssemble, the cursor changes to a 4-arrow cross indicating motions of your
“control stick” and is trapped on the upper-right edge of the screen just as for FlyView.

Motion of the mouse directly “flies” the selected component, with almost the same commands
as in FlyView. Moving the mouse by itself changes the component’s X and Z location, in the
directions you’d expect in a side view (although you don’t have to actually be in a side view).
With the Ctrl key held down, the mouse “flies” the component in pitch and roll.

With the Shift key held down, left-right mouse movement yaws the component, and up-down
motion moves the component in Y. This last one is confusing – down mouse motion increases
the Y value. To visualize this, place the airplane in top view. Then with the Shift key held down,
the mouse moves the component in the Y direction you’d expect. But again, the component
moves in the global axis system regardless of the current view.

Press S for Slow, D for Default, or F for Fast to change the mouse sensitivity during FlyAssemble.
The arrow keys can also be used in FlyAssemble, with Ctrl and Shift for rotations and Y motion.
Most of the display hot keys also work, such as I, O, A, T, B, and the numbers 0-9. Pressing H
brings up a list of available options.

A joystick game controller can also be used in FlyAssemble, allowing you to “fly” the selected
components into place. Two-axis control stick motion, like mouse motion, changes the
component’s X and Z. Twisting the joystick changes Y. These motions are in the global axis
system and are view-independent. Don’t be surprised if you move the stick to the right in a rear
view, and nothing seems to happen. The selected component is moving towards you.

Holding down the “trigger” causes the stick to control rotations. It then works just like an
aircraft’s control stick, changing the component’s pitch and roll. Twisting the control stick while
holding down the trigger changes component yaw.

The throttle control paddle can still be used to zoom while in FlyAssemble. The buttons on top
still work for render and cross-section cut. Pressing any joystick button other than the ones
labeled in figure 32 above will exit FlyAssemble.

FlyAssemble is entered either from the Assemble pulldown menu, or by clicking on the button
at the bottom of the DLM screen. Alt-M can be used to enter FlyAssemble any time that there
are active components, otherwise it will take you to FlyView. To get out of FlyAssemble, use
Esc or Alt-M. DLM asks if you want to keep the changes – a handy feature.

Note that FlyAssemble, like FlyView, “traps” the mouse cursor and may stop other Windows
programs from working properly. Exit it before switching to another program.

87
Move Selected Components in global X or Z: Mouse or Arrows
Move Components in global Y: Shift-Mouse, Shift-Arrow or Ins/Del
Pitch or Roll Comps (local axis system): Ctrl-Mouse or Ctrl-Arrows
Yaw Components: Shift-Mouse, Shift-Arrow or PageUp/PgDown
Mouse & key action speed: Slow/Default/Fast = S / D / F
Toggle FlyAssembleMouse operation: Alt-M
Escape FlyAssemble Operation: Esc

Undo and Redo


RDS-DLM has a powerful and unique Undo capability. Instead of undoing a single keystroke,
DLM allows you to undo major design changes. Every time a significant geometry change is
made, the entire design is automatically saved to a temporary file. When in DLM, Undo recovers
the most recent version, and can be repeated up to nine times if you have made so many changes
to the design. Redo is also available.

During design work in RDS-DLM, you are actually working on the latest temporary file, not on
your stored file. When you Save the design (File-Save) you are merely renaming that most-recent
temporary file.

Here’s a secret hack as a reward for getting this far: Ctrl-K will instantly save a numbered copy
of your current design file. Every time you press it, you get another complete file saved. It’s
useful for recreating your design sequence, or for training others.

Design Files & Geometric Analysis (TAB File)


A complete RDS-DLM file includes the design’s components plus optional "header" items such
as Designer's name and Notes. The Files pulldown menu allows storing, retrieving, and starting
new design files. In the Component menu you can copy components from other files including a
provided Component Bank where commonly used items are stored for easy access.

To document the design and provide geometric output for the analysis modules, the Design
Analysis command creates a tab-delimited file (.TAB) of key design geometric information. This
contains wing and tail data blocks, component information such as location and volume, and
cross section perimeters and areas. You must select DoAnalysis in DLM to create a TAB file if
you want to read your design’s geometric information into the Aerodynamics, Weights, and
Propulsion modules. When the TAB file creation is finished, DLM will offer to open it in your
spreadsheet for review.

The RDS Aerodynamics, Weights, and Propulsion Modules read geometric data from the TAB
file into the proper input grid data locations. To work properly, the components need to be
identified as to type (wing, fuselage, wheel…) using the SAWE group weight statement code
described above. You are prompted to select an appropriate code each time you make a new
component, and can revise codes in the Component pulldown. Make sure there is one and only
one Reference Wing. For more information on the TAB file see Appendix B.

88
figure 51. Volume Distribution plot (with “broomsticks”)

Another important design analysis is the Volume Distribution plot. This is critical for supersonic
aircraft design and is also useful for conceptual design volumetric density methods. This is called
from the Analyze pulldown menu, and prompts for the number of cross-section cuts and the pixel
sample grid size. Use 50 | 1000 or higher to get a more-accurate plot, but it will take a lot longer.

Before running the volume plot, limit the components being viewed to the external ones, to save
time. Also, for some calculations you should first create a “broomstick” component in front of
the inlet, and behind the nozzle. These are just extrusions of the inlet or exit cross section to the
front and back of the design, so that the volume plot doesn’t show a sudden jump caused by the
massflow of the jet engine.

During volume plot analysis you’ll see your design slowly sliced from nose to tail, with the
background filled by red. The analysis is actually flooding the background with that color, except
for the aircraft cross section cut, and then measuring how much of the red color is on the screen.
This is a sneaky, backwards way of analyzing the volume, and it doesn’t require the user to create

89
a perfect solid model geometry to get a useful result. But don’t try to bring another Windows
program to the foreground during this operation – RDS needs to “see” the slices.

If you’ve already created a TAB file for that design, you’ll then be asked if you wish to add the
volume plot data to the TAB file. It’s a good idea to do so.

The RDSresource directory includes file RDS-win_Volume_Plot_graph.XLS, which can be used


to create pretty volume plots including superimposing the contributions of the various
components. To create data for this spreadsheet, first Select for View the various external
components. Analyze the volume plot, review the graph, then view the results in your spreadsheet
using ListAndPrint - ListLastResults (first set UseMySpreadsheet). Copy the entire page into the
Data worksheet of that spreadsheet file, and note the remaining instructions there.

In RDSwin-Pro, volume distribution plots can be created at canted angles corresponding to Mach
Plane Cuts. This allows shaping to reduce supersonic drag at higher Mach Numbers than the
transonic speeds implied by using perpendicular cuts. The routine prompts for the Mach Number
as well as the number of cross-section cuts and pixel sample grid size. Recall that Mach angle =
arcsine(1/M), measured off a perpendicular to flight direction. To be consistent with wave drag
slender body theory, the resulting Mach Plane Cut areas are projected in the streamwise direction,
ie., multiplied by the cosine of the Mach angle. This routine takes several minutes to run, showing
all the slicing operations on a red screen.

figure 52. Mach Plane Cut Volume Distribution plots

90
Design Export (-Pro only)
In RDSwin-Professional, the menu option Files-ExportDesignFile uses the current DLM design
data to create output files that can be read into a variety of other design and analysis programs,
as follows:

(yourfilename) _RDS-IGES.IGS IGES standard geometry format


(yourfilename) _RDS-DXF.DXF AutoCAD geometry (section points)
(yourfilename) _RDS-Rhino.TXT Rhino3D CAD geometry - (McNeel & Assoc)
(yourfilename) _RDS-VSA.VSA VS-Aero input file (Analytical Methods Inc.)
(yourfilename) _RDS-STL.STL Stereolithography (3-D Printing)

Once the Export command is select, on-screen instructions will lead you through the required
inputs and options such as axis orientation and point ordering. The default selections are usually
best. RDSwin automatically creates all of these file formats, stored in the same folder (directory)
as your design. Delete the ones you don’t need.

While the Export routine is working through the components, you may see a statement to the
effect that duplicate points or a degenerate SuperConic (all points the same) were found in a
particular component, and asking if you want to remove them. Normally you should not do so,
especially if you plan to use the IGES or Rhino3D exported files.

The reason this option is available is that the surface-fitting routines of some CAD systems won't
work properly with duplicate points and you may see wild lines around your actual geometry.
This seems especially a problem with CAD systems reading the old DXF-format data. Usually
IGES data will have no such problems, and the RDS-Rhino interface fixes them automatically.
If you do see such wild lines, try doing Export again and reply Yes.

It is a good idea anyway to avoid designing using degenerate cross-sections. In other words, don’t
scale the first cross-section by 0.0 to bring the fuselage to a point. Instead, scale by 0.001 or so.

The RDSwin IGES export capability allows commercial CAD systems to immediately read the
full RDSwin design geometry. This routine includes automatic conversion of DLM SuperConic
surface and cross-section components into 4 th degree Bezier polynomials, stored using NURBS
(Non-Uniform Rational B-Splines). This is done by mathematically moving the center point from
the shoulder point actually on the curve as used for RDSwin SuperConics, to a location “floating”
near the curve as used for Bezier curves.

Point and SuperConic Section components are translated using IGES Entity Type 118 (Ruled
Surface). The cross sections of Point components are defined using straight lines (Type 110),
whereas SuperConic cross sections are defined as Rational B-Spline Curves (Type 126).
SuperConic Surface Components use IGES Type 128 (Rational B-Spline Surface) and as a
result, require less data and create a better geometry.

Each entity also has an IGES Color Entity (Type 314). Normally this will be the default color
used when rendering in RDSwin and is based on the current background color. If the component’s

91
ViewCode indicates a Hue, that color is used for the IGES Color Entity. This example shows
RDS colors transmitted through IGES, as rendered in Solidworks.

Since its inception, RDS has followed historical drafting table practice having yaw to the right
and Z upwards, which actually defines a left-handed coordinate system. The output IGES file is
automatically converted to a standard right-hand coordinate system, so the left side cross sections
you’ve designed in RDS will all have negative Y values when exported.

The IGES file created by RDSwin includes mirroring for symmetrical components and mirroring
across the aircraft centerline. This is done based on the viewing options at the time the IGES file
is created. Since mirroring across the aircraft centerline will double the already-large IGES file,
it may be wise to make the IGES file without mirroring, and do mirroring in the other CAD
system. Before exporting a design, view it in isometric (“i”) and make sure that the mirroring is
the way you want it in your IGES file (change using DesignViewOptions).

STEP output is not supported, but all major commercial CAD systems can read IGES which
remains a widely-used neutral file format. RDS win does not use the types of extra information
that makes STEP superior to IGES for certain applications, so nothing is lost. There are many
free IGES-to-STEP converters if STEP is specifically required for some reason, or the IGES file
can be opened in your commercial CAD system (including Rhino) and saved as a STEP file.

The DXF Export file format can also be read into most commercial CAD systems. However, the
DXF file is just a collection of points. Even SuperConic components in RDS win are converted to
points before the DXF file is created, using the current number of points and sections per
SuperConic.

The design geometry is not connected or surfaced when passed using DXF. You’ll have to use
your CAD system’s commands to select cross-sections and build the surfaces, including any
trimming and detailed shaping that may be required. The DXF format is considered obsolete, and
should be used only when the far-superior IGES file is inappropriate for some reason.

92
Rhino3D is an affordable CAD system with impressive capabilities. A free evaluation version
can be downloaded at www.rhino3d.com, and can instantly read in RDSwin DLM geometry and
create realistic renderings. The evaluation version won’t permit saving the design as a Rhino file,
but you can just read it in again from the RDS output! Of course, if you use it regularly then you
should purchase a license.

The RDSwin output file for Rhino is a “command script” which instructs Rhino to create the
design components. Once in Rhino, use Tools/Commands/ReadFromFile and enter this filename.
You will see your design take place in the current viewing panes - wait for it.

All of your RDS components will be recreated as NURB surfaces in Rhino, with different options
for geometry fairing. They can be smoothly faired in both directions (longitudinal and around the
sections), or only longitudinally, or only around the sections, or neither. When you use RDS to
export design geometry you are prompted to decide this for each component, with the likely best
option as default. If you get strange shaping, try another option.

If you aren’t planning to use the Rhino script, just select Cancel when the first smoothing options
box pops up. This doesn’t cancel the whole geometry export, just the smoothing questions.

Your RDS components must have a constant number of points per section to work properly in
Rhino. SuperConic components are normally this way, and unless you change them by adding or
deleting points in a cross section, RDS wings and tails are this way too.

If the design isn’t mirrored across the aircraft centerline you can do it in Rhino as follows: Ctrl-
A to select All components, then Tools-Mirror. Type in 0,0,0 Enter, then 1,0,0 Enter. If you want
to mirror just certain components, select them individually with the mouse then do the Mirror
operation. You can also Mirror across a line other than the centerline by selecting two points with
the mouse instead of typing in the coordinates as above. Rhino may be confused by an
asymmetrical design. You can use Rhino mirroring commands to make it right.

Note that the Rhino script routine converts SuperConic components to points and then passes
them to Rhino, which then recreates them as NURB surfaces. This entails some loss of geometric
precision. The IGES file is actually preferable when accuracy is desired, and Rhino reads IGES
as easily as it reads its own scripts. However, IGES files are much larger.

VS-Aero is a classic aerodynamics panel code offered by Analytical Methods Inc. - see www.am-
inc.com/VSAERO.shtml. It combines integral methods for potential and boundary layer flows
giving it excellent results for a code of its speed, being able to compute a commercial airliner in
under 5 minutes on a desktop computer. The RDS-produced VSA file isn’t “run-ready” but it
contains the required geometry. Using it as a starting point, a VS-Aero input file can be quickly
defined.

Starting with Version 10, RDSwin-Pro will also export your design as a file for 3-D printing in
stereolithography file format (STL). This lets you make desk models of your latest design, either
on your own 3-D printer or through an online company like Shapeways (www.shapeways.com).
You might even find a 3-D printer at your local library.

93
The resulting STL file may need some filtering and cleanup depending upon which 3-D printing
machine is to be used, especially to make it “watertight”. There are various “STL repair” utilities
available, and the Rhino3D mentioned above has such capabilities. Be advised that the exported
STL file represents the actual 3-D geometry as you’ve defined it, not how you wish it to be!

The STL export routine is slow and creates a huge file so don’t do it if you don’t need it. There
is a yes-no prompt at the end of the Export setup, or you can delete the STL output filename in
the setup box to skip it. If you continue with the STL output you are prompted for a model scale
factor and whether you wish to translate the model so that all points are positive, and reverse the
calculated surface normals (try this if other software gets confused as to which way is “out”).

94
95
FUNCTIONAL ANALYSIS MODULES

Functional Analysis Overview


Air vehicle functional analysis includes aerodynamics*, weights, and propulsion. In RDSwin these
are largely based upon the classical analysis methods described in Dr. Raymer's widely-used
textbook, Aircraft Design: A Conceptual Approach (5th edition). These methods have been shown
to provide reasonable and reliable results for normal aircraft and, when properly applied by a
knowledgeable engineer, can give good results for a wide variety of unusual designs.

RDS functional analysis has been correlated with a wide variety of actual aircraft including the
Airbus A-321, the Lockheed L-1011, Global Hawk, the Cessna Caravan, the T-38/F-5, Dark Star,
early JSF designs, and many more, and has given surprisingly good results considering the
relatively few inputs and small amount of time required for analysis. Yes, better methods are
available, but don’t be surprised if those methods require ten times the effort for an answer only
slightly better!

Inputs for vehicle analysis are defined by the user in customized RDS win input grids as described
in the RDS Operational Notes above. For aero, weights, and propulsion, the grids are mostly
paired columns of data and labels, plus some paired columns of data such as drag versus Mach.
Both types can be seen in the sample grid of figure 53. Required inputs for specific analysis are
shown in the grids using the equations, variable names, tables, and figures employed in Dr.
Raymer's book. These are explained in pop-up boxes that appear when you click on an analysis
grid column title (second row).

When you’ve created or opened an analysis input grid, its name is placed on the flowchart box
of the RDSwin main screen. To clear that name and select or create another file, either Close that
file or select File-New or File-Open. If you’ve made any changes, RDS will ask if you want to
save them. These functional analysis inputs are saved in data files with the appropriate filename
extension (.rdsDAA for aero, .rdsDWT for weights, and .rdsDPR for propulsion).

*
Including longitudinal stability & control, if desired

96
figure 53. Typical Analysis Input Grid (Piston-Prop Propulsion)

After initially selecting column types and various options, the data in the analysis input grids can
be entered. Remember that the ParseVal input processor allows simple expressions and
abbreviations, such as 45/12 or 10k. When you create a new input grid, RDS will include typical
defaults for various items. Review them carefully – they are just guesses.

Some data items are not numbers, but “yes” or “no” next to a label. Click on the yes/no button to
change it. `

Much of the required input data comes from the aircraft design geometry, such as wing aspect
ratio and fuselage wetted area. If you are modeling an existing airplane, or you designed your
airplane in some other CAD program or on a drafting table, you can just type in that geometric
information. Some of the same items are needed in the Aerodynamics and Weights modules. If
you do the Aero grid first and save it, then when you are doing the Weights inputs you can select
“Analysis Grid Input Tools-Get Weights Geometry From Aero File *.”

Most users will start by designing their airplane in the RDS-DLM and select DoAnalysis to create
a TAB file. If a TAB file with the same name exists in your project directory, RDS will offer
“Make New Input File from Geometry From DLM TAB File” when you go to the functional
analysis modules. If you’ve already created an analysis input file, or want to start with an existing
one but modify it based on changes to your design, you can select “Analysis Grid Input Tools-
Get Geometry From DLM TAB File.”

Either method pulls the geometric information from your design into the analysis grid, in the
appropriate locations. Check this data carefully, especially wetted areas and maximum cross
section area in the Aerodynamics module. The pop-up help boxes provide more information. To
help you review the transfer of geometric data from design to analysis input file, the DLM

*
Coded in response to user complaints – “why do I have to enter all that stuff twice?” You’re welcome.

97
components that were used to “stuff” data into the analysis input file columns are detailed in the
input file notes - see Edit…InputGridNotes.

New to RDSwin Version 10, you can now change the data column names in an input grid. The
default column names are related to the type of analysis method to be used, but you may prefer
other text. New column names are defined in the input file notes (Edit…InputGridNotes) in a
specific format as follows:
[column 1=AAA 2=bbb 6=Fff]
This will change the first column title to “AAA”, the second to “bbb”, and the 6 th to “Fff”. All
others including 3, 4, and 5 will be left to their normal header text. The square brackets and the
word ‘column’ is required. You can also use [column], [col], [header], [head], or [title]. This
identifier text must be lower case, but your titles can be any case. If you wish to disable this but
save it for later use, just put a space after the first square bracket.

Once an input file is created and the appropriate data is


entered, Do Analysis can be selected from the pulldown
menu or the menu buttons at the bottom of the screen.
Review the analysis results carefully, and modify the inputs
as needed. When the answers look reasonable, go to the
pulldown menu and select “Run Analysis And Put Results
In Aircraft Data File.” Then, go to the Aircraft Data File to see and graph the full results. Note:
just clicking on the Do Analysis button does NOT put those results anywhere!

Also, RDS does not automatically save the functional analysis results to any permanent file. This
is only done from the Aircraft Data File Module where the data from Aerodynamics, Weights,
and Propulsion are collected for review and application. You must go to that module and select
Save to do so. This RDS feature is deliberate – you should carefully review the results before
saving them or using them in Sizing, Performance Analysis, or Optimization and Trade Studies.

Aerodynamics
The RDS Aerodynamics Module estimates subsonic and supersonic parasite drag, drag due to
lift, lift curve slope, and maximum lift from a user-defined input grid (filename extension DAA).
That grid always includes a data column of miscellaneous inputs including the speed and altitude
range over which calculations should be made. There is always a second data column defining
the reference wing – you MUST have a wing column, to provide the reference area! Other
columns are selected by the user in a graphical pick screen.

Note that the column names are NOT the component names you
provided when doing the design layout. Instead these are analysis
category names that should indicate to you what equations and
methods will be used for analysis. You should check these
categories and the data in each column with the components in your
design, to make sure all components are included and that RDS has
properly assigned them to analysis categories. You’ll have to use
your own judgment to ensure that the analysis columns reasonably approximate the reality!

98
Subsonic parasite drag is estimated by the component buildup method (eqs. 12.24-12.39 in Dr.
Raymer’s textbook)*. Supersonic wave drag is determined by the equivalent Sears-Haack
technique (eq. 12.46). Transonic drag is determined by empirical fairing between M DD (book
figs. 12.26 and 12.27) and the supersonic wave drag, using a cubic polynomial curve fit (book
fig. 12.29).

Drag due to lift is calculated by the leading-edge suction method using C L-alpha calculated with
book equation 12.6 and fig. 12.6. The input design lift coefficient (C L-design) is used to select the
leading edge suction schedule from book fig. 12.35.

For subsonic, thick-wing designs, the graph of book fig. 12.35 is automatically modified during
RDS analysis to provide 93% leading edge suction at all lift coefficients below design CL. This
is common industry practice.

For high aspect ratio wings, the leading edge suction schedule actually becomes a function of
aspect ratio, with percent suction increasing for very high aspect ratio wings. RDS handles this
by automatically adjusting the default suction schedule in book fig. 12.35 so that an equivalent
Oswald’s Span Efficiency Factor (“e”) at the design lift coefficient is no less than the value stored
in file RDSCONST (e=.8 unless you change it). This correlates well with actual aircraft data.
No additional user inputs are required, just the wing aspect ratio.

For an advanced fighter with automatic maneuvering flaps, their contribution should be included
in the Aircraft Data File input grid both as an increase in maximum lift and a reduction in drag-
due-to-lift factor “K.” RDS estimates the reduction in K for such an aircraft by shifting the
leading edge suction schedule by a C L of 0.2, which is activated by entering a negative value for
design lift coefficient in the Aerodynamics input grid. Enter the lower design lift coefficient
value preceded by a minus sign. For example, if you enter (-.4) as the design lift coefficient, RDS
will use the (.4) design CL suction schedule up to (.4), maintain the peak value to (.6), then follow
the (.6) design CL schedule for higher values. This is a fairly rough approximation, but gives
reasonable results for early design studies.

In RDSwin-Professional, you can define and use your own leading edge suction schedule if you
feel that book fig. 12.35 is not representative of your aircraft. Historically, the US Navy has been
especially insistent upon using its own LE suction schedules. See file RDSconst.rdt for
instructions on how to create such an alternative leading edge suction schedule. Then you can
apply it to your design by indicating “Yes” in the first column data item labeled Alt. LE Suction
in the Aerodynamics Module inputs. This is rarely required or desired – the RDS suction schedule
is fine for most designs.

Maximum lift is calculated using book figs. 12.8 and 12.9, also from DATCOM charts. Those
charts and their RDS implementation are considered reasonable only for moderate to high aspect
ratio configurations. For very low aspect ratio configurations (<<3) this method underestimates
maximum lift because it ignores the additional vortex lift contribution that should be expected.

*
Starting with RDS V7.2, the boundary layer drag estimation includes the Wave Drag effects. This may cause a
higher value than obtained with the same inputs in prior versions of RDS, but not by much.

99
For a better answer you can estimate maximum lift yourself then enter it in the appropriate input
grid in the Aircraft Data File (.rdsDAT). Or, you can use the RDS estimate knowing that it will
be somewhat conservative.

If you choose to enter the maximum lift directly in the Aircraft Data File, make sure you leave
the airfoil maximum lift coefficient in the Aerodynamics Module input file as zero (0). This
stops RDS from doing its own maximum lift calculation and overwriting your input value.

Maximum lift as calculated and stored in the Aircraft Data File C L-max array is for the flaps-up
condition and is used for up-and-away performance calculations. The flaps-down maximum lift
for takeoff and landing calculations can be treated in one of three ways.

By selecting and completing an input column for leading and/or trailing edge devices in the
Aerodynamics Module, RDS will calculate reasonable takeoff and landing drag polars including
high-lift devices. These polars are stored in the Aircraft Data File as Alternate Drag Polars #1
and #2, along with Polar #3 which is a low-speed flaps-up polar. If you also select a landing gear
input column, the gear drag is NOT added to the polars - instead it is calculated and saved in its
own data item, to be added to the drag when appropriate.

Alternatively, the user can directly enter Alternate Drag Polars for takeoff and landing into the
Aircraft Data File. This is often done when data exists for a similar configuration – it is normal
in industry to trust adjusted real data more than bottoms-up analytical estimates in this hard-to-
predict parameter.

In either case, the appropriate Alternative Drag Polar number must be indicated in the
Performance Analysis inputs (see below). This causes the performance analysis to ignore all other
aerodynamic data in favor of the alternative polar selected.

A third option for entering maximum lift (CL-max) is to enter it directly in the Performance
Analysis inputs in the selected columns. This overrides the other options.

Longitudinal stability and control are evaluated using first-order methods from the DATCOM
and other sources. Stability and control calculation is optional, and is obtained by selecting a
Stability and Control data column in the Aerodynamics Module, entering the required data, and
then running analysis. RDS calculates the neutral point, pitching moment derivative, and other
stability parameters. Then it displays a trim plot for the input speed and altitude, followed by a
graph of neutral point, static margin, and CM- as functions of Mach number. For subsonic aircraft
(M<.7), both stick-fixed and stick-free results are presented.

If you are storing aerodynamic results in the Aircraft Data File and you have a Stability and
Control data column, trim drag as a function of Mach number and lift coefficient can be
calculated and stored as an adjustment to the induced drag factor (K). Trim drag estimation
includes the change in lift on the wing, the induced drag of the tail at the trim elevator deflection,
the rotation of the tail lift vector due to wing downwash, and the parasitic drag impact of the
elevator deflection.

100
This total increase in drag is used to adjust the drag-due-to-lift factor “K” such that the total drag-
due-to-lift including the effect of trim can be subsequently calculated just by multiplying this
adjusted K by CL2. This speeds up execution during iterative sizing and optimization runs.
However, when you then graph the resulting K matrix it may look strange compared to the
untrimmed K matrix – this is to be expected.

When creating a new aerodynamic input file, the user first selects from a menu the desired types
of aerodynamic components such as fuselage, tails, and canopy. An input column for a reference
wing component is automatically provided, and its area will be the reference area for all
aerodynamic coefficients. You cannot analyze a design without a reference wing, so when
analyzing a blimp or a rocket with no wing, you should enter a “fake” wing of the desired
reference area, but with wetted area set to zero so that the parasitic drag of the fake wing isn’t
included in the analysis. Using a “fake” reference area of 1.0 causes drag results to be in units of
drag area (D/q).

You can’t select an additional wing analysis column. Instead, model additional wings as
“horizontal tails.” These additional wings will only be used to calculate parasite drag and will
have no affect on lift or drag due to lift. To properly analyze such configurations as tandem or
joined wings, you’ll need to run a panel code or CFD. However, the RDS assumption that the
“main” wing is the only lifting surface probably isn’t too far off for sizing and performance
calculations, especially if you adjust maximum lift for the extra area.

For components and drag contributions not available in the list, you may select the arbitrary input
of D/q as a function of Mach number. This is typically done for an external store or the drag
penalty for an unusual radome or refueling probe.

There are many important terms in the first column of the aerodynamic data input array. The term
%WD Flatness permits adjusting the estimated magnitude of the typical reduction in Wave Drag
coefficient past Mach 1.2, as calculated by the statistical middle terms in equation 12.46 of the
textbook. This statistical term is based upon earlier supersonic jets which typically had rather
large wings compared to modern aircraft, so this equation may indicate an excessive reduction
in wave drag coefficient for a more modern design. Entering 0 for %WD Flatness uses equation
12.46 as written. Entering 100 causes the resulting wave drag curve to be completely flat (100%
flat), with no reduction past Mach 1.2. This occurs sometimes when the wing is rather small
relative to the overall cross section area.

A reasonable value for this term can be determined by comparing RDS results with data for an
existing aircraft similar to your concept. For a modern fighter, 50% seems to be reasonable.
Some companies and government organizations always apply a conservative 100% flatness
factor (i.e., no adjustment) even when more sophisticated drag codes indicate otherwise!

A key parameter in the analysis of wing lift curve slope as well as induced drag is the product
{F*Sexp/S}, which is the fuselage lift factor times the ratio of exposed to reference wing area
(Raymer’s book, eq. 12.6). If this product is greater than one, it implies that the total lift of the
actual wing plus the fuselage area covering the wing is greater than the lift of the trapezoidal
wing itself. This can happen, but rarely. For example, a wing with a large strake may generate

101
more lift than its trapezoidal planform would indicate. However, it is unlikely and RDS warns
you should it occur.

RDS allows you to override this lift contribution estimate {F*Sexp/S} by inputting your own
value in the first column input item Set F*Sexp/S. Setting this input to something other than zero
forces that value, otherwise the calculated product is used. As a typical, conservative limit, 0.95
can be used. If a negative number is input for this term (say, -0.95) the term F*Sexp/S is capped
at that absolute value (0.95), but can go lower if indicated by the geometry. This is especially
useful during optimizations where the wing size may be varied and the user doesn’t want RDS
to assume lift beyond the area of the trapezoidal wing.

Note that the maximum lift calculation is also corrected and constrained by this input term
F*Sexp/S.

The calculated parasitic drag is strongly affected by the assumed percentage of laminar flow.
This is used to determine the flat-plate skin friction coefficient, interpolating between turbulent
and laminar values. Previous versions of RDS only allowed a single percent estimate for the
whole aircraft, but RDSwin allows each component to have a different estimate. To maintain
compatibility with previous data files, both are permitted. If there is a non-zero value in the first
column it will be applied to the whole airplane, otherwise the values in the separate component
columns will be used. Typical estimates of attainable % laminar flow are in the table below:

Attainable laminar flow as a percent of wetted area Fuselage Wing & Tails
General Aviation - Classic Production Metal 0% 10%
General Aviation - Smooth metal (no rivets or cracks) 10% 35%
General Aviation - Smooth Molded Composites 25% 50%
Sailplane - Smooth Molded Composites 35% 70%
Subsonic

Helicopter - Traditional Design 0% 0%


Helicopter - Smooth Design 20% 20%
Civil Jet - Classic Production Metal 5% 10%
Civil Jet - Research Goal (passive) 25% 50%
Civil Jet - Research Goal (with active suction) 50% 80%
Military Aircraft with camouflage 0% 0%
Supersonic - Current 0% 0%
SS

Supersonic - Research Goal (with active suction) 20% 40%


-Unlikely past crack for movable surface like leading-edge flaps
-Unlikely near wing-mounted engines (~1 diameter each side)
-More difficult for wing with more sweep
-Reduces behind propeller (for area in propwash, multiply above by .8 to .9)
-These are for entire wetted area of wing, not just 2D airfoil
-These are percent of total wetted area, not the length from the nose

figure 54. Attainable Laminar Flow

For most supersonic aircraft, a reasonable assumption as to laminar flow at supersonic speeds is
simple - there isn’t any! Therefore, RDS normally uses turbulent skin friction coefficients at
supersonic speeds regardless of the input percent laminar flow. However, recent research offers

102
the hope of attaining some laminar flow at supersonic speeds. By inputting the percent laminar
flow as a negative number in the aerodynamics inputs, the input amount of laminar flow will be
assumed at both subsonic and supersonic speeds (good luck in actually attaining this!).

As described in Raymer’s textbook, a fictitious “cutoff Reynolds number” is used to adjust the
skin friction coefficient for an aircraft with relatively rough skin surfaces. This calculation uses
a roughness coefficient called “k” which can be found in the table below.

Surface k, ft k, m

Camouflage paint on aluminum 3.33  10−5 1.015  10−5


Smooth paint 2.08  10−5 0.634  10−5
Production sheet metal 1.33  10−5 0.405  10−5
Polished sheet metal 0.50  10−5 0.152  10−5
Smooth molded composite 0.7  10−5 0.052  10−5

figure 55. Skin roughness value k

For RDSwin-Pro, Alt. LE Suction=Yes indicates that an alternative leading edge suction schedule
as provided by the user in file RDSconst.rtd should be used. This option is rarely needed because
the default suction schedules built in to RDS are quite reasonable for most analysis. View this
file for more information.

The remaining data columns each contain information for one particular component or
component type. The first item in most aerodynamic data columns is the number of components
of the type described in the column. RDS already counts the left and right wing (or tail) as one
component, so unless you are designing a biplane, a 1 should be entered. If you are designing a
biplane you could enter a 2, and the parasite drag would be properly estimated. However, RDS
does not contain aerodynamic analysis for K and maximum lift of a biplane, so you must estimate
those yourself then type the results into the Aircraft Data File.

For wings and tails, the standard trapezoidal geometric parameters are used including area, aspect
ratio, taper ratio, etc… The wetted areas for wings and tails are estimated from the input exposed
areas using equations that essentially double that area then add a bit for the extra wetted area
around the leading edge. Alternatively, you can enter the actual wetted area if known, putting a
negative sign in front to indicate this (an input of -100 tells RDS to skip the wetted area estimation
for this wing or tail, and just use a wetted area of 100.)

Note that the classical aerodynamic methods used in RDS do not directly use the airfoil data. The
chosen airfoil impacts the aerodynamic calculations indirectly, through the inputs for design lift
coefficient, Cl-max, and percent laminar flow. Airfoil selection also influences the viscous
separation pressure drag which in RDS is approximated by calculation of a form factor (equation
12.30 in Raymer’s textbook). This is suitable for a normal, classical airfoil. The very best modern
airfoils, perfectly fabricated, will do a bit better which you can approximate by a fudge factor on
wing parasitic drag which is slightly less than one. Base this adjustment on your airfoil data.

103
One confusing aspect of the aerodynamic inputs must be noted. In the Fuselage drag column,
effective diameter “d” for the fuselage is required. This is the full effective diameter, and is used
to determine the form factor for subsonic parasitic drag. In the first column, though, Amax is
input. Amax is the total maximum cross section area of the WHOLE AIRCRAFT, including the
wing, but does NOT include the cross section area of the capture area of a jet engine. This term
is used to estimate supersonic wave drag. The air that goes “down the hole” (i.e., into the engine)
doesn’t affect the wave drag.

To get a better estimate of Amax, run the Volume Distribution Plot after creating the TAB file,
then say “yes” to “Add Volume Distribution Plot data to…”

For a supersonic airplane, the Fuselage drag column includes the term “Nose Length.” This is
the length from the front of the body to the point where the cross-section becomes essentially
constant, such as for a commercial airliner. A relatively short nose length affects the transonic
drag rise - see fig 12.30 in Raymer’s textbook.

X-Front is the X location of the front of the fuselage (usually X-Front=0). It is used only in
stability calculations, and affects the pitching moment calculation for the fuselage.

Fudge factors permit arbitrarily reducing or increasing drag by some value input by the user. The
use of fudge factors can be toggled on or off from the menu area, so that you can make an
aerodynamic calculation ignoring the fudge factors, without having to reset them all equal to 1.0.
Note that the drag fudge factor is only applied to parasitic drag, not drag due to lift (K).

When you select “Run Analysis And Put Results In Aircraft Data File” RDS will load the
calculated parasite drag, drag due to lift factors (K), and maximum lift coefficients into the
currently-open Aircraft Data File. Go there to graph, list, and print these results. RDS does NOT
automatically save these results to a disk file, and you must go to the Aircraft Data File Edit
Module and select Save to do so. These aerodynamic results stored in the Aircraft Data File,
along with the required propulsion and weights data as described below, may then be used for
sizing and performance calculations.

104
figure 56. Typical Aerodynamic Results

Weights
Like the other Functional Analysis calculations, Weights analysis
is done from an RDSwin input grid (filename extension DWT).
That grid always starts with the same 13 data columns, which
cannot be deleted. Additional columns, if needed, can be selected
by the user in a graphical pick screen. There can be multiple
copies (up to 5 each) of certain weights columns including wing,
tails, fuselage, nacelle, landing gear, etc.

As with aerodynamics, the column names are NOT the component names in the design layout.
They are analysis category names telling you what equations and methods will be used. Again,
use your own judgment to ensure that the analysis columns reasonably approximate the reality.

Any weights items that cannot be calculated or input in the available analysis columns must be
entered in the last (13th) column as either miscellaneous empty weight (We-misc) or miscellaneous
load (Wload-misc). This includes things like Wing Fold, Arresting Gear, Catapult equipment,
galleys, toilets, stealth weight penalties, and more. You may need to split them out later in your
Group Weight Statement for reporting purposes.

Component weights are estimated statistically using the equations from Dr. Raymer's textbook,
copied below as Appendix A. When starting a new weights analysis input file you are prompted

105
to select aircraft type as either Fighter/Attack, Transport/Bomber, or General Aviation. This
selection defines which of the three sets of equations will be applied.

If none of these categories can approximate your design you’ll have to estimate its weight
elsewhere and just enter the values needed in the Aircraft Data File for sizing and performance
calculations. However, with suitable adjustments and “fudge factors” these three sets have been
found to approximate most design types. For example, most UAVs are modeled fairly well by
the General Aviation equations, except for the large “UCAV” types which seem to follow the
Fighter/Attack equations. As with everything in aircraft design and analysis, your judgment is
essential!

You must give all relevant inputs if a default value is not provided in the array. While RDS
checks for divide-by-zero, you will get nonsense results if a parameter is left out. You may leave
all zeros in a column if your aircraft doesn't even have a particular component (such as a
horizontal tail), but for other components you must set all parameters including constants which
are 1.0 for your design (for example, you must set Kdw=1.0 for the wing of a non-delta-wing
design). Read the variable descriptions carefully as you input them into RDS!

Note that the statistical weights are estimated from an input design gross weight (Wdg). This
may or may not be the same as the design takeoff gross weight (Wo), which is the total weight
used for the group weight statement to calculate fuel available. Inputs are required in RDS for
both Wo and Wdg, for fighters and transport aircraft. For fighters especially, it is common to
define Wdg as the aircraft weight after burning off some of the design fuel. A typical Wdg is
defined as the aircraft weight carrying some specified payload, with 50-60% of maximum
internal fuel. This may be only about 85% of Wo. This can make a big difference in the calculated
empty weight.

In the last column of weights entries, a fudge factor can be applied to the total previously
calculated empty weight. This provides an Empty Weight Margin which reduces the project risk.
Typical values are between 5% (input as 1.05) and 10 % (1.1). Upon weights analysis, the empty
weight margin will appear as the last item in the empty weight buildup.

Also in the last column is the Uninstalled Avionics Weight (Wuav). RDS win uses statistical
equations to approximate the installation weight including racks, power connections, cooling,
and the like. This typically adds about 50% to yield the Installed Avionics Weight in the analysis
results. If you wish, you can estimate Installed Avionics Weight yourself and enter it as a negative
number such as -400. RDSwin will skip the installation analysis and use your number directly as
the installed avionics weight.

Fudge factors permit estimation of the weight impact of non-standard materials and other
emerging technologies. Fudge factors can also be used to calibrate the RDS weights equations
to some known design. The use of fudge factors can be toggled on or off from the menu area, so
that you can make a weight calculation ignoring the fudge factors, without having to reset them
all equal to 1.0.

106
A simplified but often-used method for weights estimation can be employed in RDS instead of
the statistical equations described in the textbook. Component weight ratios, such as pounds per
square foot (kg/sq m) can be used to estimate wing, tail, and fuselage weights. Similarly, landing
gear weights can be simply calculated using an input percent of Wo. These inputs, if used,
completely override all other weights inputs (except that fudge factors are still applied).

Center of gravity is determined from input component locations, and is summed for empty
weight, zero-fuel weight, and takeoff gross weight.

During mission sizing calculations, RDSwin uses an exponential coefficient to estimate the
variation of empty weight fraction with takeoff weight. This Empty Weight Sizing Coefficient
‘C’ corresponds to the empirical slope of the log of empty weight fraction plotted versus the log
of takeoff weight, as defined in table 3.1 and Figure 3.1 in Dr. Raymer’s textbook. This is defined
in the Aircraft Data File and is described in that section (below).

With RDSwin-Professional, ‘C’ is automatically estimated in the Weights Module and passed to
the Aircraft Data File. This is done by applying an arbitrary increase in gross weight of ten
percent, adjusting the weights equation inputs for changes such as the increase in wing area,
fuselage size, thrust, etc... This automatic method is usually better than using an empirical value
because it is based on your own aircraft design, but it should be checked with statistical values
typical for that class of aircraft before using it. This estimated C value is presented at the bottom
of the Weight statement when Analysis is done.

In the first column of the Weights input array for RDS win-Pro, an entry labeled Fixsize Engine
affects this calculation of the C coefficient. If this entry is set to “yes”, then RDS assumes that
the engine is NOT scaled with takeoff weight. This reduces the impact on empty weight of an
increase in takeoff weight compared to the case where this parameter is set to “no”, in which case
the engine is rubberized and scales up with increasing takeoff weight.

Similarly, “yes” for Fix We-misc entry causes the miscellaneous empty weight items you have
entered in the last weights input column to be held fixed in weight rather than scaled up by a 0.9
exponent with increasing design weight.

Those using the Student version of RDSwin can get a similar estimate of the Empty Weight
Coefficient C by changing the values in the Weights input grid. Pick and apply an arbitrary
increase in gross weight Wo-as_drawn. Change all the other parameters that will be affected if
the aircraft is larger and heavier, such as an increase in wing and tail areas, a bigger fuselage size,
larger tires, larger engine and nacelle, etc... Rerun the analysis to calculate the resulting We, and
do the math to find what ‘C’ must be in the equation:

(from Raymer, Aircraft Design: A Conceptual Approach)

107
When you select “Run Analysis And Put Results In Aircraft Data File” RDS will load the
calculated weights results into the currently-open Aircraft Data File. This includes the calculated
Empty Weight as well as the input Takeoff Gross Weight, Crew Weight, Passenger Weight,
Cargo (payload) Weight, Misc. Useful Load, and empty weight fraction sizing coefficient.

Fuel weight is not stored in the Aircraft Data File because the fuel weight is always calculated
by RDS as the remainder when empty weight and useful load are subtracted from takeoff gross
weight. Fuel weight available is shown in the Aircraft Data File but cannot be changed except by
changing one of the other weight values. No cheating!

RDSwin does NOT automatically save these results to a disk file, and you must go to the Aircraft
Data File Edit Module and select Save to do so. These weights results, along with the required
aerodynamic and propulsion data, may then be used for sizing and performance calculations.

One handy option in the RDSwin-Pro Weights Module allows you to input a different takeoff
gross weight (Wo) and have all other inputs for weights analysis parametrically adjusted. This
is used to create a detailed group weight statement from a sizing result, and is found in the Options
menu.

NOTE: Version7.2 fixed an old, unnoticed bug in the weights estimation for Transport and Cargo
aircraft. The Flight Control equation (15.35) was missing the exponent on Nf (number of
hydraulic functions) causing that weight to be overestimated. Also, the Hydraulic weight
estimation for General Aviation aircraft, while not incorrect before, has been improved using the
hydraulics weight factor Kh (Eq. 15.55, below). If Kh is left blank, the simpler analysis from
earlier editions of Raymer’s textbook is used, so your results will not change.

Propulsion
RDSwin Propulsion analysis includes installation analysis for jet engine thrust and specific fuel
consumption, and propeller thrust and specific fuel consumption for piston-prop engines.
Turboprop engine analysis includes both propeller analysis and inclusion of the additional thrust
due to residual jet exhaust.

As in the Aerodynamics and Weights modules, Propulsion input is done in an RDS win grid
(filename extension DPR). When you create a new one, a pick list offers Jet, Piston-Prop, or
Turbo-Prop. Options for inlet efficiency, propeller efficiency, and other parameters are prompted.
The relevant geometric information can be pulled from the TAB file.

Jet engine installation analysis takes an already saved file of manufacturer's uninstalled engine
data and applies corrections per chapter 13 of Dr. Raymer’s textbook. The uninstalled engine
data (thrust and specific fuel consumption) is entered using the Aircraft Data File Edit Module.
When this file is saved, it should be given a filename ending in .rdsDJT or it will not be listed as
available when you need it.

After this uninstalled engine file is created and saved, the Propulsion Module is selected and a
propulsion input file is created. An input grid is used to input required parameters such as

108
reference and actual inlet pressure recovery (vs. Mach), bleed coefficient, and inlet drag (vs.
Mach). Defaults are provided for many values, such as the MIL-E-5008B reference pressure
recovery schedule (book eq. 13.5), and typical actual pressure recovery schedules for various
types of inlets. These defaults may be overridden by entering new values in the input grid.

For propulsion analysis of a non-rubber, or "fixed-size” engine, enter a zero (0) in the "Thrust-
net" entry item. RDS will use the given engine without scaling, and will determine the resulting
installed thrust. This is used for design with an actual engine.

An afterburning jet aircraft can use part-AB operation for cruise. This is described in the Mission
Analysis section below, and turned on in the sizing options menu.

Propeller propulsion analysis does not require (or use) an uninstalled engine file, and instead
calculates thrust and specific fuel consumption strictly from inputs in the Propulsion Module
input file. These inputs include horsepower and brake specific fuel consumption as functions of
altitude, propeller efficiency as a function of Advance Ratio (J) and Power Coefficient (Cp), and
static thrust coefficient ratio as a function of power coefficient. Default values are provided for
various types of propellers, or you can enter new values from some other source.

Engine power is input as a function of altitude at maximum continuous cruise power. If only one
value is given, RDS assumes a normally aspirated (non-supercharged) engine and degrades
power with altitude following equation 13.9 from Dr. Raymer’s textbook. The single value given
for maximum (takeoff) power is ratioed in parallel with the given cruise power, although
generally maximum power is not used at high altitudes. Power specific fuel consumption for
takeoff power setting is input as a ratio to the cruise setting.

If a piston-prop engine has power that is substantially a function of forward speed for some
reason, it should be treated as a turboprop with zero residual thrust (see below).

Propeller thrust calculation interpolates the propeller efficiency tables to calculate gross thrust
for the input engine power. This includes a blockage adjustment that acts to reduce J for the
effect of the nacelle behind the propeller. A tip Mach number correction is employed, then
scrubbing, cooling, and misc. drag adjustments are added. A static thrust value is estimated from
the table of Ct/Cp, but is adjusted as required to ensure that the static thrust doesn’t exceed the
25 kt thrust by more than 10%, and doesn’t fall below the 50 kt value. Empirical fairing is then
used between the static value and the forward flight thrust results.

It is sometimes useful to know how efficient your propeller is, compared to a theoretical result.
RDSwin-Pro can calculate a comparison value based on a given propeller thrust ‘Figure of Merit’
which is similar to efficiency but includes the induced velocity effects. The ideal value of 1.0
means that all of the engine’s power is going to accelerate the airflow.

Most people will not use this so it is initially turned off. To activate it, find and open file
‘RDSwinParams.rtd’ using either NotePad or WordPad (not Word). Find the parameter
‘PropFOM.’ Change it from 0.0 to 1.0 for an ideal analysis, or some lesser value if desired. For
typical aircraft propellers the actual FOM should be about .85 to .95 but for comparison purposes,

109
you’ll probably want to use the ideal value. The calculated value will then be added to the detailed
propeller thrust analysis printout as ‘Ideal Max Power Thrust.’

Note that the propeller analysis creates exactly the same type of data as the jet installation
analysis, namely thrust and specific fuel consumption as a function of velocity and altitude. This
permits the sizing and performance modules to merely read the values when required rather than
recalculate them every time they are needed.

RDS handles piston-propeller engine data under takeoff conditions (maximum horsepower, full
rich mixture) by storing it in the first two engine matrices of the Aircraft Data File). The third
and fourth matrices store thrust and specific fuel consumption under leaned-out cruise conditions.
One special input required for this in the Propulsion Module is the ratio of fuel consumption from
max-rich to lean mixture setting (cmax/ceconomy), which is typically about 1.15 for regular engines
and about 1.55 for turbocharged engines.

Note that in the mission and performance modules the user should indicate maximum power,
full-rich operation by a throttle setting of 999 (like afterburner for a jet), and indicate a maximum-
continuous cruise throttle setting as a percentage somewhat less than full power, perhaps 80%.

For turboprop engines, a previously saved file of manufacturer's uninstalled engine data provides
(horse)power and power-specific specific fuel consumption which are used for calculation of
propeller thrust and thrust-specific specific fuel consumption as described above. The effects of
residual thrust are then added to the propeller thrust. The engine data must be entered using the
Aircraft Data File Edit Module. When this file is saved, it must be given a filename ending in
.rdsDTP.

These propulsion results, when analyzed and put in the Aircraft Data File, is used along with the
aerodynamics and weights data for sizing and performance calculations. See the next section for
important information about engine scaling and input of T/W.

In RDSwin-Pro, thrust and SFC can be evaluated for a Flat-Rated engine for use in sizing, mission
analysis, and performance. This is selected in Aircraft/EngineDataFileTools and basically
prevents the scaling of thrust if a non-standard atmosphere is in use. Otherwise, thrust obtained
is scaled by the ration (P/Po)/(T/To) which accounts for the change in density due to non-standard
pressure and temperature. For most users this is not needed, and if a flat-rated engine is to be
used, its thrust and SFC data will already take that into account.

110
111
AIRCRAFT DATA FILE
The Heart of RDSwin is a Filing Cabinet
The Aircraft Data File is the analytical heart of RDS. Think of it as a filing cabinet. First you fill
it with data from the Aerodynamics, Weights, and Propulsion modules, then you pull out that
data to run the mission sizing and performance calculations.

RDSwin works this way for several reasons. When you are calculating
something like rate of climb, RDSwin doesn’t have to recalculate the drag
coefficients. It just pulls them out of the “Aero drawer” in the “filing
cabinet”. This is much faster, especially for the big optimizations in
RDSwin-Pro.

This program structure lets you review and approve the analysis results
before they are committed to range and performance calculations. RDS win
facilitates this by stepping through graphs of all the stored data, with a
single pulldown command. And, it’s easy to correct data you don’t like.

With this method you can quickly do trade studies. Various tools in RDS win
let you scale or change these data items and then redo the mission sizing
and performance calculations. For example, you might multiply the whole
parasitic drag data array by 1.2 to determine the effect on range and rate of
climb of a 20% increase in CD0. In a recent study* for NASA, this technique was used to populate
a multivariable trade study space which was then input into commercial regression software,
resulting in a Response Surface model for further investigations. The customer loved it.

Finally, this filing cabinet approach lets you “mix and match” your data. You don’t have to use
the RDSwin calculations exclusively. For example, you could type in wind tunnel data for
aerodynamics, copy the propulsion data from a similar aircraft, use RDS win to estimate the
weights, and then use this mash-up to calculate range and performance.

The Aircraft Data File includes weights data, CD0, K, CL-max, CL-alpha, installed engine thrust,
specific fuel consumption, and certain other parameters. This is all contained in seven separate
input grids, as listed below. Except for the Weights & Misc grid, these are in array format as a
function of one or two variables such as velocity and altitude. This data is stored together in one
big file using filename extension DAT. The sections below describe this data in detail.

In addition to these seven input grids, RDSwin-Pro can have seven additional arrays containing
part-power specific fuel consumption data. In RDS win-Student, part-power fuel consumption is
handled empirically, a simpler but less accurate way to deal with this. See below.

*
See www.aircraftdesign.com/FutureAirlinerStudy_Raymer_PrepublicationCopy_rev9-2011.pdf

112
- Weights & Misc (Wts, T/W, W/S, Stores Drag, Alternate Drag Polars)
- Cdo (Parasite Drag Coefficient)
-K (Induced Drag Factor)
- CL max & CLalpha (Maximum Lift Coefficient & Lift Curve Slope)
- Maximum Afterburning Thrust (or Max Power Propeller Thrust)
- C At Maximum Afterburning Thrust (or Max Power Propeller SFC)
- Maximum Dry Thrust (or Max Continuous Prop Thrust)
- C At Max Dry Thrust (or Max Cont. Prop Thrust SFC)

Data can simply be typed in if it is available from some other source. This is often the case when
estimating performance for an existing airplane. Normally, though, the RDS win Aerodynamics,
Weights, and Propulsion Modules are used to calculate the data which is then passed to the
Aircraft Data File. This is done using the pulldown menu option “Run Analysis And Put Results
In Aircraft Data File.” You must have a “filing cabinet” open to receive the data. If there isn’t
one open already, you’ll be taken to an Open File dialog.

Caution: The data that you calculate and pass to the Aircraft Data File is not saved to the disk
until you tell RDSwin to do so. Go to the Aircraft Data File, review the calculated data (Graph-
All is helpful), and if all looks good, select File-Save or press Ctrl-S.

When in one of these Aircraft Data File arrays, you can navigate to the others using Jump To, or
by using the buttons lined up just below the data. These are a little confusing because the button
for the array you are viewing is not shown, which causes the others to move around when you
change to another array.

Remember that the units can be toggled instantly by clicking on the current units (FPS or MKS)
or by pressing #.

In response to the request of a major engine manufacturer, RDS win-Pro now allows more than 10
altitudes for propulsion and drag tables, up to 30 in all. This permits closer-together engine data
and thus more-accurate analysis. For most users, 10 altitudes is sufficient.

To navigate to the additional altitudes below the 10 altitudes shown on the initial screen, use Ctrl-
ArrowDown. Just running off the screen to the bottom takes you to the bottom buttons, not the
next page. Similarly, Ctrl-ArrowUp goes up a page.

To create a new data table with more than 10 altitudes, just enter them when prompted. Or, you
can enter something like “0 to 50k step 2000” which will create a table with 26 altitudes. You
can also add more altitudes using Tools-Aircraft/Engine Data File Tools-Insert a Row.

Note that once you have 11 or more altitudes, the last page downwards may show extra rows
with altitude=0. Don’t worry about this. If you wish, you can click on them and enter new values,
provided they are increasing from the highest altitude already entered.

113
When using more than 10 altitudes, the RDSwin graphing routine will show a graph of the 10
altitudes currently shown on the screen. To graph the data below the first 10 altitudes, first use
Ctrl-ArrowDown then select Graph or press “G”.

Starting with Version 10, RDSwin has a unique capability for adjusting data visually in the Aircraft
Data File. For example, if the installed engine data looks strange or has a few “bad” data points,
you can fix it! Make a graph of the data by pressing “G” in the input grid (NOT by using the
pulldown menu). Press “L” for the Locate routine and position the cursor over the offending data
point. Then press “P” for point or “=” for “make it so.” Move the cursor up or down to the desired
new location and click. All fixed. Note that you cannot move the points in the X direction. Also
note that this makes it easy to “cheat”. Be nice.

Weights & Misc and Much More


The first input grid (figure 57) holds the key aircraft weights data needed for performance and
mission analysis, along with other important parameters.

The T/W and W/S entries in the first column are so important that they have their own User’s
Manual section (below). Read it carefully or all of your calculations will be incorrect!

The weights values in the Aircraft Data File include only the as-drawn takeoff and empty weights,
the crew, cargo, passenger, oil, and miscellaneous useful load. This is typical of the Aircraft Data
File – it only includes the information directly needed for mission sizing and performance
calculations. For the full weights buildup, see the Weights module calculation results.

figure 57. T/W, W/S, Weights and Other Data Input Grid (partial)

114
Note that fuel weight is NOT an input here, nor anywhere else in RDS win. Fuel weight is always
calculated as the “left over” weight when all the others are subtracted from Wo, and is shown in
its own box at the bottom. This is deliberate – it’s how the design process works. If you want to
specify a certain fuel weight you’ll have to adjust some other weight items to make it happen *.
It’s just like a real airplane. You can’t stuff in more fuel without taking out some cargo or
passenger weight, or finding a way to reduce the empty weight.

At the bottom of the first data column is the statistical Empty Weight Sizing Coefficient ‘C’. This
is the exponent found from a historical regression analysis of the trend of We/Wo versus Wo. It
is used during sizing calculations for estimating the change in empty weight fraction with takeoff
weight. This critical parameter is described in the Weights Analysis section above, and must be
a negative value. For a full description see Raymer’s textbook.

You can enter your own preferred value for C, or pick from typical values using pulldown menu
Tools - AircraftDataFileTools - PickEmpiricalWeSizing Coeff. This offers C coefficients for
various aircraft categories (Raymer’s textbook Table 3.1). If you use this Tool after you’ve set
Wo but with We still at zero, RDS will estimate We from the selected statistical equation. This
is a rough estimate only.

In RDSwin-Professional, the Weights Module will calculate C based upon your actual design
using approximations for the effect of a design weight increase on the input parameters. This was
described above in the section on Weights Analysis. With this method, the calculated variation
in empty weight during the sizing process is virtually identical to that obtained by a program
which recalculates the empty weight on a component-by-component basis. Using the C method
for calculating each new We greatly speeds up the analysis, especially for big optimizations. This
is one of the reasons that the RDSwin-Pro optimizer can go through 20,000 cases in the time it
takes to get a drink of water.

Set C=-1 to disable empty weight resizing, keeping We the same even as Wo changes. This is
used for estimating the weight of an overloaded aircraft on an extended range mission, and is
described in the Sizing Analysis section below. This gives the wrong answer for normal sizing
so be careful!

The number of engines, aircraft maximum load factor, and dynamic pressure are entered in the
second column of this input grid. Number of engines defines the engine-out thrust for balanced
field length. It is also used for calculating total thrust when the user provides thrust per engine
rather than T/W. When providing T/W, the given number is the total T/W and does NOT get
multiplied by the number of engines. See the next section for a full explanation.

Nmax is the in-flight limit load factor (n), not the structural ultimate load factor. For a modern
fighter aircraft Nmax is typically 8 g’s, whereas ultimate load factor is typically 12. The q-max
term is the maximum dynamic pressure assumed for structural design, and is used as a cutoff for
the flight envelope.

*
There is a special command in RDSwin-Pro to do just this, but it is not the normal preferred practice.

115
Several items in the second data column have an asterisk (*) in the label. These are used for
takeoff and landing calculations, but ONLY if those items have been left blank in the
Performance Analysis input grid. See that section below for a complete explanation.

To the right in this Weights & Misc input grid are two paired columns defining stores drag as
D/q per store versus Mach number. Stores drag refers to droppable stores such as bombs. These
are not included in the CD0 matrix as described below. The Sizing and Performance Modules
have inputs for the number of droppable stores (which can change during the mission). During
analysis, the number given is multiplied by the D/q values in the input grid. If your aircraft is
carrying and dropping different types of stores, the value stored should be the average D/q.

Farther to the right you will find space for up to seven Alternate Drag Polars. These allow directly
defining the drag for special conditions. All seven can be entered by the user, but the first three
are used automatically if flaps are included in the Aerodynamics module, namely for clean,
takeoff, and landing drag polars. Once defined, these Alternative Drag Polars can be selected by
number in the sizing and performance modules, bypassing normal drag calculations. This is
useful for variable geometry aircraft like the B-1, or for doing takeoff and landings with gear-
and-flap-down data calculated in more detail, outside of RDS win.

At the bottom of the Weights & Misc input grid is a space in which data file Notes and data
Genesis information are displayed. The Notes are entered using Edit-Aircraft Data File Notes
and can be any text that you chose to type. Only the first six lines are displayed on-screen, but
you can enter dozens of lines.

After you’ve finished entering Notes, you are taken to the Aircraft Data File Genesis Notes.
These exist to help you later in remembering just how you created this particular Aircraft Data
File. Whenever you do Run Analysis and Put Results in Aircraft Data File in the aerodynamics,
weights, or propulsion modules, the filename is written to the appropriate Genesis item. You can
change these or enter your own. These must be just one line per data item, as prompted.

T/W and W/S (or Thrust and Wing Area)


The first entries in the Weights & Misc input grid define the thrust-to-weight ratio (T/W) and
wing loading (W/S). These are critical parameters for aircraft performance, range, and mission
sizing calculations. They’re in almost every equation so if you have the wrong values here, your
final answers will be nonsense!

The weight W in both of these terms is the design takeoff gross weight (Wo-as drawn). During
calculations this is automatically adjusted to the actual weight of the airplane at that point in the
mission, based on fuel burned and payload dropped.

Wing area S is the planform area of the reference (trapezoidal) wing. This should match the value
displayed in the aerodynamic coefficient grids. It doesn’t have to match though, for advanced
users who wish to apply the coefficients to a different size of airplane.

116
The thrust T in the parameter T/W is the sea level static maximum thrust. If there is an afterburner
it is turned on. For piston and turboprop engines, this is the thrust obtained at maximum rated
power.

The T/W of your aircraft is defined by the value here in the Weights & Misc input grid, but the
Aircraft Data File has detailed thrust tables as separate input grids. This can be confusing.
Sometimes the thrust that you see in those tables isn’t the thrust that is applied to your airplane
during mission and performance analysis. RDSwin may scale it – if you say to.

To force RDSwin to use your actual thrust data tables WITHOUT any scaling, set T/W=0. The
actual thrust in the thrust data tables gets multiplied by the number of engines in the next column.
This also forbids thrust scaling so all sizing is done assuming a “fixed-size” engine. If the airplane
must grow to hold enough fuel for the mission, RDS win is not allowed to make the engine bigger.
This greatly affects sizing results. At the extreme, there may not be enough thrust to climb or
hold cruising altitude. Make sure that you understand the different sizing assumptions, and check
that the input here is the one you wanted.

Designers who are more familiar with piston engine aircraft often prefer to set T/W=0, and use
the thrust data table directly. Perhaps this comes from the rarity of new engine development for
general aviation aircraft.

To force RDSwin to use your actual thrust data for the as-drawn airplane but still allow it to scale
the engine during sizing, make T/W the actual value based on Wo and the engine thrust data.
You can use the simple calculations of ParseVal, entering an expression with values for thrust
and weight. For the sample DR3 design, enter 16150.4/56 which will be converted to 0.98 in the
grid.

A non-zero T/W allows what is called “rubber engine aircraft sizing.” During sizing calculations,
the engine will be scaled up or down to hold T/W as it was entered (0.98 in this sample). This
preserves the performance of the baseline aircraft. RDSwin doesn’t need to scale or adjust the fuel
consumption data since this is always saved as specific fuel consumption, ie., per unit thrust.

You can actually enter any T/W value here, and RDSwin will hold this and scale your engine data
accordingly. You don’t need to multiply the thrust array by some value to scale it up – just change
T/W. In fact, if you scale the thrust table up or down but don’t change the T/W value, RDS win
will just scale the thrust right back to the previous values!

When scaling is done during performance or mission calculations, the engine thrust of the whole
data table is automatically multiplied by a factor calculated to produce the given T/W value at
takeoff gross weight. This is based upon the FIRST data item in the FIRST thrust table. The first
data item is normally the sea level, zero airspeed (static) value. If the first thrust table (max ab
thrust or max power) has no data, then the next thrust table is used (max dry thrust or max
continuous power).

Regardless of the value of T/W, you can instruct the Sizing calculations to assume a fixed-size
engine by selecting Engine Sizing Options-Fixed Size in the pulldown menu (Analyze-Change

117
Sizing & Performance Options). The engine will not be scaled up or down during sizing, but it
will initially be scaled to yield the input T/W for the as-drawn aircraft. This fixed versus rubber
engine sizing option is saved with the mission model, not with the Aircraft Data File.

There is a completely different way of defining thrust and wing area for your design,
implemented for designers who aren’t used to thinking in terms of thrust-to-weight and wing
loading. They prefer actual thrust T and actual wing area S. For this, enter the actual static thrust
per engine (lbs or kN) in the box labeled T/W. The input grid label immediately changes to “T
per engine,” and is recognized whenever the value in the T/W box is greater than 2.0.

When actual thrust T is entered here, the actual wing area S must be provided in the next data
box rather than the wing loading. You CANNOT mix the parameters. Whenever you change
from T/W to T, or from T to T/W, RDSwin prompts for the appropriate S or W/S value. The pop-
up box has a default value calculated using the current W/S or S and the Wo value.

For example, if Wo=10000kg, T/W=0.9, and W/S=200 kg/sqm, then you enter T/W=100 kN,
RDSwin says: "T/W was changed to Thrust. Please confirm Wing Area S" and offers as default
S=50 sqm which is Wo/(W/S). You can click OK or enter something else.

If you try to mix T and W/S, RDSwin will think that the wing area is the number entered for W/S.
You’ll get the wrong answers during performance and mission analysis, if they even run.

When you enter actual thrust and wing area, the thrust value T gets multiplied by the number of
engines in the next column. The values in the thrust table are scaled to match that total during
mission and performance calculations. The desired thrust in the Weights & Misc input grid does
not have to match the actual thrusts in the thrust data table. RDS win will scale them.

The table below provides examples of these powerful but confusing thrust options.

SLS Thrust Value in Thrust Array: 10000


Aircraft Weight: 50000
# engines: 2

Input value in Total SLS Thrust Rubber Engine


Weights & Misc: used in calcs: Sizing?
T/W= 0 20000 No
T/W= 0.40 20000 Yes, unless turned off
T/W= 0.50 25000 Yes, unless turned off
T= 10000 20000 No
T= 14500 29000 No

figure 58. Sample Thrust Scaling using T/W and T

When you graph the thrust tables in the Aircraft Data File, RDS win checks to see if your inputs
will result in thrust scaling. If so, you are offered the option of graphing the raw or the scaled
engine thrust data.

118
The use of T/W=0 to indicate a fixed-size engine means that you cannot analyze a glider just by
inputting T/W=0. To analyze a glider you must trick RDSwin, giving a small value for thrust in
the thrust input grid (.000001), and some small but nonzero T/W value (such as .1). Don't give
a smaller value for T/W because it might be read as T/W=0. This is rather clumsy but RDS win
really wasn’t intended for gliders. With this one initial trick, it works just fine.

Engine Data – Thrust and SFC


The engine thrust and fuel flow data required during performance and mission calculations are
read from the information stored in the Aircraft Data File. This is entered or calculated in the
various engine data input grids. For jets, thrust and fuel consumption should be the installed data
including corrections for inlet recovery, inlet drags, nozzle drags, and bleed.

For propeller-powered aircraft the thrust and fuel consumption should include the propeller
efficiency effects plus loses from propwash, tip Mach number, cooling drag, and installation
miscellaneous drag.

A propeller-powered aircraft is treated exactly the same as a jet aircraft in the Aircraft Data File.
The engine power data is converted to thrust, and that thrust and its thrust specific fuel
consumption are stored in the same input grids as for a jet. RDS win barely knows and doesn’t care
how that thrust was created. For either jets or props, the thrust is read from the Aircraft Data File
when needed for a mission or performance calculation. Of course, calculating the thrust and SFC
is completely different for jets and props, as seen in the RDS win Propulsion module.

Engine data in the Aircraft Data File is contained in four separate input grids, each an array of
thrust or SFC versus speed and altitude. The first of the engine data arrays holds either maximum
afterburning thrust for a jet-powered aircraft, or thrust at maximum power for a propeller-
powered aircraft. Units are kN or lbs-force. These maximum thrust values are normally used
during takeoff, climb, and extreme maneuvering such as air-to-air combat.

If there is any data in this first thrust array, its lowest value (upper-left corner of grid) is assumed
to be the sea level static case. Make it so, when building your engine data arrays. It is this value
that is used to calculate the scale factor so that your engine data is scaled to match the T/W or T
value that you have input in the Weights & Misc input grid.

The second engine data array holds the specific fuel consumption for that first thrust array (max
AB or max power). Specific fuel consumption (SFC, or just C) is “specific” in thrust terms, being
fuel burn per hour per unit thrust. Metric units are mg/Ns. In British Imperial units, SFC is in lbs-
mass per hour per lb-force. This is traditionally presented as “per-hour” as if we could cancel
lbs-force with lbs-mass. It’s an ancient engineer joke.
.
Since this fuel flow data is given as specific fuel consumption, it does not have to be scaled when
the engine is scaled.

119
The next two input grid arrays are the thrust and SFC for either maximum dry thrust for a jet (no
afterburning), or thrust at maximum continuous (or economy) power for a prop. These tables are
used during cruise, loiter, and most other flight conditions.

If the first thrust array has no data, then RDSwin uses this dry or max continuous thrust data array
to define the thrust scale factor. You MUST have this second array populated. The first array,
and its SFC table, are optional.

In the RDSwin performance and mission/sizing analysis calculations, throttle setting is given as
percent of maximum dry thrust (or maximum continuous for props). If throttle is given as 80%,
RDSwin uses a thrust equal to 80% of the available thrust at that speed and altitude, as contained
in the SECOND of the thrust tables.

For cruise and loiter mission segments in the Range & Sizing Module, the given throttle setting
is an upper limit. The code calculates the actual throttle setting required. This calculated throttle
setting is compared to the allowed minimum throttle setting and if it is less, an error is generated.

To tell RDSwin to use the Maximum Thrust data array a throttle setting of 999% is used. This
lights the afterburning, or goes to maximum power setting with a piston engine. Part-AB
operation is also possible, as described in a separate section below.

The installed engine data can be calculated elsewhere and typed into the input grids, or can be
calculated in the Propulsion Module using the pulldown menu option “Run Analysis And Put
Results In Aircraft Data File.” Since the Aircraft Data File is in plain text format, it is also
possible to write a utility that takes installed propulsion data from other sources and “stuffs” it
into the Aircraft Data File format.

Thrust and SFC tables for piston-powered aircraft are calculated in the Propulsion module as
described above, with nothing needed except the numbers in that input grid.

For jet and turboprop engines, an uninstalled engine data file is needed. This is created as a new
file, not a part of your Aircraft Data File, but using the same RDS win input grid to enter the
manufacturer's uninstalled thrust and SFC. It takes about 30 minutes to type in the data, or it can
be copied into the RDSwin format with a utility program created for that purpose.

Indicate that the input grid contains uninstalled engine data by using a .rdsDJT extension for the
filename when you save it. In other words, create a new file and enter the thrusts and C's, then
save it giving a filename such as MYPLANE.rdsDJT Then you can go to the Propulsion Module
and apply installation corrections to the uninstalled data, putting the results in the Aircraft Data
File.

Similarly, turboprop manufacturer's uninstalled data is entered and stored in a file with extension
.rdsDTP. Turboprop aircraft need only one-each matrices of thrust and SFC. The Propulsion
Module copies the same data into the "Max" thrust and SFC arrays so that you can run the same
mission files for piston-prop and turboprop engines.

120
Instead of typing in the installed or uninstalled engine data, RDS win-Pro includes a routine that
can read engine data from a formatted text file and place it into the Aircraft Data File. This can
be used to set up an interface with your own engine analysis program, or to read thrust tables
obtained from other sources. Under Aircraft/EngineAircraftDataFileTools, select
ImportEngineData and enter the filename. A typical data file looks like this:

DR3 Thrust,SFC,&Fuel Flow Table


Altitude,Mach,Thrust ,SFC ,DataType
0 ,0 ,16150 ,1.355 ,AB
0 ,0.5 ,18761 ,1.439 ,AB
0 ,0.9 ,20579 ,1.577 ,AB
20000 ,0 ,8075.2 ,1.388 ,AB
20000 ,0.5 ,9234.2 ,1.454 ,AB
(etc…)

The first two rows are ignored. After that, each line must be exactly as shown here. “Data Type”
indicates which DAT array the data should be “stuffed” into (AB or DRY in this case).

The data must have the same Mach numbers for each altitude, starting at M=0 and Altitude=0.
There can be up to 20 Mach Numbers and 50 altitudes. The units of the data must match the units
you are using now (fps or mks). This must be stored as a pure text file (not a Word document),
and must be comma or space delimited. Data can be formatted this way in Microsoft Excel using
SaveAs...CSV, or it can be created by other programs. You can also use Excel to manipulate
thrust data from other sources into this format.

There are many more options for this tool, allowing the import of part-power data, turboprop
engines, minimum thrust tables, and more. There is a long descriptive text file that pops up when
you run this tool – read it carefully the first time you use it.

If you have engine data in fuel flow (lbs or kg per hour) rather than specific fuel consumption
data, you may enter it in the C matrix then select the “Convert Fuel Flow to SFC” in the Tools
menu. You must have the thrust data entered as well before you run this routine. It will then
convert your input values to C by dividing through by the appropriate thrust.

For expert users, RDSwin-Pro allows two additional paired tables of thrust and SFC, labeled
AlternateTableOne and AlternateTableTwo. These are created and viewed from the JumpTo-
AircraftDataFileEdit. These additional paired tables are treated the same as the current dry thrust
tables, and can be used for any purpose you desire. A typical example would be separate tables
for maximum climb thrust.

Use of these tables is selected in the mission and performance input arrays by entering “1” or “2”
in the last row item entitled AltThrustTable#, indicating used of paired alternate propulsion tables
One or Two (thrust and SFC).

121
Engine Data – Part-Power SFC and Part AB
Piston-powered aircraft show little variation of specific fuel consumption with power setting, so
their SFC data can normally be used for all throttle settings.

The same is not true for jets and turboprops. At a reduced power setting these turbine engines
often consume far more fuel per unit thrust, in some cases more than double.

There are several ways of dealing with this in RDSwin. The simplest option is to input typical
"cruise" SFC's in the non-afterburning SFC input grid rather than inputting the max-thrust SFC's.
This introduces some error if the thrust required during some mission segment is substantially
different from the assumed cruise thrust settings.

A better method, selected in “Tools-Part Power C Options”, uses a semi-empirical equation


developed by Dr. Mattingly, co-author of the AIAA textbook Aircraft Engine Design. This
method needs no additional inputs and provides a realistic increase in the SFC as thrust is
reduced. You should check this equation’s results versus your engine data to make sure that it is
representative.

c 0.1 0.24 0.8 1


   0.66x  0.1M (  x)
c maxdry x 0.8 x
x

where x = T / Tmax dry

When using this method you should enter the SFC values for maximum dry (non-afterburning)
throttle setting. Since this equation goes to infinity as X approaches zero, a cutoff value is
assumed but can be changed. There is also a correction fudge factor in case your experience
doesn’t quite match this relationship.

This empirical equation can also be applied to turboprops, but with lesser accuracy.

RDSwin-Pro includes a third method for handling the variation of jet engine SFC with thrust
setting, namely Part-Power Tables. This provides the best accuracy, but requires substantial
effort. The empirical approach is often almost as good, and a lot less trouble. But sometimes, the
better method is worth it.

RDSwin-Pro lets you define up to seven additional arrays containing part-power specific fuel
consumption data. Select use of Part-Power Tables from the Part-Power Options menu and enter
the data into the appropriate arrays. These define specific fuel consumption versus thrust for
different altitudes. Once created, Part-Power options and tables are selected by clicking on the
Part Power button at the bottom of any thrust input grid.

If entering manufacturer's uninstalled data, the Part-Power data will be "installed" when you run
the Propulsion module, along with the rest of the engine data.

122
These part-power SFC adjustments are not applicable to afterburning operation. Afterburning is
selected in sizing and mission analysis through the mission segment thrust setting input, which
is normally given as percent of maximum dry thrust from 0 to 100%. A value over 100% lights
the afterburner. In most cases such as combat and climb, this causes maximum afterburning thrust
to be used with fuel consumption accordingly.

Earlier jet aircraft had only one afterburner setting – full on! In RDS win this is selected by a
throttle setting of 999. Many modern jet engines allow partial afterburning, especially useful for
supersonic cruising. RDS permits this for cruise mission segments in the Sizing module. This is
selected by giving a thrust setting greater than 100% but less than 999% (say, 900%). RDS
linearly interpolates SFC between max dry and max AB values to match the required part-AB
thrust. This is approximately correct for most jet engines with part-AB capability.

Avoid giving a thrust setting of 999% for a cruise or loiter segment. RDS win will determine the
actual thrust required at the given speed, then apply the maximum afterburning SFC value to that
thrust. This is generally incorrect – afterburners just don’t work that way.

To have your aircraft cruise at whatever speed the maximum afterburning thrust will allow, you
can set thrust=999 and enter a way-too-high value for speed. RDS win-Pro will detect an error and
will slow the airplane down until the afterburning thrust exactly equals the drag.

Engine Data –Minimum Thrust


RDSwin allows specifying a minimum throttle setting for cruise or loiter (“flight idle”). This is
typically needed only for jet engines. This is done as percents of total thrust, using Analyze-
ChangeSizingAndPerformanceParameters. Be careful with this - when activated, you will get
noticeably different answers for optimum speeds and altitudes. RDS won’t allow the airplane to
fly at a condition where the thrust required falls below the defined minimum.

In RDSwin-Pro you can do this the “hard way” by creating tables of minimum thrust in the Aircraft
Data File. Select JumpTo-AircraftDataFileEdit-MinimumThrust, then build up a minimum thrust
table as you’d build a regular thrust table. Both dry and afterburning minimum thrust tables can
be defined.

When you run a mission, RDSwin-Pro will prompt how to handle it if the airplane tries to fly at a
condition that violates this table. Options include ignoring the tables and using the percent
minimums, using these tables but only warning in the printout if a problem is found, and testing
on T<Tminimum then fixing it if possible.

Aerodynamic Data
The Aircraft Data File Module contains three arrays of aerodynamic data, input by the user or
calculated in the Aerodynamics Module. These include Cdo, the Parasite Drag Coefficient, and
K, the Induced Drag Factor. Cdo is an array of coefficients versus speed and altitude. K is versus
speed and lift coefficient, and is based on the Leading Edge Suction method (see Raymer’s
textbook).

123
The third aero input grid contains two separate rows of data, the first being the Maximum Lift
Coefficient (Clmax), and second the Slope of the Lift Curve (Clalpha). These are functions of
speed only. Clalpha is used mostly in the V-n diagram gust calculations. The Aerodynamics
Module puts Clalpha here, but it can usually be left blank if you are hand-entering the data. In
RDSwin-Pro, Clalpha is also used in the ROAST trajectory module and in the output of data
tables for use in simulators.

Alternate Drag Polars can be stored in the Weights & Misc array, as described above. There is a
similar-sounding tool in RDSwin which is actually quite different. If you are analyzing an existing
aircraft for which you have good drag polars (CD vs CL), you can input those and then run a
conversion routine from the Tools menu to extract the K values and load them into the K array.
This is especially useful for entering wind tunnel data into RDS win.

First enter the CD's at CL =0 in the RDS CD0 matrix (for various velocities and altitudes). In the
K matrix, enter CD for different lift coefficients and velocities at some representative altitude.
Select “Convert Drag Polars to K,” and the CD0 and K matrices will be created for you.

Another tool allows you to change the reference wing area of the calculations. This is a hack for
experts, and is rarely needed.

Aircraft Data File Tools and Options


The Aircraft Data File Module has a number of data modification routines, available in the Tools
menu. These include addition and multiplication into the data, by row, column, or whole array.
This capability is very useful for the fudge-factoring used in trade studies.

For those working with rockets and missiles, RDS win allows displaying SFC data as Isp. In British
Imperial Units this is 3600/SFC. Isp actually makes more sense – a big number is a good engine.
But the Isp of rocket motors is terrible compared to jet engines, because rockets have to include
their oxygen in the propellant calculation. Jets get oxygen for free.

RDSwin-Professional will output detailed text files suitable for flight simulators and air combat
tools such as the classic Tac-Brawler. The data includes thrust and fuel flow at different speeds
and altitudes, and lift and drag as a function of angle of attack, This output is selected from the
Options menu.

Another useful tool allows you to copy data from another Aircraft Data File, or copy similar data
from one array to another within the currently open file. Select Tools - Aircraft/Engine Data File
Tools – Copy Arrays from Another File, then select the desired file to copy from. A menu will
pop up to select which data you wish to copy.

If you select the same file that is already open, RDSwin allows you to either get arrays from that
file which overwrites any changes you’ve made, or allows you to copy data from one current
array into another. For example, you may have already entered the engines Dry or Economy

124
thrust and SFC, and wish to copy that data into the Max Thrust arrays and then, perhaps, scale
the thrust up a bit. This tool makes it easy.

125
CAPABILITIES ANALYSIS MODULES

Capabilities Analysis Overview


Capabilities Analysis takes the results of the technical analysis (aerodynamics, weights, and
propulsion) and determines air vehicle performance capabilities including range, speed, altitude,
rate of climb, takeoff distance, and many other design requirements. This includes Sizing, which
calculates the required takeoff gross weight of a new design to perform some given mission and
range. Sizing is actually a performance-based inverse solution, asking “what takeoff gross weight
will give the range required?”.

Cost analysis is included in this section because the cost to attain a desired capability is the
penultimate decider in aircraft development and purchasing decisions. Cost is normally done
after Sizing, being largely based on the sized empty weight. Cost is also a key measure-of-merit
in design trade studies, where the revised empty weight as calculated in the trade study is used
to determine a revised cost.

These capabilities calculations in RDSwin are based upon the methods described in Raymer's
textbook, Aircraft Design: A Conceptual Approach. Inputs are defined in grids, similar to the
functional analysis grids described above.

Sizing & Mission Analysis


Sizing is the process of calculating the required takeoff gross weight of a new design to perform
some given mission. Mission analysis determines the range capability of a design (new or
existing) where the design takeoff gross weight is known and unchangeable. Both are done in
the Sizing & Mission Analysis Module. Both rely on data in the Aircraft Data File, so it must be
fully defined before the Sizing and Mission Analysis Module can be used.

A new mission profile is created by selecting the mission segments that form your mission. When
you are done selecting mission segment types, RDS displays an input grid of your selected
mission segments. You then enter the required mission input values, such as cruise range,
altitude, etc. When the mission is fully defined, save it (filename extension DMS) then select Do
Analysis. This will be presented in your current choice for List and Print, with a summary at the
top followed by a detailed listing of the calculation results.

126
In RDSwin-Pro a detailed mission analysis table is presented at the bottom of the output listing.
This is also saved separately in the RDStemp directory as a spreadsheet file named “(project
name) _MissionTable.xls”. It will be erased when you exit RDS so save it elsewhere if desired.

For most performance and sizing calculations, the input thrust setting specifies the thrust as a
percent of maximum dry or continuous power thrust at that flight condition (0-100%). This is
true of climb, combat, takeoff, and similar calculations.

For the sizing calculations in level flight such as cruise and loiter, the input thrust setting defines
an upper limit, not necessarily the actual value employed. The program finds the required thrust
setting so that thrust=drag at that flight condition. If the required thrust is greater than the
available thrust, RDS will use the input percent of thrust available, and slow the aircraft down
until thrust=drag. Check for this in the detailed list out of the sizing calculations.

Entering Thrust=999% turns on the afterburner of a jet or selects maximum rated power for a
propeller-powered aircraft. This can also be done in the input grid by typing MaxAB or MaxP *.
Entering either of these sets Thrust=999 and causes maximum afterburning or maximum power
thrust to be used, with fuel consumption determined accordingly.

For cruise mission segments you can permit partial afterburning in a jet engine by entering a
thrust setting somewhere between 100 and 999% (such as 900%). RDS will determine the
required part-AB thrust setting and then interpolate SFC between max-dry and max-AB values.
You can also select this by typing ABpart †. This sets Thrust=900 which selects partial
afterburning (jet only).

You can go back to non-AB or maximum continuous power by entering 100 or less, ie., the
percent of power to be used. You can also type Dry or MaxCont‡, which set Thrust=100%.

Experienced users will probably find it easier to enter 999, 900, or 100 or less for throttle setting.
It’s quicker, and you do it often.

Normally you should not use thrust=999 for cruise or loiter. This will light the afterburner and
apply the afterburning SFC, even if full AB thrust is not required. If you wish to “cruise” or
“loiter” at whatever speed maximum afterburning will allow, set thrust=999 and enter a way-too-
high value for speed. RDSwin-Pro will detect an error and will slow the airplane down until
afterburning thrust equals drag.

RDS sizing and mission analysis normally follows an optimal climb schedule between the input
start and ending velocities. This can be turned off in the Options menu, which will cause the
velocity to change linearly from the start to end velocity. If climbing at a constant speed put in
the same velocity for start and end conditions.

*
Or Afterburner, Afterburn, MaximumAB, ABM, MRP, MXP, or MaximumP

Or AfterburnPart, ABP, or AfterburnerPart (not PartAB - as soon as you press P, the input array is Printed!)

Or NonAB, MaxContinuous, MaximumContinuous,, MaxC, MaximumC, Continuous, or Cont

127
Velocities are normally entered as true airspeed or as Mach number. In RDS win-Pro, calibrated
airspeeds can be entered instead and are indicated by using a negative number. When a
"negative" velocity is found, RDS converts the CAS to TAS based on altitude. If CAS is given
for climb or analytical descent, this is redone for each mission step.

RDSwin-Pro can find optimal altitudes and velocities for cruise and loiter. Simply leave them
blank (=0.0), and RDS will find the best values and will also adjust the adjacent climb altitudes
and velocities to "match up" with the optimal cruise or loiter conditions. If you actually intend to
cruise or loiter at very low altitude ("sea level"), you should use some small but nonzero value
such as 200 feet.

In some rare cases the use of best velocity/best altitude routines can prevent convergence in
sizing. This occurs when the next iteration of takeoff gross weight causes a change in optimal
altitude, which then reverses the last change in takeoff gross weight for the next iteration. In
effect, an infinite loop is set up, not by the coding, but by the physics of the aircraft, the mission,
and the speed/altitude optimization. In such a case, the best solution is to find and input the best
velocity and altitude using the Performance Module. Also, changing sizing sensitivity as
described below may permit convergence.

RDS also checks to ensure that your input speed is neither below stall speed at that altitude, nor
above maximum speed at that altitude and power setting. If either is found, RDS attempts to fix
it by changing velocity.

This capability can be used to define cruise and loiter speeds by power setting. Input the desired
power setting (such as 80%), and give it a speed higher than reasonable (such as 500 kts for a
propeller-powered aircraft, or M1.0 for a jet transport). RDS will "fix it" to the highest velocity
possible for that power setting, altitude, and vehicle weight. Do not give a ridiculously high
speed, such as Mach 5, because it will take longer to converge and may not even be able to find
an answer.

Caution - if you tell RDSwin-Pro to search for best altitude but specify the velocity, it is possible
that the aircraft cannot fly at that speed at any altitude. RDS win may flag this as an error, or may
be so confused that it returns a ridiculous answer. Check the printout.

RDSwin-Pro also permits specifying a cruise-climb rather than cruising at a constant altitude. As
with many RDS options, this is done with a negative input, namely for cruise altitude. The cruise
will start at that altitude and during the cruise, climb keep CL constant.

To perform fixed takeoff weight mission analysis you must define a mission as above, then
indicate one or more cruise or loiter mission segments as variable in length or duration. This is
done by “yes” for the column position labeled VaryRange or VaryTime. When you select Do
Analysis, RDS will then hold the aircraft takeoff weight constant and will vary the range or loiter
time of all mission segments so indicated until the solution converges, then will print out the
resulting range and loiter times.

128
The Sizing & Mission Analysis Module includes the use of a range credit for climbs and descents.
In the case of climbs, the distance required to perform the climb is calculated, saved and
subtracted from the next cruise segment.

Descent fuel burn and range credit depend largely upon pilot technique – the pilot can chop all
power and dive down abruptly, or slightly reduce power and descend gradually over a long period
of time. There are two methods of defining a Descent Mission Segment in RDS. Usually the
simple method for defining a Descent Segment is adequate since the descent fuel consumption is
normally small (mission segment weight fraction is nearly 1.0). The user just inputs a historical
mission segment weight fraction and a range credit distance, which is subtracted from the
requirement for the preceding cruise segment’s range. A three (3) degree descent profile at cruise
speed is commonly used, so the descent range credit can be estimated as the altitude lost divided
by the tangent of three degrees.

The better method is labeled Descent Analysis, and requires inputs for throttle setting, descent
speed, extra drag for speed brakes, etc. This method then calculates the descent rate, the range
credit for descent, and the mission segment weight fraction.

In RDSwin-Professional, if the descent speed is given as zero (0), RDS will determine best descent
speed to maximize descent range. In most cases however, the pilot will descend at about cruise
speed (but slowing as needed to keep speed under 250 kts when below 10,000 ft, as per air traffic
regulations).

Another option in RDSwin-Pro is to specify a descent rate, whereupon RDS adjusts throttle setting
as required. This is specified by inputting the desired sink rate Vvertical (fpm or mpm) in the
throttle setting box, as a negative number.

The set aside for “reserve and trapped” fuel is handled in a landing segment. If you have no
landing segment, such as for a UAV with parachute recovery, you should include a landing
segment anyway or RDS will not include a reserve and trapped fuel allowance. Give a Mission
Segment Weight Fraction of 1.0, then enter the desired reserve&trap allowance (6% is normal).

One source of potential confusion in defining mission inputs is the use of external dropped stores,
such as bombs for a fighter. These are "dropped" in the mission definition by providing a
"Weight Drop" mission segment, indicating the weight dropped and the number of stores
dropped. The weight dropped is the TOTAL weight dropped at that point in the mission, and is
not multiplied by the number of stores you have input. When the sizing analysis reaches this
point in the mission, the aircraft weight is decremented by this total weight. The Wo value in the
Aircraft Data File must include this to-be-dropped weight.

The value you input for number of stores is used to calculate the extra drag of the external
dropped stores before they are dropped. This number, times the D/q per store value you stored
in the Aircraft Data File, is added to the parasite drag for all mission segments before the weight
drop segment. In other words, droppable stores drag (D/q per store) is entered in the first array
of the Aircraft Data File (.rdsDAT), and the mission file merely indicates how many external
stores are dropped along the mission.

129
Thus, to properly handle internal weapons being dropped you just need to decrement weight by
the total weight dropped, using a Weight Drop mission segment weight fraction. Your takeoff
weight must have included the weight of the stores being dropped. However, if those stores are
carried externally you must do two additional things. First, you must define the additional drag
per store in the column D/q per store in the Aircraft Data File, then you must include the number
of stores being dropped in the Weight Drop mission segment along with the weight dropped.

There is a way to “trick” RDS which is sometimes useful for missions and trade studies involving
external stores. When RDS encounters a value for the number of dropped stores and does NOT
find stores D/q in the Aircraft Data File, it assumes a D/q of one. In other words, the value input
as number of dropped stores is assumed to actually be the stores drag area (D/q) and is added to
the aircraft drag on all mission segments before that Weight Drop mission segment. So, you can
put actual stores drag area (D/q) directly in the mission file in the "number of dropped stores"
entry, and not bother putting it in the Aircraft Data File. Note that the number of external stores
does not have to be an integer value.

Two caveats must be noted if you are using this “trick” – first, this assumes that stores D/q does
not change with Mach number. If you want to input drag variation with Mach number you must
do it the “real” way, by entering a D/q table in the Aircraft Data File. Another caution – if you
later decide to include stores D/q in the Aircraft Data File, RDS will multiply those values times
the number in the Weight Drop mission segment to calculate total D/q. You must change the
method in both places.

While confusing at first, this convoluted method gives great flexibility for dealing with all sorts
of external and internal stores carriage with a minimum number of additional inputs.

In some rare cases involving "out-and-back" missions, the climb and descent range credits can
cause problems. For example, RDS was used to calculate the range of an L-1011 launching the
Orbital Sciences Pegasus booster. This mission involves a steep climb to launch the booster, just
before beginning the return to base. RDS tried to apply the range credit for the climb to the return
range! In such a case, a "Weight Drop" mission segment can be used to indicate the turn-around
point, canceling all range credits prior to the turn-around point. This can also be used for the
case where, for some reason, the customer requirements specify that no range credits may be
taken.

Alternative Drag Polars in the Aircraft Data File can be used for mission or performance
calculations when the drag polars determined from the stored C D0 and K would not reflect the
aircraft configuration. This could be, for example, when an airliner has flaps deployed for climb
or descent, or when an aircraft with a variable sweep wing has it swept at an angle other than the
assumed baseline. Up to seven alternative drag polars can be used, and are entered and stored as
paired columns of Cl and CD in the first Aircraft Data File input grid.

To use alternative drag polars which have been stored in the Aircraft Data File, enter the drag
polar number (1-7) at the item "AlternatePolar#" in the Performance input grid or in the Mission
file in Climb, Cruise, Loiter, or Descent Analysis segments.

130
Cruise and Loiter Stall Margins in RDSwin-Pro provide a velocity margin for stall during Mission
Sizing. If the stall margin is not met, an error {C L>CL-max usable} is generated. Also, stall velocity
margins are checked when determining best speeds and altitudes for cruise and loiter. Stall
Margins are input as percent of velocity in Options-Sizing Parameters, and are saved with the
mission. If you are having problems associated with stall, especially when RDS is determining
best cruise or loiter conditions, you may wish to specify a greater stall margin.

Another feature in the RDSwin-Pro Options menu allows you to specify a headwind for your
mission, which is applied to Cruise, Climb/Accelerate, and Descent Analysis types of mission
segments.

Sizing Sensitivity tells the sizing routine when the calculated gross weight is close enough to the
“guess” gross weight, and can be changed in the options menu. Using a value of, say, .001
rather than the default of .0001 will speed up execution especially for trade studies, and may
also avoid the rare occurrence of an infinite loop in sizing analysis. However, the sizing results
may be slightly off because RDS will accept convergence when the calculated W 0 is still
significantly different from the “guess” value of W 0.

In RDSwin-Professional, sizing accuracy can be improved by letting RDS automatically break the
mission into small steps. Naturally, this slows down the sizing calculation, so use it sparingly.
These settings are saved when you exit RDS, so it may be wise to check them before running
sizing.

RDS by default uses the ICAO Standard Atmosphere. It is possible in RDS win-Professional to
use another atmosphere such as polar or tropical. This is done by creating an atmospheric table
in a text file. This is described in the included file RDSATMOS.TXT. After creating one or more
alternate atmosphere files you can select the desired one in the OPTIONS menu of the Sizing and
Performance modules. Note that selecting another atmosphere table only changes the
atmospheric data. It does NOT automatically change your engine thrust and SFC data! You must
provide the revised engine data. As a common approximation, you can instead use the standard
day engine and atmospheric data and simply do the analysis at a higher altitude where the air
density matches the desired Hot day sea level value.

In some cases you’d like to know if your as-drawn aircraft can attain a certain range or loiter
time, not by resizing, but by simply adding fuel without regard to any effects on takeoff distance,
landing gear loads, or other such problems. This is equivalent to “sizing” the airplane without
changing empty weight. Empty weight resizing can be disabled in RDS by setting We Coeff C=-
1 in the Aircraft Data File. When that is set, the increase in TOGW during the sizing analysis is
all fuel. Also, the wing area and engine size are fixed rather than scaled to hold T/W and W/S
constant. This analysis is suitable for off-design, overload analysis, but this is NOT a proper
“sized” result. Instead, setting C=-1 is like putting extra gas into an airplane on the flight line,
exceeding maximum design takeoff weight but flying it anyway. Be careful!

RDSwin-Professional allows trade studies to be performed in several ways. For mission and
performance trades such as cruise range or takeoff distance, you can always simply change the

131
appropriate input value and rerun the analysis. Write down the answers and use them to make a
graph of the changed input value versus the results, such as range versus takeoff gross weight
(ExcelTM is a great tool for the graphing, or you can make any graph in RDS and select R to revise
the data, then enter all new labels and data).

For trade studies involving aircraft characteristics such as SFC or parasitic drag, trades can be
done simply by modifying the Aircraft Data File. Each data input grid such as C D0 or thrust can
be modified by addition or multiplication of input grid data by an input constant (one of the
commands at the bottom of each array in the Aircraft Data File). You can apply this to the entire
array, or for a more sophisticated trade study, apply a constant to individual rows, columns, or
data items. For example, you could use this method to do a drag trade study of an arbitrary
increase in supersonic CD0 without a change in subsonic CD0.

Trade studies can also be done by making changes in the inputs of the Aerodynamics, Weights,
and Propulsion Analysis Modules, running Do Analysis to create a new Aircraft Data File, and
using those results to rerun Sizing and Performance calculations.

RDSwin-Pro automates a number of the commonly used trade studies, making the parametric
change to the selected input, rerunning the analysis, and graphing the results immediately. In the
Sizing and Mission Analysis Module, automatic trade studies include variations in parasite drag,
drag due to lift, specific fuel consumption, dead weight, range, and payload weight. For each
parametric variation, the aircraft is resized and the resulting aircraft gross and empty weights are
stored for graphing. For range trades you must first indicate which cruise mission segments are
to be varied in range by indicating “yes” for Vary Range as described above. This is also required
for a range-payload trade, which is done holding the aircraft at a constant gross weight and
determining the change in range as payload weight is increased and decreased.

In some cases you may wish to do a trade study which is different from the RDS win -Pro “canned”
trades. These you must do as described above, by changing the appropriate inputs and parameters
in the analysis routines and/or Aircraft Data File, running the Sizing and Performance
calculations, and making a graph from the results.

RDSwin-Pro trade study graphs can be produced with Cost as the measure of merit rather than
weight. This option is prompted for after the weight-based trade study graph is shown.

132
figure 59. Sizing Trade Study

Performance
RDSwin instantly calculates all the commonly-used performance criteria such as rate of climb and
takeoff distance. Some of these are shown in graphical form whereas others are output in detailed
text files, shown using the current List and Print option. Performance analysis requires that an
Aircraft Data File be open and fully defined as described above.

Performance analysis graphs are selected from the Analysis pulldown menu, including Flight
Envelope, Range Optimization, Rate of Climb, fs Calculation, Ps & Turn Rate, and V-n diagram.
These also appear as options when you click on the Performance button on the main screen
flowchart. You don’t need a Performance analysis file for these graphs, only an open Aircraft
Data File.

When a performance graph is requested, RDSwin offers a pick menu to change the parameters
used to create the graph. Normally, the defaults are fine. Then the performance graph is created,
such as the Rate of Climb graph shown in figure 60. For explanations and raw data, Exit Graph
then View - List and Print – List Last Results.

133
figure 60. Rate of Climb

Other performance calculations require more inputs which are defined in a Performance input
file (.rdsDPA). These include Takeoff, Landing, Acceleration, Ps, Turn, and Climb performance.
You create a new Performance input file much like you create a Mission file - first you pick the
columns by type, then you enter the data in an input grid. The options are shown below, and you
can have more than one of each type.

Note that Performance calculations are all independent whereas a mission model is in time
sequence, with weight determined by the previous segment calculations. The order of
performance columns has no effect on the results since the weight is defined by the first entry in
each column.

When you are done selecting performance calculation types, an input. Typical default values are
provided for many parameters. Explanations of the inputs are found by clicking on the column
titles, and are described in detail in Raymer’s textbook.

Complete all inputs, then select Do Analysis. Results are displayed in the current List and Print
option.

134
One parameter has a big effect. The ratio Wi/W0 is the aircraft weight at which you wish
performance to be calculated, divided by the aircraft takeoff weight. Performance may be
calculated at the design takeoff gross weight (Wi/Wo=1), or at some arbitrary weight ratio such
as 0.8. You can also enter an actual weight here, such as 10,000 kg.

If you wish to calculate performance at some specific point in your sizing mission, go to the
sizing analysis results to find the actual weight ratio at that point and copy that Wi/Wo into the
Performance input grid. Or, read the actual aircraft weight at that point in the mission and enter
it for Wi/Wo.

This is not recommended if you plan to do carpet plots or optimization in RDS win-Pro because
the actual weight Wi or the ratio Wi/Wo may change during the optimization.

Instead, RDSwin-Pro can do this automatically. Instead of entering a ratio Wi/Wo you can provide
the number of a mission segment after which the performance calculation should be done. This
is indicated with a negative number. For example, setting Wi/Wo= -5 would indicate that you
wish RDS to use the aircraft weight at the end of the fifth mission segment, as calculated the last
time that the aircraft was sized. This ensures that the performance will be calculated based on the
correct weight during the mission. When running optimizations, sizing is always done just before
performance analysis so that the latest calculation of Wi/Wo is available.

A few specific comments: Takeoff and Landing calculations are done the “hard way” with full
integration of thrust, drag, and rolling friction. For takeoff, the Balanced Field Length calculation
iterates to find the Decision Speed, and has another iteration loop to find the best liftoff speed
considering distance to clear the obstacle.

Some data items for Takeoff and Landing have an asterisk (*) in the label. If these items are left
blank, the appropriate values from the Aircraft Data File Weights & Misc array will be used
instead. If those items are zero there too, then zero will be used. Be advised! This option allows
the same performance input grid to be used for several different aircraft designs, without having
to revise these items.

The Ps & Turn Rate calculation is done at one specific altitude and velocity, unlike the similar
Performance graph in which Ps and Turn Rate values are calculated for the entire flight envelope.
This calculates everything you’d want to know about the aircraft’s performance at that speed and
altitude, including maximum instantaneous turn rate, available rate of climb, and Ps at a sequence
of load factors up to the maximum.

The option for Engine-Out in the Ps & Turn inputs allows calculation of engine-out go-around
and similar requirements. The “Extra Delta Cd” entry can be used to add gear and flap drag.

In RDSwin-Pro the performance input grid has, at the bottom, entries for Required Values and
their associated Requirement Codes, as listed below. The required values are printed with the
performance analysis results for comparison of goal to actual. More importantly, they are used
in the RDSwin-Pro Carpet Plot and Optimization Module as the optimization constraints. Carpet

135
Plots will show the line where the selected design variables produce an aircraft that exactly meets
each of these required values. In the Multivariable/Multidisciplinary optimizations, these
required values will constrain the design space so that the resulting optimal design meets or
exceeds these required values.

Required Performance Parameter Codes:

Takeoff: 1=GroundRoll 2=Total Distance 3=FAR25 4=Balanced Field


Landing: 1=GroundRoll 2=Total Distance 3=FAR25 4=No Flare Distance
Ps&Turn: 0=InstTurnRate 1=Rate of Climb
>1 is load factor n for required Ps value
Accel: 1=Time 2=Distance to Accelerate
Climb: 1=Time 2=Distance to Climb

Cost Estimation
Development and procurement cost analysis is done using a modified DAPCA-IV method, from
an RDSwin input grid (filename extension DCA). Its input grid is similar to the other RDS
analysis modules’. To calculated costs in other than 1999 dollars, enter an economic escalation
(inflation) factor, defined as “then-year-dollars”/1999 dollars. Also, hourly rates for engineering,
production, etc. should be entered in then-year dollars.

Results can be converted to other currencies – see Options-Currency. 16 common international


currencies plus the emerging Bitcoins are included in RDS data file
RDSresource\RDSCostC.RTX, and others can be added. You should update the exchange rates
found in that file – these days, rates change often! Directions are on the pulldown menu.

DAPCA tends to underestimate costs for new-generation fighter aircraft, so a “DAPCA Fudge
Factor” of 1.25 is recommended. On the other hand, DAPCA seems to over predict transport
aircraft costs so a fudge factor of 0.9 is recommended.

DAPCA was not developed with general aviation aircraft in mind, but some users report that
DAPCA with an overall fudge factor of 0.25 gives useful results. This seems very crude, but
perhaps the exponents of the equations are reasonable even if the constant terms are far off.
General aviation cost estimates should be calibrated by use of actual data for a similar aircraft to
create a DAPCA Fudge Factor suitable for your design.

For an aircraft with composite materials, a Materials Fudge Factor of 1.5 was historically
recommended. Today, perhaps that factor should be 1.0 or even less. Opinions differ.

An “Investment Cost Factor” of 15% is typical. This includes the contractor’s cost of borrowing
or using money as well as contractor profit.

There are two ways to define engine cost in this module. If engine cost is known, enter it directly
in the appropriate place as cost per engine. If engine cost is unknown, RDS will estimate it from
inputs for thrust, maximum Mach number, and turbine inlet temperature. If this estimate is being

136
used, leave engine cost blank to tell RDS to calculate it using the inputs. For a piston-propeller
aircraft, you must enter engine cost – RDS has no estimating method.

Life Cycle Cost and Airline Economic analysis are calculated by yearly accumulation of costs
based upon user inputs, adjusted for the inflation rate. These inputs are defined in the input grid
based upon concepts in Raymer’s textbook.

137
ROAST - TRAJECTORY ANALYSIS & FLIGHT SIMULATION

figure 61. ROAST Instrument Panel During Trajectory Script Operation

Introduction
ROAST is the flight simulation and launch trajectory analysis module of the RDS win aerospace
vehicle design software. ROAST is a user-friendly tool for calculating vehicle performance over
trajectories for which closed-form equations are not suitable, and determines what an airplane or
aerospace vehicle will do in response to various control inputs from an initial starting speed and
altitude. It also determines speeds and altitudes that can be reached with a given amount of
fuel/propellant, following a commanded control scheme. ROAST is only available in RDS win-
Pro.

The program outputs an extensive table detailing the simulation second-by-second, including
speed, altitude, angle of attack, flight path angle, dynamic pressure, distance, weight, fuel burn,
and more. ROAST also graphs the results including altitude vs. distance, velocity vs. time, and
many more. An included spreadsheet file allows using ROAST results to produce standard
Microsoft Office graphs, if preferred.

ROAST is intended for initial design analysis and conceptual trade studies of aerospace vehicles,
primarily aircraft. It can also be used for launch vehicle analysis, but it isn’t nearly as detailed or
accurate as the iconic POST and OTIS programs commonly used by the government and
contractors. These determine a launch trajectory and fuel burn with enough accuracy to launch
the Space Shuttle, but their sophistication and setup time make them problematic for early
concept studies. ROAST, by comparison, is a 2-D, flat-Earth model that is quick and easy to use.
It doesn’t have the sophisticated setup and mathematical optimization methods of those high-end
codes, although in comparison studies ROAST matched POST reasonably well for simple
trajectories.

ROAST is an integral module of RDSwin, optionally compiled into the main code and using the
same user interface, input grid, graphing routines, and data output. The name ROAST stands for
“RDS Optimal Aero-Space Trajectories,” or it can be humorously interpreted as “Raymer’s
POST Approximation” (delete the P and move the A).

138
ROAST was originally developed to analyze the Lockheed L-1011 for pitchup and pushover
trajectories. Later ROAST was expanded and configured for vertical launch, with an iterative
routine that finds the required flight control to attain a desired burnout trajectory angle. Now it
has been fully integrated into RDSwin, with capabilities far beyond those early implementations

Note that ROAST is not a stability and controls simulation. ROAST “deems” the vehicle to be
under control, and explicitly sets its angle of attack after consideration of user inputs, commanded
targets, and limitations such as maximum load factor, stall, and pitch rate limits. Even when at
an angle of attack that would produce a stall, and even at an altitude where there is insufficient
dynamic pressure for aerodynamic control, ROAST assumes that somehow the vehicle can be
controlled and set to whatever angle of attack is needed. The user should check the trajectory
printout to make sure that it has not entered an uncontrollable situation.

ROAST Data in RDSwin Modules


ROAST is called from and integral to RDSwin. The vehicle data required by ROAST is defined
and stored in the RDSwin Aircraft Data File, containing the design’s calculated CD0, K, CL-max,
installed engine thrust and specific fuel consumption, and other sizing inputs such as key weights
and allowable load factor. Data for the Aircraft Data File can be calculated elsewhere and directly
typed in, thus skipping the other modules. Normally, though, the Aerodynamics, Weights, and
Propulsion Modules are used to analyze a design and load the appropriate data into the Aircraft
Data File. Once the Aircraft Data File is properly created, by whatever means the user prefers,
its data can be used in ROAST as well as the Sizing & Mission Module, and the Performance
Module.

The analysis modules of RDSwin were originally developed with aircraft in mind, but can be used
for a wide variety of vehicles including exoatmospheric. The Aerodynamics module uses
classical methods for subsonic, transonic, and supersonic flight. For hypersonic speeds, RDS win
includes a Newtonian method for lift and drag. This tracks well with the characteristics of normal
vehicles such as the X-15 or Space Shuttle. It requires input of total planform area in the ROAST
input grid, including projected areas of fuselage and tails.

Alternatively it is easy to enter aerodynamic characteristics calculated elsewhere into the


appropriate RDSwin arrays. For a launch vehicle without wings, the body frontal area is commonly
used as the reference area, or a unit value can be used (thus drag coefficients are actually drag
areas, D/q).

The normal RDS propulsion analysis includes installation analysis of thrust and specific fuel
consumption for jet engines. It is also possible to simply type in the thrust and fuel consumption
into the appropriate table in the Aircraft Data File. Note that if your thrust table does not have
values at lower speeds and those speeds occur during the simulation, the thrust will suddenly
drop to zero. Don’t blame ROAST!

For rocket rather than airbreathing engines, there is a special interpolation routine for direct input
of rocket thrust and Isp. This is an option when going to the Propulsion Module. Propulsion

139
values are loaded directly into the Aircraft Data File, interpolated proportional to atmospheric
pressure from just four inputs - Sea Level and Vacuum values for Thrust and Isp.

To be consistent with RDS jet aircraft terminology and calculations, rocket Isp values are
normally converted and stored as specific fuel consumption (SFC=3600/Isp in fps units).
However, the SFC data can be viewed and edited as Isp if desired. See Tools-Aircraft Data File
to select this option, or simply press 'I' when in the Aircraft Data File.

For an ullage-pressure-fed rocket engine, the thrust and Isp are reduced as the propellant is used
because of a reduction in usable blowdown pressure. ROAST provides an adjustment for this
(see below) so it is not necessary to enter data at different propellant levels. Bottle-pressure-fed
systems don’t experience these reductions but have additional weight and complexity.

Weights methods in RDSwin are statistical and require significant adjustment to properly
represent launch vehicles. RDSwin does make it easy to make such adjustments or to simply enter
the required weights information (Wo/GLOW, Wempty, fuel/propellant weight, etc…).

The RDSwin Cost Module is airplane-based. Using it for spacecraft would require suitable “Fudge
Factors” developed specifically for that class of vehicle. In other words, the exponents of the
equations may be useful, but the constants need to be adjusted and/or calibrated.

ROAST Methods and Assumptions


ROAST is a time-domain simulation of an aerospace vehicle trajectory based largely on the
equations and methods in the books by Sutton, Bate, Griffin, and Koelle. ROAST works both in
and out of the atmosphere and can handle powered, unpowered, glide, and landing phases. It can
be used for multi-stage launch vehicles and can also set aside propellant for an orbit
circularization burn.

ROAST starts at the altitude, flight path (climb) angle, and velocity as entered in its Input Grid
(see below), then follows the vehicle through a timestep integration of F=ma at quarter-second
intervals until the altitude becomes negative or the MissionTime is exceeded. Then, a graph of
altitude vs. downrange distance is presented. After viewing this summary graph, other options
for graphing the data or displaying a full output in spreadsheet format are offered.

While ROAST analysis is 3-DOF and thus essentially two-dimensional, the important three-
dimensional effects are included as analytical adjustments. A centrifugal force calculation is used
to include the effects of orbital speed and to determine when orbit has been reached. Gravitational
force is adjusted for altitude. The launch site latitude and launch direction are taken into account
using an Earth rotational speed contribution. Re-entry S-turns are permitted using a lift vector
projection method.

140
figure 62. Typical Trajectory Graph

The vehicle is first defined in the Aircraft Data File of RDS win, consisting of propulsion tables,
aerodynamic lift and drag data, and top-level weights including gross (GLOW), empty, and fuel
(propellant). This data can be typed in to the appropriate data arrays, or can be created by other
modules of RDSwin.

There are limitations and assumptions in the use of the Aircraft Data File that relate to ROAST.
The regular Performance Module calculations in RDS win are limited to about Mach 5. ROAST
has no such limitation, and will apply a Newtonian analysis for extreme speeds. Similarly,
RDSwin normally calculates performance within the provided speed and altitude range of the
engine thrust data. ROAST will extrapolate beyond the data provided – be careful!

Remember that RDSwin tests on {T/W > 2} as an indication that instead of T/W and W/S, the
user has provided actual thrust (T) in units of force (per engine) and wing area (S) in units of
area. Therefore, an aircraft or launch vehicle with thrust more than twice the takeoff weight must
have its thrust input as force (T), not ratio (T/W), and the wing must be input as (S), not (W/S).

The standard atmosphere model cuts off at 150,000 feet. ROAST extends this to space, but past
150,000 feet this has little effect on performance. Mach number calculations at extreme altitude
are largely irrelevant, and may jump around.

Stores Drag data placed in the Aircraft Data File will always be used by ROAST, so if it isn’t
appropriate, those values should be zeroed. The Stores Drag data table might be useful for the
drag of an externally-carried upper stage, or that drag could be included in the basic drag of the
air vehicle.

141
Like all such programs, ROAST has internal assumptions and “magic” parameters. Examples
include the stall margin on maximum lift coefficient, or the altitude at which pitchover begins
during a vertical launch, or the radius of the sphere used for the Chapman Heating calculation.

These built-in ROAST assumptions and parameters are stored in the RDSresource file
RDSwinParamsROAST.RTD along with brief explanations. They can be changed if desired. This
is NOT recommended, and you do so at your own risk! If you do, the file must be saved as a
simple text file (not Word document), and must have exactly the same name. Save a backup copy
before you make changes.

The parameter file includes a limitation on the rate at which angle of attack can be changed,
namely 10 degrees per second. This makes the simulation more realistic. Several landing analysis
parameters are also included (see below).

Coordinate System
ROAST uses a modified Stability Axis System with X in the flight direction and Z upwards and
perpendicular to X. Forces and accelerations are calculated in those directions and the change in
velocity is determined at each quarter-second time interval.

Resulting position and velocity are defined in a flat-Earth


coordinate system in which X is downrange distance and Z
is altitude above mean sea level. The vehicle is shown as
flying from left to right, so that the resulting graphs will
show positive values for downrange distance. For vertical
launch the picture appears as if you are south of the launch
site and viewing an easterly launch. Climb path angle
Gamma (Γ) is defined such that zero is horizontal to the
right, and 90 degrees is vertical.

There are two options for vehicle orientation. For normal


aircraft flight the orientation is upright, with positive angle
of attack tending to increase climb path angle. For vertical
launch, the vehicle can be rolled on its back like the Space
Shuttle so that a positive AOA takes it downrange. After
burnout the vehicle can be rolled upright for reentry and
landing. This is automatically done for normal ROAST
launch guidance options. For Trajectory Script and Real-
Time User Control (see below) the user has to make it
happen, or use a negative AOA to go downrange.

142
figure 63. Vehicle Flight Orientations

Input Parameters
ROAST is selected from the main RDSwin pulldown menu or by clicking on the ROAST box at
the bottom of the page. This brings up an input grid which allows definition of various parameters
and options. Input grid operations and hot keys are described in the main RDS win user’s manual.
Pressing “#” toggles between fps and mks units. Pressing “H” brings up on-screen help,
especially hot key descriptions. Clicking on a data column heading brings up help specific to that
column, including required units for the various items.

figure 64. ROAST Input Grid

Data entry in an RDSwin input grid can be done as an expression rather than a single number, and
many typical aircraft abbreviations are supported. For example, to enter initial Altitude as 50 nmi
rather than the expected feet, you can enter it as 50*6076. You can also enter altitude as flight
level even if you are using metric units at the time. FL100 will be converted to 3048 meters
which, upon pressing #, is converted to 10,000 feet.

The ROAST input grid has four columns of data. The first column defines Start conditions (t=0)
including initial altitude, flight path angle (gamma), and velocity. For aircraft this is typically
some speed and altitude, with zero flight path angle. For a vertical launch use V=0,
FlightPathAngle=90, and the appropriate Altitude. The velocity input here must always be in fps
or mps, not Mach number, kts, or km/hr as permitted in the RDS Performance Analysis Module.
You can use Tools-StandardAtmosphere to find the exact speed of sound at that altitude and
enter, say, Mach .8 as 0.8*994.66 (speed of sound at 30,000 ft).

143
V-EarthRotate is the contribution from the Earth's rotation in the launch direction. At the equator
this is 1526 fps (465mps). This reduces by the cosine of the latitude so at KSC in Florida, the
Earth provides 1340 fps (408mps) of rotational velocity (Eastward launch). For a polar orbit there
is no rotation contribution regardless of launch point. Skip this for aircraft analysis – most of
them are too slow for this to have any measurable effect!

The parameter nLaunchPullup is for air-launched designs such as SpaceShipTwo. If greater than
zero, this parameter tells ROAST to do a pull-up immediately after launch, and the given value
is the initial pull-up load factor (if permitted by stall and/or thrust). This pull-up continues until
the desired starting boost flight path angle (gamma) is reached, input as PullupEndAng (~30 deg
for the OSC Pegasus, which features a large wing just to do this initial pull-up). If the pull-up
lasts longer than 60 seconds, ROAST assumes something is wrong and stops trying. This can
occur if the launch speed is too low, or the wing loading is too high, or the thrust isn’t great
enough to allow the initial climb.

The second column in the ROAST input grid defines the Guidance Method. The first entry is the
chosen launch guidance method, selected from an options menu by clicking on the box. Six
methods are available. Normally the first option is used, in which ROAST iterates to find a
minimum constant angle of attack that reaches the desired trajectory angle at Burnout. This is
usually less than a single degree of AOA, and tends to minimize propellant burn. The next option
uses a constant Pitch Rate which is found to reach the set trajectory angle at Burnout.

For either of these options, the next input item is the desired flight path angle (gamma) at
Burnout. This is normally not level flight (zero) because a good launch trajectory allows the
vehicle to coast upwards long after burnout. A 60 degree burnout angle seems to produce good
results in many cases.

To avoid a sudden turn immediately after a vertical launch, the angle of attack is kept at zero
until the velocity has exceeded 100 fps and the altitude has exceeded 1,000 ft. After that, the
angle of attack for initiation of Pitchover is selected. These limits can be changed by editing file
RDSwinParamsROAST.RTD but this is not recommended. The trajectory when starting at zero
velocity is extremely sensitive to small changes in AOA, and allowing a turn immediately upon
liftoff can prevent ever finding a usable solution. Plus, it would scare the folks on the ground!

The next two guidance options implement user-set values, namely angle of attack (AOA) or pitch
rate (deg/sec). These are entered in the following data box. Be advised that the vehicle will follow
whatever trajectory that your input produces, including loops! Also, there is no target burnout
flight path angle for these options – you get what you get.

The next guidance option, Trajectory Script, causes ROAST to follow the commands found in a
separate Trajectory Script text file which you must first create. The Real-Time User Control
option allows you to "fly" the vehicle using arrows, joystick, and various special commands. This
both take an initial AOA value, and are described in separate sections below.

ROAST allows you to set aside enough propellant to circularize an orbit by inputting the desired
orbital altitude in the next entry box. If this is greater than zero, the delta-V and required

144
propellant to circularize an orbit are automatically recalculated as the program iterates to find the
best AOA or pitch rate, and that amount of propellant is excluded from the boost phase of flight.
The orbit circularization burn calculation assumes that the boost engine cutout point is the perigee
for a coast up to the desired orbital altitude apogee, and the orbital circularization burn then adds
the required velocity for orbit. If multiple stages are used (see below), the orbital burn set-aside
only applies to the final stage.

The next entry item allows defining whether skip-ups are allowed during re-entry or glide and if
not, how the vehicle should respond when a skip-up situation is encountered. When the parameter
“Entry S-turn” is set to zero, the reentry angle of attack is maintained so skip-ups can happen.
Sometimes this is useful, to dissipate heat or to increase range via a “skip-glide.”

If Entry S-turn is set to exactly one, skipping is suppressed and the angle of attack is lowered to
reach level flight (n=1). This continues until enough speed is bled off for descent to resume.

When Entry S-turn is set to a value greater than one, skip-ups are prevented. During re-entry, this
causes the vehicle to enter an S-turn. The input value is then the maximum load factor for level
S-turns to bleed off speed (3 g's for the Space Shuttle). S-turns are not used during the glide
phase, so there Entry S-turn>1 will produce level flight until speed is bled off.

The next two entries define an unpowered landing. LandFlareAlt is the altitude at which a flare
maneuver is begun. LandSinkRate is the target sink rate to be reached and maintained as long as
possible during unpowered landing flare. These inputs and the methods used for the ROAST
landing calculations are detailed below. Note that the landing simulation will not exactly find
your chosen field elevation as the touchdown spot. It doesn’t really matter.

The third column in the input grid defines various vehicle limits that are not already defined in
the airplane-oriented Aircraft Data File. First is the Axial g limit. This is the structural limit in
the thrust direction. Note that Earth’s 1g is included so to allow for a 3g vertical acceleration,
you should enter 4! If this is confusing, think of a rocket hovering. The structure is experiencing
a 1g load, but the vehicle is accelerating at 0g – not at all.

Maximum lateral load factor is already set by Nmax from the Aircraft Data File. The dynamic
pressure limit is also in the Aircraft Data File.

The limit Boost Mach# prevents the vehicle from exceeding the given Mach value, until the input
Altitude Cutoff value is exceeded.

MissionTime is a time cutoff for the ROAST simulation, in hours. Remember that a single orbit
around the Earth takes about 90 minutes, so few missions will exceed 1.5 hours. But, ROAST
doesn’t care if you put in a huge value, and will stop the simulation anyway once the vehicle hits
the ground.

The last input grid column defines various vehicle parameters. First is BaseArea, which is the
total rearward projected area of the engines. This is used for a base drag calculations when the

145
engines are shut down, and must include the area of the fuselage aft-end where the engines reside.
Ignore this if engine-out glide isn’t of concern.

The Reentry AOA is used for Newtonian aero analysis reentry (M>6). A typical value is 40
degrees. Planform Area is the total vehicle top-view planform area, and is also used for the
high-Mach Newtonian lift and drag calculations.

Wi/Wo or Wi defines the simulation starting weight, as a ratio to takeoff gross weight (TOGW
or GLOW) or as the actual starting value. This is normally set to one, ie., all-up weight. If
Wi/Wo<1, some propellant has been burned prior to the start of this trajectory simulation.

FuelMargin% is a percent allowance for fuel flow, typically 1-5%. This can be used for engine
efficiency adjustment or for unusable propellant.

Selecting YES for the PressureFed option causes ROAST to approximate the thrust and Isp
degradation typical of an ullage-pressure-fed engine as its propellant is used. This is caused by
the reduction in usable blowdown pressure. Thrust and Isp are adjusted in a linear fashion from
the as-stored values which assume full tanks, to the empty-tank adjusted values, namely 60% for
thrust and 75% for SFC (=1.33*Isp). Bottle-pressure-fed systems don’t experience these
reductions so leave this option NO for such vehicles.

Multi-Stage
For a multi-stage launch vehicle, ROAST does not define separate “stages” then add them up.
Instead, you define separate “Stacks,” each of which is the TOTAL vehicle at that point. In other
words, for a three-stage launch, the first Stack is a vehicle consisting of stages 1, 2, and 3 together.
The second Stack is stages 2 and 3, and the third Stack is just the top stage.

Each Stack is defined as a separate vehicle within its own Aircraft Data File. To tell ROAST that
there is another Stack, put the text string {STACK#2=filename.rdsDat} in the Aircraft Data File
Notes for the first Stack. If there is a third Stack, put {STACK#3=filename.rdsDat} in the Notes
of the second Stack. Each Stack's cargo weight should be the TOTAL weight of all Stacks above
it, including the final payload.

When the propellant of a Stack is exhausted, ROAST looks for the phrase “{STACK#” in the
Aircraft Data File notes. If found, ROAST reads in the Aircraft Data File for the next Stack as if
it were a separate vehicle which begins flight at the previous Stack's final speed and altitude.

If an orbit altitude is defined in the input grid, propellant is set aside for an orbit circularization
burn, but obviously for the final stage only.

RATO (Rocket-Assisted Take Off)


ROAST can simulate the use of rocket-assisted takeoff, adding its thrust and weight to the values
in the Aircraft Data File. RATO systems are typically strap-on “bottles” that ignite for takeoff or
launch, burn for just a few seconds, and then drop off as the vehicle flies away. The thrust is

146
often angled down significantly, in some cases enough that the vertical component of thrust lifts
the vehicle off the ground by brute force.

RATO in ROAST is modeled as additional thrust, weight, and drag which are added to the vehicle
values in the Aircraft Data File. You do not have to change the Aircraft Data File Wo, T/W, W/S,
or other parameters – ROAST adjusts them automatically. The RATO system is defined by a text
string in the Notes of either the ROAST input grid or the Aircraft Data File *, with the following
exact format:

{RATO: units=fps Thrust=50000 Wf=10000 We=500 BurnTime=4


ThrustAngle=20 D/q=.5

Units can be fps or mks. Weights are in lbs or kg. Thrust is in lbs or kN, and remains constant
throughout the burn. Thrust angle is defined such that a positive angle provides an upward force
component. D/q is “drag area” in sqft or sqm.

Burn time is in seconds. If you prefer, you can provide Specific Impulse (Isp=200), and
ROAST will calculate the burn time. For those rocket scientists who are used to saying
“propellant” instead of “fuel”, you can give (Wp=) instead of (Wf=). Don’t confuse this with
payload weight.

This text string is not case sensitive, Also, it doesn’t matter if the Notes display wraps the text to
the next line, and the order of the inputs in the text string isn’t important.

Don’t be confused - RATO is defined by an entry in the ROAST array, whereas Staging is defined
by a “Stack” entry in the Aircraft Data file. Also, RATO can only be applied at t=o so you cannot
have RATO for other than a first stage.

Unpowered Landing Simulation


ROAST includes a landing simulation for analyzing the approach and touchdown of an
unpowered vehicle. The RDSwin Performance Module calculates landing distance for a normal,
powered aircraft using analytical integration. This isn’t suitable for an unpowered glide landing,
where time-dependent effects are critical and the approach sink rate cannot be specified using
thrust. For a vehicle like the Space Shuttle or the tourist-carrying SpaceShipTwo, the unpowered
landing becomes a critical sizing requirement and can drive the wing to a size much larger than
would be expected just for stall speed. The problem is that as the vehicle flares for landing, it
must not run out of airspeed before a safe touchdown can be accomplished.

*
If you foolishly do both, the definition in the ROAST input grid is used.

147
figure 65. Landing Simulation

For landing a powered aircraft, the pilot will set up a stabilized descent using a power setting that
gives the desired descent angle, usually 3 degrees. Just before touchdown the pilot will smoothly
increase angle of attack, increasing lift to check the descent rate. In the ideal case, the vehicle’s
velocity vector will become horizontal just as the ground is reached – a perfect touchdown.

When landing an unfamiliar or high-performance airplane, the pilot will flare to a small sink rate
and just wait for the ground to hit the airplane. This is the logic normally used for unmanned
aircraft and airplanes with automatic flight control systems, and is used in the ROAST landing
simulation.

There is a problem for a typical winged spacecraft. With no thrust and high drag, it must approach
the airfield at a steep descent angle. During the flare it increases angle of attack to cut its sink
rate to the value that the landing gear can safely handle. It needs to hold that safe sink rate for
about 5 to 15 seconds while waiting for the wheels to “find the ground.” But with no thrust and
high drag it is slowing down rapidly, so it might stall first.

ROAST simulates such a landing, and by plotting V-vertical vs. time for the approach and
landing, you can see how much time is available at a safe sink rate.

148
figure 66. Typical Landing Simulation Results – Vvert vs. Time

The landing routine is always active in ROAST (except for Script or User Control guidance).
ROAST checks altitude and, when it is less than the input LandFlareAlt *, begins the flare. Angle
of attack is increased until the default pull-up load factor (1.5) is reached. The flare continues
until the sink rate is less than the input value LandSinkRate, and then the nose is lowered to hold
that value as long as possible.

The input value LandFlareAlt should be 50-100 feet above the desired touchdown elevation. If
the input value LandFlareAlt is left as zero, the vehicle will reach zero altitude before it barely
begins to flare. This is known as “crashing,” and will be seen in the trajectory printout.

It isn’t necessary to adjust the flare altitude until touchdown occurs at exactly the landing field
altitude. If it is within a few hundred feet of the correct altitude, the air density is close enough
that the results are usable.

The LandSinkRate value should include a structural safety margin. Since loads are proportional
to energy, a typical 1.5 factor of safety should be squared. If the maximum sink rate is 12 fps, the
target or nominal sink rate should be 5.3 fps. Note that this logic is debatable – consult with your
experts as to the desired target landing sink rate including structural margins.

There are four landing-related parameters in RDSwinParamsROAST.RTD. These include


ApproachAGL, the altitude at the start of the transition to approach speed (default=500 feet), and
the related ApprPullupN which defines the pull-up load factor during transition to approach speed
(default=1.5). If this is set to a crazy-high value such as 100, the pull-up is always done at C Lmax

*
ROAST automatically adds 50 feet to flare altitude to take into account the time lag when increasing angle of
attack as a result of the pitch rate limiter.

149
for maximum performance. ApprStallMarg defines the stall margin at landing approach speed
just prior to flare (normally set to 20%, ie., 1.2). ApprNpushover is the load factor used when a
pushover is required because the speed has dropped or the climb angle has become positive
(default=0.6666).

ROAST Results and Outputs


Once the inputs are properly defined and the Aircraft Data File is complete, ROAST analysis is
selected by clicking on the Do Analysis box, by pressing “A,” or by choosing Run Analysis from
the Analyze tab of the pulldown menu. If one of the first four guidance methods are being used
(AOA or Pitch Rate) the simulation is run at computer speed which is virtually instantaneous,
and the results are immediately presented. When the guidance method is Trajectory Script or
Real-Time User Control, the simulation is run in real time until the user presses ESC whereupon
it is instantly finished at computer speed.

After the simulation is completed, a graph of altitude vs. downrange distance is presented. When
ExitGraph is selected, the following display options are offered:

 Return to InputGrid
 Show Results in your Spreadsheet
 Show Results in current ListAndPrint Option
 Altitude vs DownRangeDistance
 Velocity vs DownRangeDistance
 V-vertical vs DownRangeDistance
 Altitude vs Time
 Velocity vs Time
 V-vertical vs Time
 DownRangeDistance vs Time
 DynamicPressure vs Time
 q*alpha vs Time
 Altitude vs Velocity
 Altitude vs V-vertical
 Altitude vs DynamicPressure

The table of ROAST simulation results is best viewed in your computer’s spreadsheet program
(Excel, for most of us). It can also be displayed using your current ListAndPrint option. RDS win
lets the user select any of six different displays, including a text Console, a pop-up box, or your
computer’s Word Processor, Spreadsheet, or Web Browser (with or without background image).
This can be selected in File-ListAndPrint.

The table of simulation results starts with 31 lines of background information including the data
files used, the simulation starting conditions, various input parameters, and information about the
aircraft or launch vehicle analyzed.

150
The actual simulation results begin on line 35. While ROAST does its calculations at quarter-
second intervals, the results are shown at one-second intervals to keep the table manageable in
size. The data columns list the Time, Altitude, Range, Velocity, M#, AOA, Gamma (flight path
angle), PitchRate, V-horizontal, V-vertical, Weight, Fuel weight, Thrust, Drag, Lift, n-lift (load
factor due to lift alone), nX-Acceleration, nZ-Acceleration, q (dynamic pressure), q-alpha, Delta-
V, EnergyHeight, and Chapman Heating (1 ft radius sphere). At the far right of the data rows are
notes such as Flight Phase or Trajectory Script actions.

At the bottom of the trajectory listing are summaries, maximums, and other information such as
propellant set-aside for orbit circularization.

The display options listed above after “Show Results…” are all graphs, which can be saved or
copied to the clipboard. You can also save the graph data (Ctrl-S) and use some other graphing
program to make “prettier” graphs.

Another graphing option uses the spreadsheet file RDS-win_ROAST_data_graphs_.XLS which


is included in the RDSresource folder. As it says on its Instructions, select "Do Analysis" to run
the trajectory, then select "Show data in your Spreadsheet." Copy the entire resulting worksheet
into the Data worksheet using Edit-PasteSpecial-Values (not Ctrl-V). Delete all rows after the
last analysis data row, starting with the row near the bottom saying "Time Altitude Range...."
Then you can view the graphs on the other tabs, and copy or link them in to other Windows
applications. It may be necessary to change the graph extents, and you may wish to create other
graphs from the raw data.

ROAST Trajectory Scripts


ROAST has a unique capability for guidance which allows the user to design a trajectory then
watch the vehicle follow it. Normally ROAST finds and follows an optimal pitchover from
launch to a target climb path angle at burnout, using a constant angle of attack or pitch rate.
Trajectory Scripts allow vehicle guidance by setting triggers of events, after which certain flight
controls such as angle of attack and throttle setting can be specified. The specified control is
followed until changed by another event trigger.

A Trajectory Script file is a text file like the following:

START SCRIPT: Units=fps


When Altitude>10000 Set AOA=-0.05 << start pitchover
When Altitude>20000 Set throttle=80
When q-dynamic<100 Set throttle=999 << maximum/ab thrust
When Thrust<0.01 Set AOA=0.0
When q-dynamic>500 Set S-turn=1. << pullup to level flight
END SCRIPT

When the Guidance Method is RunScript and DoAnalysis is selected, RDS win prompts “Create
New,” “Pick Existing,” or “Modify Existing.” If you select Create New, the sample above is
presented in a pop-up box along with instructions for creating a trajectory script.

151
You can also create a new Trajectory Script file outside of RDSwin using a text editing program
such as WordPad, or can develop a script by modifying the sample in the provided file
ROAST_Trajectory_Script.rdsDts. Script files normally use extension .rdsDTS but any extension
is acceptable. Script files must be saved as plain text (SaveAs-PlainText).

Trajectory Script Event Triggers and Controls


A Trajectory Script starts with a line beginning “Start Script:” (including the colon). Any text in
the file prior to that phrase is ignored, so you can add notes and comments above that line.
Similarly, text after the phrase “End Script” is ignored, and any text on a script line after the
symbols "<<" will be ignored. Blank lines are also ignored.

The Start Script line also specifies the units of the parameters in the script (“Units=fps” or
“Units=mks”). When a Script is run, RDSwin will automatically switch to those units. It is not
possible to run a script written in mks but see the results in fps, or vice versa. You’ll have to
translate the script yourself. The RDSwin Tools-UnitsConverter will make this easy.

Event Triggers are listed after the line "Start Script:" and have the following form:

WHEN (event)<>(number) SET (control)=(number)

Event triggers can be set for any of the items seen in ROAST printout data columns, namely:

Time Altitude Range Velocity M# AOA Gamma PitchRate


V-hor V-vert Weight Fuel Thrust Drag Lift n-lift
nX-Accel nZ-Accel q-dynamic q-alpha Delta-V EnergyHt Heating

Available Controls are:

Throttle AOA PitchRate nZ-Accel n-lift Gamma ClimbRate S-turn


ClimbSpeed LevelSpeed

Event Triggers and Controls are not case sensitive but otherwise they must be written exactly as
listed above, without abbreviation, and including any dashes. When an event trigger is satisfied,
it is printed to the right of that data line in the output table, and ROAST begins to apply its control
command.

There are no equality triggers. If you need a Event Trigger such as [Time>=20], use
[Time>19.99].

To set a control at the start of the simulation, use [When time>-1] You can have several of these.
However, in a vertical launch the angle of attack won’t be changed from zero until the altitude
has exceeded 1,000 ft and velocity has exceeded 100 fps.

152
For a command to take effect upon Burnout, use [When Thrust<1].

Multiple triggers can be defined using "OR" such as*:

When Time>50 OR Altitude>20000 Set AOA=0.5

Event Triggers can be defined incrementally using "MORE" such as:


When time>60 More Set AOA=0

Once the previous event trigger has been satisfied, this event trigger will watch until 60 more
seconds have passed, and then do its command (here, set AOA=0).

There isn’t a "Less" option. Instead, use a negative value with “More” but be careful – it might
make no sense. [When time>-60 more] will never happen unless your rocket is also a time
machine!

An Event Trigger is active until it is satisfied, at which time the given Control is executed and
the next Event Trigger is read and becomes active. Controls which have been set by an Event
Trigger are continued to the end unless superseded by another Event Trigger. Note that Throttle
is only affected by another Throttle control, whereas the others all change the angle of attack so
they supersede each other.

Only one Event Trigger is being watched for at a time. Subsequent ones are not even considered
until the previous one has been satisfied, and it may never be satisfied. For example, the script
below will shut off the engine and never restart it, because the vehicle will never reach 50,000
feet with the engine shut off at 5,000 ft!

START SCRIPT: Units=fps


When Altitude> 5000 Set throttle=0
When Altitude>50000 Set throttle=999
END SCRIPT

If an Event Trigger seems to be ignored, it was probably never active because one of the previous
Event Triggers was never satisfied. Also, it is easy to define a Script that causes the vehicle to
loop or dive into the ground! ROAST does exactly what you tell it to do. You can develop your
script interactively, leaving it open in WordPad or another text editor and changing it based on
what you learn from a previous result.

Controls are not case sensitive but must be written exactly as listed above. There can be only one
Control that is Set per Trajectory Script line. There is nothing equivalent to OR, AND, or MORE
for Controls. To set several Controls for the same Trigger, you can use several lines, such as:

When Altitude>10000 Set AOA=-0.05


When Altitude>10000 Set throttle=80

*
AND is not available

153
A Throttle control is defined exactly as in the RDSwin Sizing and Performance Modules. A throttle
setting of 0 to 100 sets the percent of thrust given in the Aircraft Data File "Thrust-dry/econ"
table. Throttle=999 uses thrust from the “Thrust-Max” (AB) table.

ROAST always starts with Throttle=999, and stays so unless changed by an Event Trigger, or is
automatically throttled back to avoid exceeding dynamic pressure, Mach, or X-axis acceleration
limits. To start at a lower throttle setting, use something like [When time>-1 Set Throttle=80].

Note that there isn’t a “Thrust” control, even though there is a Thrust Event Trigger. Use Throttle
to control the thrust (0-100 or 999).

The remaining controls in ROAST all affect the angle of attack. Obviously, AOA=5 sets the
angle of attack directly to five. However, PitchRate=5 also sets AOA, but it does so in order to
reach the target PitchRate. This is recalculated every quarter of a second, until the next Event
Trigger occurs. Similarly, when you set the nZ-Accel, n-lift, S-turn, Gamma, or ClimbRate,
routines in ROAST will calculate AOA to make it so - if possible.

Limitations for pitch rate, stall, and load factor may cause ROAST to set AOA to a different
value than expected. The change in AOA will also be limited by the maximum pitch rate.

The controls nZ-Accel and n-lift are similar, but n-lift considers only wing lift and is more
suitable for aircraft. The nZ-Accel control is more suitable for rockets and space vehicles, and
includes lift, rocket thrust, and the weight vector:

nlift = L/W
nZ-Accel = ( Tsin(aoa) + L - Wcos(gamma) ) / W

Note that in wing-borne unaccelerated level flight, n-lift equals one (1g) whereas nZ-Accel=0
since the vehicle is not accelerating upwards. Don’t let this confuse you!

The control "Gamma" is the climb angle in degrees. Use [Set Gamma=0] for level flight. Don’t
mistakenly say “ClimbAngle” instead of “Gamma.” It doesn't work.

ClimbRate should be given in fps or mps, not the fpm or mpm normally used by pilots.

The control "S-turn" is similar to Entry_S-turn in the ROAST input grid. If set to 1, the vehicle
will not be permitted to skip up (until the next Event Trigger Command becomes active). When
climb path angle tries to become positive, the Angle of attack will be lowered to the AOA needed
for level flight, until enough speed is bled off for descent to resume. If S-turn is set to a value
greater than 1, that becomes the load factor for level S-turns to bleed off speed. This is what the
Space Shuttle does during re-entry.

The ClimbSpeed and LevelSpeed controls are mostly used for aircraft trajectories. ClimbSpeed
keeps the throttle setting constant, and holds the given speed by controlling the climb angle (not
rate). There must, of course, be sufficient thrust to climb at that speed. If thrust is well in excess

154
of weight, the vehicle will eventually point vertically and will then accelerate beyond the desired
speed.

The control LevelSpeed continuously revises the angle of attack to try to hold climb angle at
zero, and simultaneously adjusts the throttle setting to maintain the current speed. This routine
attempts to hold altitude but, like a real pilot, it isn’t perfect.

The automatic pilot flying these controls in ROAST is aggressive, and assumes that when you
say “go to Gamma of 20 degrees,” you mean “right now.” If the vehicle is currently well away
from the target control condition, the maneuver to “make it so” will probably be done at the
vehicle structural limit. If you want a smoother, gentler maneuver, use something like:

START SCRIPT: Units=mks


When time> 5 Set n-lift=1.5
When Gamma>19 Set Gamma=20
END SCRIPT

Trajectory Script Misc. Controls


Normally the vehicle is flying right-side-up, so that a positive angle of attack makes it climb
upwards (figure 63). This is the default for Trajectory Script operation. However, you can roll
the vehicle over so that during a vertical launch, a positive angle of attack takes the vehicle
downrange (plus-X direction). This is done in a Trajectory Script by entering the phrase
Orientation=Launch on a separate line or in the Start Script or at the end of any Command line.
The phrase Orientation=Flight rolls it back to the usual up-is-up orientation.

START SCRIPT: Units=fps Orientation=Launch


When Altitude> 5000 Set AOA=-0.05
When Altitude>50000 Set AOA= 0 Orientation=Flight
END SCRIPT

The Start Script line can also override your input grid’s initial conditions of speed, altitude, and
climb path angle. To do this you must use exactly the following wordings (one or more, order is
unimportant):

START SCRIPT: Units=fps Altitude=10000 FltPathGamma=20 Velocity=600

The vehicle’s initial starting weight for the simulation can be changed from the Wo value in the
Aircraft Data File by adding StartWt=(#) to the Start Script line. This can either be a ratio
like 0.85, or an actual value in lbs or kg.

Since ROAST uses the RDSwin ParseVal routine, Trajectory Scripts can include triggers and
commands defined by simple expressions. For example, to set climb rate to 100 feet per minute
starting 5 minutes after the last command has been implemented, you can use:

When Time>5*60 more Set ClimbRate=100*60

155
Trajectory Script simulations start in “real time,” slowed down so that you can watch what
happens. An instrument panel displays speed, altitude, flight path angle, vehicle attitude, and
more. This is described in detail in the next section. If you wish to jump straight to the end, press
ESC or click with the mouse anywhere outside of the instrument panel.

While the pop-up control menu described in the next section is not available during a real-time
Trajectory Script run, the arrow and joystick controls are “hot.” If you press an arrow or move
the joystick, you’ll override the active Trajectory Script Command and see the change on the
instrument panel. Then when the next Command becomes active, it will override you!

This can be useful. Trajectory Script operation saves its commands to the bottom of the output
data table. If you override the Script with arrow or joystick inputs during a run, those inputs are
included in the saved Trajectory Script. Your overrides are saved as time-based Event Triggers
(When Time>…). You can use this capability to develop a new or revised Trajectory Script.

Real-Time User Control


The last guidance option is the most fun, but is also technically useful. Real-Time User Control
lets you “fly” your vehicle using arrows, joystick, and a pop-up menu of control commands.

When you select Do Analysis, an instrument panel pops up on the screen, the vehicle begins its
flight per the Launch conditions and initial AOA, and the controls become active. You fly it until
the MissionTime limit is reached or the vehicle hits the ground. If you get bored you can press
ESC to instantly continue the trajectory to the end, following your last input or command. After
completion, the usual graphing and data presentation options are made available.

The commands you have entered, including arrow keys, joystick inputs, and pop-up commands,
are recorded as a Trajectory Script that is added to the bottom of the output results table *. If you
run that Trajectory Script (first copy it to a text file), it should give the exact same trajectory as
when you first “flew” it.
START SCRIPT: Units=FPS
Orientation=Launch
When Time> 24.50 Set AOA= 1.0
When Time> 32.50 Set Gamma=75
When Time> 65.50 Set AOA= 0
Orientation=Flight
END SCRIPT

The saved commands are all defined by time-based Event Triggers, such as [When
Time>15.00 Set AOA=-2.0]. ROAST cannot know the real reason that you made a control
input, such as throttling back until exceeding a certain altitude, or setting AOA to zero when you

*
Experts Tip: This recorded Trajectory Script is also written to folder RDStemp, in a text file called
(yourfile)_RealTimeHistory.rdsDts, and in a format that can be immediately used as a Trajectory Script. If you
wish to use it, you must save it elsewhere BEFORE exiting RDS. All temporary files are deleted upon exit.

156
run out of propellant. You can edit the saved Trajectory Script to change the Event Triggers as
needed.

Joystick inputs may be too rapid to be properly saved in a Trajectory Script. Every tiny motion
gets recorded as a new command, and in some cases, the recording logic can’t keep up with the
numerous tiny steps as the joystick is moved. As a result, replaying the Script may not yield the
same trajectory. Arrow keys or pop-up commands should not experience such problems.

ROAST Instrument Panel


When you select Do Analysis for Real-Time User Control (or Trajectory Script), an instrument
panel pops up just below the input grid. All other RDS win inputs and pulldown menus are turned
off until the simulation is completed.

figure 67. Instrument Panel During Real-Time User Control

Key parameters are shown on the instrument panel. Dials from left to right show the altitude,
velocity, dynamic pressure, and current thrust. These dials have no units – they are only for a
quick visual check. The actual numbers are listed just below. The dials go from zero to the
expected maximum value based on the Aircraft Data File. When this range is exceeded, the dial
is shown crosshatched, like the dynamic pressure in the sample here. A crosshatch in the AOA
gage means that Clmax has been exceeded and the wing is stalled. However, ROAST continues
to assume that Clmax is attained and usable – so don’t go there!

Next are vertical tape displays for fuel/propellant remaining, and angle of attack. Tanks go from
empty to full; AOA goes from -30 to +30 degrees. Below the dials and tapes are text listings of
most of the parameters calculated throughout the flight and listed in the big output table.

To the right is a vehicle attitude icon, with flight path angle (gamma) shown as a red vector. The
icon is airplane-like, with a vertical tail and cockpit to make it clear which side is up. The bottom
of the cockpit defines zero AOA. When thrust is on, there is a red “nozzle” icon at the back.

For an unmanned vehicle the cockpit is eliminated. A short horizontal line shows zero angle of
attack. How does ROAST know the vehicle is unmanned? Zero crew weight.

157
If you prefer a more rocket-like vehicle attitude icon, you can change to the Rocket icon in
RDSwinParamsROAST.RTD (set ibAOAIconShape =1). This icon is shown below, in this case
in the upside-down Launch orientation. One side of the nose is a lighter color, to make it clear
which side is “up.” There is also a tiny stub of a tail to help visually.

figure 68. Instrument Panel with Rocket-like Attitude Icon

If you really want to get creative, you can edit these icons in file RoastAOAicon.rtd. Read the
instructions carefully. Only change the X and Y values of the points. Don’t insert, delete, or move
any text lines, and don't change the total number of points.

You can also change the instrument panel background image. ROAST always uses the image
named ROASTpanel.bmp found in folder RDSresource. You can edit or replace this image. There
are three more images in the folder, namely ROASTpanel-TurnedAlum.bmp, ROASTpanel-
Steel.bmp, and ROASTpanel-Wood.bmp. To use one of these, just copy it as ROASTpanel.bmp.
The default image is the turned aluminum version, so you can restore the original by copying it
back to ROASTpanel.bmp.

The folder RDSresource also includes file ROASTpanelOutline.ppt, which helps to create new
background images. You can put your favorite photo or some wild color scheme as the
background, then Save the slide as a bitmap. You’ll have to crop it appropriately using Photoshop
or something similar, then name it ROASTpanel.bmp and drop it into RDSresource.

Real-Time Controls
Real-Time User Control provides several control options to “fly” your vehicle. Remember that
ROAST is not intended to be a full flight simulator such as X-Plane or the Microsoft Flight
Simulator. ROAST is best viewed as a tool for calculating vehicle performance over trajectories
for which closed-form equations are not sufficient. It is supposed to be a engineer’s tool, not a
toy. But it can be fun anyway!

Once the instrument panel pops up and the simulation begins, normal RDS win menus and hot keys
are disabled until the simulation finishes. You will see the time counter progressing in real time,
and will see various changes in altitude, speed, and other parameters.

158
Since ROAST is a 3-DOF simulation, its available controls are essentially angle of attack and
throttle setting. These can be directly controlled using arrow keys or a connected joystick, or can
be automatically controlled to accomplish some task such as tracking a particular climb angle.

The available controls are listed below. The up/down arrow keys change the angle of attack.
Throttle setting is increased or decreased by up/down arrow keys, while holding down the Shift
key. Left or right arrows roll the vehicle 180 degrees, switching between Flight and Launch
orientation (figure 63).

ROAST REAL-TIME USER CONTROL HOT BUTTONS AND CONTROLS


Increase/Decrease AOA up/down Arrows
Throttle Increase/Decrease Shift-up/down Arrows
Roll (toggle Flight-Launch Orientation) left/right Arrows
Roll to Flight Orientation +
Roll to Launch Orientation -
Arrow key action speed Slow/Default/Fast = S / D / F
Pop-up Control Menu C
Help H
Pause/Unpause P
Exit Real-Time (& finish simulation) Esc

As in other parts of RDSwin, the amount of control resulting from an arrow key can be changed
by pressing S for Slow, D for Default (medium), or F for Fast. Repeatedly pressing S or F will
make the command even slower or faster. If you’ve pressed S or F too many times, just press D
to bring it back to the default.

Pressing ESC or clicking the mouse anywhere outside of the instrument panel will take the
simulation out of Real-Time mode. In other words, it will finish the trajectory analysis in the
blink of an eye and graph the results. The control settings will remain as they were, so strange
things can happen!

You can Pause the simulation at any time by pressing “P,” then resume it by pressing “P” again.

You can also issue the same commands that are available in Trajectory Scripts, setting AOA,
Gamma (flight path angle), Pitch Rate, and more. The Control Menu is displayed by pressing
“C” or by clicking with the mouse anywhere on the instrument panel. Note that this pauses the
simulation, and can be used to pause instead of pressing “P”.

The available commands in the Control Menu are the same as in Trajectory Scripts, namely:

Throttle AOA PitchRate nZ-Accel n-lift Gamma ClimbRate S-turn


ClimbSpeed LevelSpeed

159
Select one of these from the list then enter the desired value. ROAST will attempt to follow that
command until you override it with another command, or until you deliberately change the angle
of attack with an arrow key or joystick input. Note that Throttle is only affected by another
Throttle control, whereas the others all change the angle of attack in some way.

An attached joystick can be used to control angle of attack (stick forward/rearward) and throttle
setting (throttle paddle). Pressing the trigger pauses and unpauses the simulation. Pressing any
other button brings up the Control Menu described above. See the main RDS win manual for
information on setting up a joystick. And yes, it’s a lot of fun!

As with Trajectory Scripts there is a pitch rate limit during Real-Time User Control. This applies
to your arrow key or joystick inputs as well as the Control Menu options.

In the sample trajectory below, a vertical launch was followed by Control Menu Gamma=0,
causing it to pitch over to level flight. After a while the arrow keys were used to push back up to
a near-vertical climb. After burnout, the arrow keys were used to set AOA to 20 degrees for re-
entry. Then Control Menu S-turn=1 was commanded so that the vehicle wouldn’t skip upwards.
After that, ESC was pressed to instantly finish the simulation.

figure 69. Real-Time Control Trajectory

Obviously, this was a very inefficient launch trajectory!

160
RDS-EZ
At the bottom of the main screen, RDS win offers a routine called “RDS-EZ.” This is a simplified
method of developing the inputs required for range and performance analysis, assuming an
aircraft with a normal design arrangement. It works as if a design expert were to ask you some
overall questions about the design and then approximate the inputs required to estimate range
and performance.

RDS-EZ asks you to input about 20 geometric and weights numbers defining your design, such
as length, wing area, and whether the landing gear can retract. These can be saved, using filename
extension DEZ. When you select Do Analysis, it automatically develops RDS input files for the
aerodynamics and propulsion analysis, and uses statistical methods to estimate empty weight. It
shows you the rough estimates it plans to use, allowing you to override them in case you know
more about the design than RDS-EZ can estimate.

After RDS-EZ creates these input files, it automatically runs them, saves them to a new Aircraft
Data File, then runs sizing and performance analysis. All of these RDS input files are left open
in case you wish to revise them or use them as a starting point for a more serious analysis. If you
don’t save them, they disappear when you exit RDS.

Please keep in mind that RDS-EZ is just a quick approximation. You can use RDS-EZ to get a
5-minute answer or to get started on developing analysis files, but you should not rely on the
results from RDS-EZ for anything more.

161
OPTIMIZER AND CARPET PLOT

figure 70. Carpet Plot

RDSwin-Pro Optimization Overview


RDSwin-Professional has powerful capabilities for the multidisciplinary optimization of your
configuration. What distinguishes RDS win from other programs offering similar capabilities is
the extreme ease of use - once the RDS analysis files are created and checked, multidisciplinary
optimization can be done literally with the press of a button. Another unique feature - after MDO
is completed, RDS can automatically scale and revise your design to match the optimal TOGW,
engine size, wing planform, and fuselage fineness ratio.

Optimization can be done with a number of different methods including classic carpet plots, a
deterministic stepping search routine, and several variations of evolutionary and genetic
algorithms. The optimization works to minimize a selected Measure of Merit which can be
takeoff gross weight, empty weight, fuel weight, purchase price, life cycle cost, or internal rate
of return. This is done in the face of performance requirements including takeoff, landing, turn,
Ps, climb, and acceleration. Geometric constraints such as wing span, fuselage length, and
internal volume can also be specified.

The variables used for optimization in RDSwin are based on standard industry practice with a long
history going back to the 1930’s. These include T/W and W/S plus the wing trapezoidal planform
parameters, ie., aspect ratio, taper ratio, sweep, and wing airfoil thickness ratio. For the MDO
methods two more variables are added - fuselage fineness ratio and wing design lift coefficient
which is equivalent to camber optimization.

162
For a detailed discussion of aircraft conceptual design optimization and the methods employed
by RDSwin, see Enhancing Aircraft Conceptual Design using Multidisciplinary Optimization (D.
Raymer), 2002, available (free) at www.aircraftdesign.com/otherstuff.html .

Note that the Optimization & Carpet Plot module contains stripped-down copies of the analysis,
sizing, performance, and cost routines used elsewhere in RDS win. Input error checking is removed
for speed, so carefully test your input files in other modules before trying to Optimize.

Optimization Input Grid


Optimization parameters are set in a typical RDSwin input grid which is opened by clicking on
the big box to the right on the RDS win main screen, or by using JumpTo. In the input grid you
can change various default settings including optimization method and the measure of merit in
the first column.

The second column contains inputs for the various real-world constraints to be applied to the
optimization. These constrain the MDO solution to approximate the real-world effects on an
actual design layout. Wing span and fuselage length are “no greater than” limits, whereas
fuselage diameter is “no less than,” to make sure that passengers can still fit inside.

The Pitchup constraint ensures that the final combination of sweep and aspect ratio remains on
the safe side of the pitchup graph in Raymer's textbook, and is based on NACA TN 1093. The
maximum speed in the aerodynamics input file is used to determine whether to use the subsonic
or supersonic constraint line. This constraint is needed only for substantially swept wings, and is
usually important only for tailless or T-tail designs.

The Net Design Volume* constraint will approximate the aircraft's internal volume, net of known
volumes such as the fuel tanks, and will then adjust the aircraft length to maintain that total net
volumetric density as the design changes during optimization. By default, RDS will not make the
fuselage smaller, only larger. This can be changed by editing resource file
RDSwinParamsMDO.RTD which sets many optimization parameters, but this is not
recommended.

The third and fourth columns allow you to set the extents of the optimization, ie., the allowable
ranges of the design variables. When you first make a new optimizer input grid the minimum and
maximum values are set as 20% above and below the as-drawn baseline values. You can change
the minimum and maximum values as desired. Note that they are reset to 20% variations any
time you change the baseline design values of those variables. Also, the as-drawn baseline values
are listed on the grid but cannot be changed here.

These optimization inputs can be saved for later application. A .rdsDOP file extension is used.

Another parameter can be useful in special cases where the optimization results change the
vehicle size by a large percentage. This affects the aerodynamic drag estimation and is set in the
*
Raymer, D., "Use of Net Design Volume to Improve Optimization Realism",Weight Engineering Journal Vol 61
#2, Society of Allied Weight Engineers, Spring 2002

163
Aircraft Data File, not in the Optimizer input grid. Called %NotPhotoScaled, it is found in the
second paired column of the Weights & Misc input grid. This defines the percent of the total
aircraft wetted area that is frozen in size, and does not photo scale up or down when the aircraft
is sized.

If a zero value is provided, the trade study aerodynamics calculations assume that the entire
wetted area of the aircraft photographically scales by the wing area which, in turn, is scaled by
the change in aircraft takeoff gross weight. In other words, the parasitic drag coefficient is
unchanged because as the aircraft gets larger or smaller, the wing reference area gets larger or
smaller in direct proportion. For most aircraft this is a very reasonable approximation for sizing
calculations.

In some cases this assumption may be misleading, especially if the aircraft takeoff gross weight
changes a lot during sizing. An example might be the fuselage of an advanced technology
passenger aircraft, where the advanced technology causes the sized takeoff gross weight to be
significantly reduced from the initial assumption. However, the fuselage cannot be made smaller
than the original layout if the passengers are to have enough room inside. In this case, a value for
%NotPhotoScaled of 0.3 to 0.5 should be determined by ratio of the component’s wetted area
(see the TAB file). This RDSwin-Pro capability is for special cases and can normally be left as
zero.

Carpet Plot
The classical carpet plot method optimizes the design graphically by parametrically varying any
two design variables and calculating the resulting change in the value of the selected Measure of
Merit. Performance constraint curves for requirements such as takeoff distance and turn rate are
calculated and shown on the graph (see above). To do this, RDS actually creates 25 new airplanes
(5x5) and does full analysis on each. For your review, RDS saves their DAA, DWT, and DAT
files in the RDStemp folder. They are erased when RDS is shut down.

A Carpet Plot can be run from the optimization input grid, or run without opening an input grid
by selecting Analysis-CarpetPlot. When run this way, a carpet plot is created using Wo as the
Measure of Merit and with default values for the first-column items.

Once the first carpet plot is shown, you can replot it using another measure of merit. You can
also show/print the calculated results for the 25 airplanes used for the plot, or graph those raw
results.

Unlike the multivariable MDO methods below, Carpet Plots do not employ the real-world
constraints in the second column of the input grid, and cannot automatically modify the design
layout since the optimal results are obtained visually, not numerically. Also, Carpet Plots can
only optimize for the first six variables listed above.

After the MDO methods below have found the best airplane, a classic two-variable carpet plot is
prepared for the optimal airplane. This helps you to better understand the tradeoff of the
parameters and performance constraints.

164
Orthogonal Steepest Descent Search
The RDS Multidisciplinary Optimizer simultaneously optimizes an aircraft for thrust-to-weight
ratio, wing loading, aspect ratio, sweep, taper ratio, wing airfoil thickness, fuselage fineness ratio,
and wing design lift coefficient in the presence of performance and geometric constraints, to a
selected measure-of-merit. In some ways this is similar to the carpet plot routine in that the
baseline design is modified by use of parametric changes in key design variables, and the
resulting modified designs undergo aerodynamics, weights, sizing, performance, and cost
calculations. In the carpet plot method these results are shown graphically for your visual
selection. In the MDO routines, various schemes are used to find the best airplane for you. Also,
the MDO routines can optimize to all eight variables described above, whereas carpet plots only
optimize the first six.

The first MDO optimization technique offered in RDS is a steepest descent stepping scheme. The
baseline is parametrically varied by changing the design parameters incrementally by plus and
minus some selected stepping distance, and the measure of merit and performance values are
calculated to determine if a given parametric variation is superior to the current “best”. The
routine then “steps” towards a better answer. Whereas some versions of steepest descent
optimization try to find the exact direction of maximum improvement, the variant coded in
RDSwin just selects the best of the parametric versions actually calculated, earning it the name
“Orthogonal Steepest Descent.” OSD seems to converge just as well, and is fast and robust.

Analysis begins at the as-drawn baseline as defined in the selected input matrices. A search step
interval is defined for each variable as a percentage of the minimum-to-maximum range
established by the user, starting at around 25% and successively reducing to less than 5%.
Parametric variation of the variables then begins, starting at the highest T/W, lowest W/S, highest
aspect ratio, lowest sweep, and lowest thickness ratio. These are used as starting points because
this "corner" of the design space is most likely to have an aircraft meeting all performance
constraints even if the baseline doesn't.

As in the carpet plot, each variable's parametric effects on the inputs to analysis are estimated
and revised in the aircraft's analysis input matrices. The aircraft is re-analyzed for aerodynamics,
weights, sizing, and performance. The "best" variant, that with the lowest value of the selected
measure of merit that also meets all performance requirements, is remembered, and when all
parametric variations about the initial baseline are exhausted, becomes the center point baseline
for the next iteration loop. This continues until no better variant is found, then the stepping
distance is shortened and the process repeated until some desired level of resolution is obtained.

During optimization, the baseline and current “best” design parameters are shown along with a
Windows progress box. After optimization is complete (2-15 minutes), the full results are shown
using your selected List/Print option.

165
Evolutionary and Genetic Algorithms
Evolutionary and Genetic Algorithm methods will typically not find an answer as good as that
found by the Orthogonal Steepest Descent method described above. Their advantage is speed -
they get close to the correct answer much more quickly than OSD, which plods along through
tens of thousands of parametric variations before finding an improvement.

These other methods are all related in that they are stochastic (random) in nature, and they all
rely on a “chromosome” bit-string to define the parametric variations of the aircraft being
optimized. This bit-string can be viewed as a “code” to make an airplane. By reading the code
and applying its numbers to the design variables, a new version of the baseline design is created.
In RDS, the binary chromosome bit-string is defined as follows:

T/W W/S A taper sweep t/c fuselage l/d CL-design


000000 | 000000 | 000000 | 000000 | 000000 | 000000 | 000000 | 000000

Each of the eight parameters is defined by six binary digits that represent position on a spectrum
from lowest to highest permitted value of that design variable, as input by the user. Thus, if the
user allows wing loading to range from 40 to 100, the string 000000 represents 40, the string
111111 represents 100, and 001010 represents {40+(100-40)(10/63)=49.52}.

A binary random number generator is used to create a new bit-string of 1’s and 0’s. This is
decoded and applied to the baseline design, modifying it in the same manner used in the carpet
plot and OSD methods. The modified design is analyzed as to measure of merit, performance
requirements, and geometric constraints. The process is then repeated for a new bit-string.

In the stochastic Monte Carlo method, this is all that is done. Thousands of alternate designs are
randomly created and analyzed, and the best one created is declared the winner. Obviously, there
is no way to know if it really is the best design possible, but as long as the design obtained is
superior to the baseline, then the method has served a useful purpose.

The “smarter” methods below all start with an initial population created entirely at random, just
like Monte Carlo. After that first population of (typically) 500 is created, these methods attempt
to create a better new generation by selection of superior members of the previous population.

In the so-called “Killer Queen” method, similar to bees or termites, only one single “best”
member of each population is selected and “bred.” This is done by creating copies of the best,
then making small random changes to each copy. The new population is evaluated, the best is
selected, and the process continues.

A Genetic Algorithm (GA) attempts to create a new population by somehow “merging” the
characteristics of pairs of superior members of the previous population. RDS win has four different
types of Genetic Algorithm. For all four, members of a randomly generated starting population
of aircraft are analyzed and evaluated as to fitness, based on the measure of merit, and the most-

166
fit are most likely to be permitted to reproduce. This “fitness” is based on the calculated value of
the measure of merit, penalized if constraints are violated.

“Reproduction” for the next generation occurs by “crossing” their genes with those from another
selected “parent”. The next generation is evaluated as to fitness, the most-fit members are
selected for “breeding,” and the process continues until the population all resemble each other,
the measure of merit is no longer improving, or a limitation on number of cases is reached.

It is in the selection method that these GA types differ. Roulette Selection is like the gambling
device, but the sizes of the “slots” into which the random “ball” can fall are determined by the
calculated values of the measure of merit. In Tournament Selection, four individuals are chosen
at random to “fight” one-vs.-one, with the superior of each pairing being allowed to reproduce
with the other “winner”.

In nature, the survival process is often decoupled from the selection process, and breeding
selection is a fairly random event from among those who have survived long enough to reach the
reproductive age of the species. In the Breeder Pool method, the top 25% of the total population
is placed into a pool from which two individuals are randomly drawn to breed. In the Random-
Stir variation, the selection is slightly randomized to allow a few lucky individuals to jump into
the breeder pool despite falling below the top 25% range. This maintains diversity, which is often
essential to a good GA result.

Evolutionary and Genetic algorithms are iterative in nature, with a (hopefully) better and better
result appearing as the solution progresses. Typically, as a solution converges the changes to the
current “best” answer get smaller and smaller.

As the routine goes through generation after generation, it should be expected that “good” traits
would begin to emerge. Many individuals in the population start to possess those good traits and
thus, begin to resemble each other. This appears mathematically as an emerging similarity in
chromosome bit-strings. For example, after several generations one may note that the sixth bit
positions in the individuals’ bit-strings are now mostly ones, whereas the eighth bit positions may
be mostly zeros.

When starting such an evolutionary method, the bits should initially have a random distribution.
When the bits become completely non-random (all individuals have identical bits), the population
is identical and the method can go no further unless mutation is introduced. This progression
from randomness to non-randomness provides a clear indication of the progression towards
convergence.

To calculate this bit-string indication of convergence, the “Bit-String Affinity” term has been
defined such that a calculated value of zero (0) indicates a completely random * population,
whereas a calculated value of 100 indicates an identical population. This Bit-String Affinity
measure of convergence is provided in the RDS output results of these stochastic methods

*
For mathematical reasons, a Bit-String Affinity value near zero can only be obtained with a huge sample size

167
The two graphs below illustrate typical RDS optimizations for a sample commercial airliner. As
mentioned above, the deterministic OSD method ultimately finds the best answer but the various
stochastic methods get close to the optimal in just a fraction of the elapsed time. Research
indicates that these stochastic methods can get within 2% of the best answer in as little as 10%
of the total case evaluations required by a deterministic stepping search.

The three GA routines all show a steady progression in Bit-String Affinity, with the Breeder Pool
method showing the strongest convergence in this example. The Evolutionary “Killer Queen”
method immediately jumps to a high value of Bit-String Affinity because all members of
following populations are slightly-mutated versions of a single best member of the previous
population. This, like the Monte Carlo method, does not converge in a mathematical sense, and
instead the solution is driven by randomness.

figure 71. MDO Solution Convergence

168
figure 72. Bit-String Affinity

These Evolutionary and Genetic Algorithm methods including Bit-String Affinity are detailed in
Enhancing Aircraft Conceptual Design using Multidisciplinary Optimization as mentioned
above. RDSwin uses suitable default values for all the parameters and options, including some not
mentioned that allow simulated annealing, elitism, and other MDO options. These can be
changed by editing resource file RDSwinParamsMDO.RTD. This is not recommended.

Post-Optimization Automatic Design Scaling


A unique and powerful capability in RDSwin allows the automatic scaling of your design’s
components to instantly match your latest optimization results. After you’ve done optimization
or a sizing calculation, the command [Scale Design To Latest Sizing Or MDO results] does just
that. This command can be found under the Tools and Component-Scale pulldown menu options.
It isn’t perfect, but it does all the “grunt work” such as changing the wing planform, stretching
the fuselage, and resizing the tires according to the MDO results. It also takes care of the obvious
secondary effects like the need to lengthen the landing gear if the fuselage gets longer.

The design to be automatically scaled MUST be the original design layout file used for the most
recent optimization. The Design Layout is scaled to the new TOGW, its fuselage is stretched to
the new optimal fineness ratio while holding Net Design Volume constant if used, the engines
and nacelles are scaled to the new thrust level, the wings are revised to the optimized W/S and
planform geometry, the tails are scaled to keep a constant tail volume coefficient, and the tires
are scaled using statistical methods. The routine goes through each affected component, asking
the user if that component should be scaled. Of course, if the results look ridiculous the user can
UnDo the whole design back to the version before the automatic scaling.

169
All affected components must have had their SAWE8 type codes set, so that the routine knows
which methods to apply to which components. Certain component types are never scaled, such
as Passenger compartment, Cockpit controls, Radar, Antenna, Avionics, Instruments, Crew,
Passengers, Seats, Accommodations, Cargo, Armament, and Load.

Automatic Design Scaling is based on calculated “ As-Drawn” and “Best” values stored in
temporary file “BestDSN.tmp”, namely TOGW, T/W, W/S, A, Sweep, Taper ratio, airfoil t/c,
Fuselage Fineness Ratio, and the Wing Design Lift Coefficient. Three required Fuselage
parameters are also saved in this file. An expert user can “hack” this file, changing those values
as desired, to rapidly revise a design. Be careful…..

There is a related routine can also be used to scale your entire design by an input takeoff gross
weight (Wo). This works by keeping wing loading and tail volume constant, scaling the engine
and nacelle to hold T/W constant, and scaling the landing gear statistically. The new Wo can be
entered as an actual value or as a ratio to the current value. The routine offers every component
for scaling (yes-no), not just those currently selected for edit.

Optimization Methods and Issues


Fundamentally, the Carpet Plot and MDO routines all work by parametrically varying the chosen
design variables, calculating the resulting weight or cost Measure of Merit, and using some
method to find the best combination of design variables that also satisfies performance and
geometric constraints.

For each parametric variation, the parametric variables' effects on the inputs to analysis are
estimated and revised in the aircraft's analysis input matrices, and the aircraft is re-analyzed for
aerodynamics, weights, sizing, cost, and performance. The assumptions as to the parametric
variables' effects on the inputs to analysis are crucial to the solution. Beyond the obvious (engine
thrust varies with T/W), key rules used are as follows:

1. Tail areas vary by the 3/2 power of wing area to hold constant tail volume coefficient
2. Maximum cross section area for wave drag calculation varies by wing area, t/c, and by cos(wing
sweep), weighted to baseline percentage of total cross section area
3. Nacelle wetted area varies by T/W
4. Wing fuel volume varies by 3/2 power of wing area

To do optimization you must have previously input the "Required" values in the Performance
Module input grid, and provided the "Requirement Codes" according to the following table:

170
Performance REQUIREMENT MEANING
ITEM CODE

Takeoff 1 Takeoff Ground Roll


2 Total Takeoff Distance
3 FAR 25 Takeoff Dist
4 Balanced Field Length

Landing 1 Landing Ground Roll


2 Total Landing Distance
3 FAR 25 Landing Dist
4 No-flare Landing Dist

Ps and Turn 0 Instantaneous Turn Rate


>=1 Ps (Req.Code=load factor n)

Acceleration 1 Time
2 Distance

Time to Climb 1 Time


2 Distance

For a stall constraint line, use a "Ps and Turn" performance input column. Provide the altitude
and velocity in the input grid, and then set both the requirement code and the required value equal
to zero.

For a sustained turn constraint line, give the desired load factor as the requirement code and set
the required value of Ps equal to zero. To allow the carpet plot to be drawn correctly even if the
baseline is stalled, the Carpet Plot Module indicates a turn rate of negative one (-1) when stall is
encountered. This can be seen in the raw results plotting and in the carpet plot results printout.

The use of alternative drag polars is described in the Sizing and Mission Analysis Module chapter
above. In the Optimization and Carpet Plot Module, RDS win-Pro will use alternative drag polars
as defined in the mission or performance constraints, but cannot parametrically vary them for
changes in aspect ratio and other design parameters. This may invalidate optimization results if
extensive use is made of alternative drag polars. Check the sizing results to see if a mission
segment using an alternative drag polar is consuming a lot of fuel, and check the performance
results to see if a performance condition using an alternative drag polar is in fact one of the
constraints at the selected optimal result. If either is the case, beware!

It is fairly common for some errors to occur during Carpet Plot analysis. For example, during
optimization of W/S the parametric variation with the highest wing loading may "stall out" at
higher altitudes and/or lower speeds. RDS checks for such things and remembers where they
occurred, but continues the analysis using some assumption.

For example, a baseline design with marginal thrust may barely meet a takeoff requirement.
When that baseline design’s thrust is parametrically reduced by 20% it may not be able to climb
after takeoff, especially with one engine out. In the Performance Analysis Module RDS would
warn you of the problem and stop the calculation. In the optimizer/carpet plot module, RDS
assumes enough thrust to climb and continues with the calculations. This allows a carpet plot to
be completed, but the resulting plot might be crazy-looking.

171
Any such errors that are found are indicated in a table at the bottom of the results printout, as a
matrix of "X's" showing which parametric variations had what errors. Remember that RDS does
25 parametric variations, 2 up and 2 down for each variable. They are numbered 1 to 25 starting
with the "down-down" case, and number 13 is the baseline.

The error item titled "Best Cruise/Loiter (?)" occurs when the altitude/speed optimization routine
seems to have difficulty finding a valid result. In such a case, you may wish to find the optimal
cruise or loiter conditions for the baseline using the Performance Module, and enter those values
in the sizing inputs input grid. This will also speed up the carpet plot calculations.

In most cases, these "errors" can be ignored because they usually occur away from the baseline,
and away from the selected optimal result. To ensure that the selected optimum has no such
problems, you may wish to add another performance constraint representing the error item (such
as stall). Make sure that you recheck for such errors after redesign and resizing of the optimal
configuration.

Such “fixed” errors are not a problem in the various MDO methods because any aircraft
variations that experience such problems are not viable optimum solutions, and are simply
thrown away. The only reason this is a concern for carpet plots is the need to construct smooth
curves throughout the design space.

Note: to speed up these time-consuming optimization methods, the Windows “OnShutdown”


routine is turned off. This means that, should you decide to shut down your computer during an
MDO run, RDSwin won’t get the message to prepare for shutdown. This causes no problems
unless you have modified an input file but not saved it. In that case, Cancel the MDO run and
exit RDSwin properly, saving those files, before shutting down your computer.

172
APPENDIX A: WEIGHTS EQUATIONS & VARIABLE NAMES
The RDSwin Weights Module performs a statistical weights analysis using equations and methods
from Raymer’s textbook, based on geometry and other parameters defined in the input grid. There
are three complete sets of equations, one for fighter/attack aircraft, one for transports and
subsonic bombers, and one for general aviation aircraft (also suitable for UAVs).

The actual equations used for weights analysis are listed below, taken with permission from
Aircraft Design: A Conceptual Approach, 5th Edition (Copyright © 2012 by D. P. Raymer). Their
original Imperial units are shown here, but RDS win permits input in metric units as well.

To get good results in your analysis, you will have to carefully think about how your design
compares with the “normal” designs implied in these equations and make suitable adjustments.
RDSwin deliberately provides numerous opportunities to adjust the results, including explicit
“fudge factors” in most input grid columns. Of course the actual inputs can be adjusted too, such
as the recommended use of a half-man (0.5) value for number of personnel, which approximates
the air conditioning required for the avionics in an unmanned aircraft.

When the general aviation aircraft equations are being used, the statistical analysis for fuselage,
wing, tails, and landing gear can be overridden by entering a nonzero value for [Wt/UnitArea]
or, in the case of landing gear, [Use % of Wo]. Typical values can be seen in figure 73, which
can also be used to check the results for all types of aircraft.

figure 73. Approximate Empty Weights

173
174
175
176
177
178
179
180
figure 74. Misc. Weights Data

181
APPENDIX B: TAB File Information
In the Design Layout Module, the DesignAnalysis command creates a tab-delimited file of key
design geometric information. The TAB file contains wing and tail data blocks as well as
component information such as centroid location, cross section perimeters and areas, and
moments of inertia. This RDSwin file has filename extension “.TAB” and is read by the Aero,
Weights, and Propulsion analysis modules to acquire geometric information about the design.
On the RDSwin main screen program flowchart, the TAB file can be visualized as the arrows
going from the DLM down to the three functional analysis modules. A portion of a typical TAB
file is shown below, and a sample is included with the program.

When DesignAnalysis is selected, your airplane is shown in side and top view, and you are
prompted to indicate the location of various items such as crew station. This is only for use in
CG calculations, to provide an X location for those weight items that haven’t been designed yet
or can’t be represented by a single component (like “fuel system”). Click on X locations for each
prompted item, or press N for numeric entry. You can press Esc to skip this step.

After its creation, the TAB file will be saved to your project directory. For your review, it will
be opened in your computer’s designated spreadsheet (probably Excel). Note that you are looking
at a COPY, so any edits you make won’t be seen by the RDS analysis modules. If you actually
want to edit it, find the similar file with extension TAB, and make sure you save it with that
extension (and not .TAB.XLS).

The TAB file (or XLS copy) is of great use to designers especially when writing reports, and it
can be emailed to others who will find most of their design questions answered. In fact, simpler
aero panel codes can be run just from information in the TAB file – we’ve done it!

A few more points about the TAB file:

Component surface areas & volumes should be multiplied by # comps to get the total for the
whole airplane.

Wing & tail components are pre-rotated so any rotations given are in addition to normal
orientation. Their area and volumes already includes both sides of the airplane. Surface Areas
are perimeter-based and not adjusted for covered regions like wing root. If a wing or tail has had
its planform stretched or modified to a multi-paneled geometry like the B-2, RDS estimates an
equivalent airfoil thickness ratio (t/c) as the airfoil measured (t/c), weighted by chord length and
averaged over trapezoidal panels between each airfoil location.

Currently, RDS is not smart enough to recognize when two components touch each other, for
example where a canopy sits on the fuselage. You must estimate those overlaps from the
geometry and subtract those from the TAB file’s wetted areas of both components. These will be
addressed in a future RDS release.

Centroid and Inertia results are given for every real component. These results are presented far
to the right in the component listings, first in the local axis system as centroid and moments of

182
inertia about that centroid. Then centroid and moments of inertia are given in the global axis
system, referenced to the LAST center-of-gravity component in the file, or the global (0,0,0) if
no CG component is provided. The CG location is the as-drawn location, i.e., wherever you chose
to position the CG symbol. If you want inertias about the actual aircraft CG you must set up and
run the RDS weights module (or find CG some other way) then go back to RDS-DLM, move the
CG symbol accordingly, and rerun Analysis to make a new TAB file.

Centroids and geometric Moments of Inertia are calculated using a cross-section integration
method. This is not as accurate as a full volumetric integration based on a solid model, but has
the advantage of being “do-able” without spending the time required to make and validate a full
solid model. This method allows calculation immediately after making changes to a component.
Errors are typically just a few percent, but some geometry may see greater inertia errors. Global
moments of inertia may be inaccurate for canted components.

Cross-moments are neglected so if a component is quite irregular about its axis system and it is
oriented at other than right angles, additional errors may be seen in the global moments of
inertias. Moments of inertia assume a unit mass which is evenly distributed (so multiply by mass
before use).

Wing HorTail VertTail


Area Sref 5833 600 555
Aspect Ratio 1.82 2.5 0.9
Taper Ratio 0.05 0.15 0.1
Sweep (LE) 62.893 47.599 59.981
Sweep (c/4) 55.527 38.641 51.918
Airfoil NACA 64A-010 NACA 64A-010 NACA 64A-010
Thickness t/c 2.20% 3% 4%
Dihedral 2 4 0
Incidence 0 0 0
Twist 0 0 0
Span 103.034 38.73 22.349
Root Chord 107.833 26.942 45.15
Tip Chord 5.392 4.041 4.515
Mean Chord 72.059 18.313 30.374
Y-bar 17.99 7.297 8.127
X loc (apex) 102.139 232.997 217.664
X loc (c/4) 155.299 245.566 239.324
Y location 0 0 0
Z location -6 3.081 5.009
Tail Vol 0.129 0.078
Comp Type RefWing HorizTail VertTail
SAWE8 Code [002-000] [020-001] [020-003]

Total Surface SurfArea+ Total


Component SAWE8 Code Length Width Height A-max l/d-equiv. Area Ends Volume
Wing [002-000] 51.517 130.32 2.741 229.894 3.011 15143.267 15375.73 7546.197
PassCompart [031-011] 172.992 14 6.5 91 16.071 7092.672 7274.672 15742.27
Fuselage [031-000] 264.05 15 15 175.581 17.66 10552.604 10555.01 36203.69
AB Tfan 70k [059-000] 26.892 4.523 5.4 19.929 5.339 403.929 417.016 437.63
AB Tfan 2 [059-000] 26.892 4.523 5.4 19.929 5.339 403.929 417.016 437.63
Nacelle [045-001] 51.807 10.862 5.202 51.808 6.379 1380.242 1432.787 2337.586
HorTail [020-001] 19.365 26.942 0.808 14.442 4.516 1253.24 1268.007 219.897
VertTail [020-003] 22.349 45.15 1.806 54.078 2.693 1222.631 1277.25 450.307

183

You might also like