Document
Rotorcraft Optimization Tools:
Incorporating Rotorcraft Design Codes into
Multi - Disciplinary Design, Analysis, and Optimization
Larry A. Meyn Aerospace Engineer NASA Ames Research Center Moffett Field, CA Abstract One of the goals of NASA’s Revolutionary Vertical Lift Technology Project (RVLT) is to provide validated tools for multi - disciplinary design, analysis and optimization (MDAO) of vertical lift vehicles. As part of this effort, the software package , Rotor C raft Optimization Tools (RCOTOOLS), is bei ng developed to facilitate incorporat ing key rotorcraft conceptual design codes into optimizations using the OpenMDAO multi - disciplinary optimization framework written in Python. RCOTOOLS, also written in Python, currently supports the incorporation of the NASA Design and Analysis of RotorCraft (NDARC) vehicle sizing tool and the Comprehensive Analytical Model of Rotorcraft Aerodynamics and Dynamics II (CAMRAD II) analysis tool into OpenMDAO - driven optimizations. Both of these tools use detailed, file - based inputs and outputs, so RCOTOOLS provides software wrappers to update input files with new design variable values, execute these codes and then extract specific response variable values from the file outputs. These wrappers are designed to be flexible and easy to use.
RCOTOOLS also provides several utilities to aid in optimization model development, including Graphical User Interface (GUI) tools for browsing input and output files in order to identify text strings that are used to identify specific variable s as optimization input and response variables. This paper provides an overview of RCOTOOLS and its use.
Two rotorcraft design codes that NASA researchers use in Introduction * this process are NDARC an d CAMRAD II. The NASA The ability to hover, as well as takeoff and land vertically is Design and Analysis of RotorCraft (NDARC) is a highly desirable for numerous air vehicle use cases. These conceptual aircraft design software tool with a primary include huma n and cargo transportation systems that are focus on rotorcraft. The Comprehensive Analytical Model independent of airports and runways, as well as surveillance of Rotorcraft Aerodynamics and Dynamics II (CAMRAD and inspection missions that require loitering capabilities.
2,3 II) is a comprehensive rotorcraft analysis tool. An To support the development of new vehicles with vertical example of integrating CAMRADII and NDARC for the lift capabilities, the National A eronautics and Space design and performance analysis of compound helicopters is Administration (NASA) created the Revolutionary Vertical presented in Ref. 4 , in which the design process was Lift Technology (RVLT) project. Part of the RVLT project’s basically a manual integration where code inputs were goals is to support the development of a multidisciplinary manually altered based on the results of previous iterations design and optimization (MDAO) process for the design of of the codes. Manual processes such as this are time ver tical lift aircraft. This involves the coupling of codes consumi ng, which highlights the need to automate the from multiple disciplines, required for the design of a new process using a tool such as OpenMDAO.
vertical lift vehicle, into a coordinated optimization process.
OpenMDAO is an open - source computing platform for multi - disciplinary o ptimization, written in Python, that is currently under development at NASA Glenn Research Presented at the AHS Technical Conference on Center and is supported by the RVLT project . OpenMDAO Aeromechanics Design for Transformative Vertical Flight, provides a framework for connecting “components” which San Francisco, CA, January 16 - 19, 2018. This is a work of provide design and analysis calculations, and then solvi ng the U. S. Government and is not subject to copyright them in a tightly - coupled manner using a variety of both protection. All rights reserved.
gradient - free and gradient - based optimization methods.
E xamples of using NDARC and CAMRAD II in an Initial Aircraft New Technologies OpenMDAO - based design study are provided in Refs. 6 and Definition and Topologies 7 . These examples show both the feasibil ity and desirability of having NDARC and CAMRAD II available as components for use in OpenMDAO optimizations and Modeling Codes analyses. Both NDARC and CAMRAD II use file - based (with OpenMDAO Wrappers) inputs and outputs, so integrating them into an OpenMDAO Aerodynamics, Structures, Engine, optimization require d the developmen t of file - based Geometry, Handling Qualities, etc.
application wrappers , so that they could be used as “components” in an OpenMDAO optimization. These RCOTOOLS RCOTOOLS wrappers would take design variable input values from the OpenMDAO framework, incorporate them into input files, CAMRAD II execute the file - based appl ication, parse the output files and RCOTOOLS then provide design variable output values to the OpenMDAO framework. The NDARC and CAMRAD II RCOTOOLS RCOTOOLS wrappers developed for OpenMDAO in these previous studies were not primarily developed for distribution to NDARC other designers an d they used an earlier, deprecated, version RCOTOOLS of OpenMDAO. The goal of the RVLT sponsored effort described in this paper is to develop flexible, easy - to - use and well - documented OpenMDAO design application Meets No wrappers that are intended for distribution and use b y Criteria?
rotorcraft designers .
Adjust Design Variables Figure 1 shows a flowchart depicting the role of Yes RCOTOOLS in an OpenMDAO optimization process for the design of a new vertical lift vehicle . The process starts New Vehicle with an initial, preliminary, aircraft design definition that Design includes new technologies and vehicle topologies. These are used to construct models for several design codes that have Figure 1 : A flowchart showing how RCOTOOLS could be OpenMDAO wrappers. These may include aerodynamics used in an OpenMDAO optimization for the design of a and structures models for rotors and/or other vehicle new vertical lift vehicle.
components, as well as codes modeling geo metry, handling wrappers do not validate inputs beyond simple namelist qualities or engine performance. An OpenMDAO problem format validation and any auxiliary input fi les, specified in is set up to connect these models to CAMRAD II and the input deck, are not read and parsed. NDARC and NDARC for a defined computation sequence where design CAMRAD II input files should be validated and tested variable values are passed between the model components.
before use with the RCOTOOLS wrappers. The wrappers in RCOTOOLS handles the i nterface to and from CAMRAD II RCOTOOLS consist of core , generic Python wrappers that and NDARC within the optimization problem. OpenMDAO read, modify and execute program input files and read and controls model execution in the optimization loop and extract data from solution files. These core wrappers do not adjusts design variable values as needed to meet the rely on or use OpenMDAO software. Separate wrappers are optimization criteria. For gradient - based optimizations, provided that interface with OpenMDAO. These interface OpenMDAO m ay also execute some models individually to wrappers inherit from OpenMDAO component objects a nd determine partial derivatives for some of the design are built on top of the core wrapper functions and objects.
variables via finite difference methods .
These OpenMDAO wrappers were designed to be flexible The NDARC and CAMRAD II application wrappers and work out - of - the - box for most needs. However, one of provided in RCOTOOLS are intended to be “light - weight ,” the reasons the core wrappers were developed, was to allow with minimal co mputational overhead. T he wrappers are not for easier development of custom OpenMDAO wrappers if intended to serve as full - blown application front - ends, such the ones provided do not provide needed functionality. The as the AIDEN application is for NDARC. The RCOTOOLS core wrappers also facilitate adapt ion to any future changes to the OpenMDAO application programming interface Fortran Namelist Wrapper (API.)
Many science and engineeri ng codes are written in Fortran An effort was made to use common code and similar APIs and often use Fortran namelist files for input. This is true of in the development of both the NDARC and CAMRAD II both CAMRAD II and NDARC . NDARC also has an wrappers in RCOTOOLS. When new design code wrappers optional namelist representation of the output solution. An example of namelist input for NDARC is presented in are added to RCOTOOLS, the goal is to maintain similar List ing 1. The namelist format separates inputs into named commonalities where possible. Much of the common code and functionality provided by RCOTOOLS resides in the groups and each group has a list of variable names and their rcotools.utils module which contains utility assigned values. Variable names within a group are unique, so when multiple assignments are made within a group, the functions used by both the NDARC and CAMRAD II last assignment is the one that is used. The beginning of a wrappers. An overview of these utilities will be presented next, followed by overviews for the NDARC and group starts with a “ & group_name ” tag and the group CAMRAD II wrappers. ends with a “ / ”, “ &END ” or “ $END ” tag. C omplex variable assignments are being used, such as Utilities “ loc_rotor(2)%XoL = 0.00 , ” which includes both Fort ran array and structure assignments. Of note, the group RCOTOOLS pro vides several utility functions that are used names ‘ DEFN ’ and ‘ VALUE ’ are being used repeatedly in by multiple application wrappers. C onvenience functions this example . Although OpenMDAO includes a module for are also included that may prove useful to RCOTOOLS reading and writing Fortran namelists, the more complicated users. These utilities are located in the rcotools.utils namelist assignments used by both NDARC and CAMRAD module. Among the utilities provided are a Fo rtran namelist II a re not supported . No third - party namelist parsers for wrapper for reading, writing and manipulating namelists and Python that were capable of handling NDARC and applications for graphically browsing input and output files CAMRAD II inputs were found, so a new namelist module used by NDARC and CAMRAD II. An overview of these was developed for RCOTOOLS.
utilities follows .
Listing 1 : Example namelist based on NDARC input.
&JOB open_status=1,&END &DEFN action='ident',create d='today',title='standard input',&END !############################################################################## &DEFN action='read file',file='gen1000.list',&END &DEFN action='read file',file='airplane.list',&END !================================ ============================================== &DEFN quant='Geometry',&END &VALUE ! fuselage reference loc_fuselage%FIX_geom='xyz', ! scaled geometry (INPUT_geom=2); x +aft, y +right, z +up loc_cg%XoL =0.01,loc_cg%YoL =0 .00,loc_cg%ZoL = 0.00, loc_fuselage%XoL =0.00,loc_fuselage%YoL =0.00,loc_fuselage%ZoL = 0.00, loc_gear%XoL =0.00,loc_gear%YoL =0.00,loc_gear%ZoL = - 0.30, loc_rotor(1)%XoL =0.00,loc_rotor(1)%YoL =0 .00,loc_rotor(1)%ZoL = 0.20, &END &DEFN quant='Cases',&END &VALUE title='Airplane', TASK_size=1,TASK_mission=1,TASK_perf=1, OUT_aircraft=0,OUT_solution=1, &END &DEFN quant='Size',&END &VALUE title='design',nFltCond=1,nMission=1,&END &DEFN action='endofcase',&END &DEFN action='endofjob',&END Listing 2: Example code to read and modify a namelist.
1 from rcotools.utils import Namelist 3 # Create empty Namelist and then read in namelist file 4 mynml = Namelist() 5 mynml.rea d('namelist_xmpl.txt') # use nowarnings=True to supressing warnings 7 # Get variable representing group at namelist index 7 8 geometry = mynml[7][1] 10 # Modify value in the existing group 11 geometry['loc_rotor'][1]['ZoL'] = 0.25 13 # Insert new groups before the group containing 'endofcase' (index = - 2) 14 mynml.insert_group( - 2, 'DEFN', {'quant': 'Solution'}) 15 mynml.insert_group( - 2, 'VALUE', {'trace_size': 1, 'trace_case': 0}) 17 # Print out the modified namelist 18 print (mynml.writestr()) The rcotools.utils.namelist module has two writing and manipulating namelist groups, major classes, Namelist and N amelistGroup . The NamelistGroup objects implement all standard Namelist class represents namelists as a list of ( name , dictionary methods for dictionary manipulation.
† value ) tuples , where name represent s the group name and For typical use, only the Namelist class needs to be value is either a Python dictionary or a NamelistGroup .
imported , using either: To support the inclusion of comments and non - namelist From rcotools.utils.namelist import Namelist data, the tuple s can also contain a pair stings. If name string or: begins with a “ % ”, then value must be a str ing . Currently the following name strings beginning with “ % ,” are supported: from rcotools.utils import Namelist “ %comment_lin e,” “ %blank_line ” and Listing 2 is an example of using the RCOTOOLS’ “ %data_line .” When one of these names are Namelist class to re ad , modify, and print the namelist encountere d, then the value string contains the full text for presented in Listing 1. Importing the Namelist class is done one line of the file. Note that namelist group names may in line 1. Line 4 creates a new Namelist object, mynml , and appear multiple times within a Namelist . In addition to then in line 5, the “ read() ” method is used to read the special methods for reading, writing and manipulating namelist from a file. The resulting Namelist has 14 ( name , namelists, Namelist objects implement all standard list value ) tuples, which includes tuples for two comment lines.
methods for list manipulation. A simple Namelist list Line 8 assigns the NamelistGroup from the eighth ( name , could look like the following: value ) tuple in mynml to the variable, geometry. Since [('%comment_line', 'Comment string'), Namelist objects, like Python lists, have an initial index of ('GROUP1', NamelistGroup ), 0, the i ndex of the eighth tuple is 7 and since the ('GROUP2', NamelistGroup ), ('%blank_line', '' ), NamelistGroup is the second item in the tuple, its index is 1.
('GROUP3', NamelistGroup )] In line 11, the value for “loc_rotor(1)%ZoL” in the The NamelistGroup class represents namelist groups as “ VALUE ” group is being set to 0.25 using the statement a case - insensitive, ordered dictionaries. In addition to “ geometry['loc_rotor'][1]['ZoL'] = 0.25 ”.
namelist variables, they can also store namelist comments, The “ loc_rotor ” index identifies the variable within the comment lines and blank line s using special dictionary keys group. This variable is an array represented by a special list - that begin with “%.” All other keys represent namelist like object in RCOTOOLS that, following Fortran variable names. In addition to special methods for reading, convention, has the first item accessed using the index 1.
The “%” symbol in the origina l namelist file indicates that this array contains a structure which is represented as a † Tuples are a Python structure representing an immutable dictionary in the NamelistGroup and “ ZoL ” is the key sequence of items. These are defined in code as comma identifying which item in the structure is to be accessed.
separated values and variables between pa rentheses.
Listing 3: NDARC namelist input modified using RCOTOOLS namelist utilities. Changes from listing 1 are highlighted.
&JOB open_status=1, &END &DEFN action='ident', created='today', title='standard input', &END !######################### ##################################################### &DEFN action='read file', file='gen1000.list', &END &DEFN action='read file', file='airplane.list', &END !============================================================================== &DEFN quant='Geo metry', &END &VALUE ! fuselage reference loc_fuselage%FIX_geom='xyz', loc_fuselage%XoL=0.0, loc_fuselage%YoL=0.0, loc_fuselage%ZoL=0.0, ! scaled geometry (INPUT_geom=2); x +aft, y +right, z +up loc_cg%XoL=0.01, loc_cg%YoL=0.0, loc_cg%Z oL=0.0, loc_gear%XoL=0.0, loc_gear%YoL=0.0, loc_gear%ZoL= - 0.3, loc_rotor(1)%XoL=0.0, loc_rotor(1)%YoL=0.0, loc_rotor(1)%ZoL=0.25 , &END &DEFN quant='Cases', &END &VALUE title='Airplane', TASK_size=1, TASK_mission=1, TASK_perf=1, OUT_design=0, OUT _perf=0, OUT_geometry=0, OUT_aircraft=0, OUT_solution=1, &END &DEFN quant='Size', &END &VALUE title='design', nFltCond=1, nMission=1, &END &DEFN quant='Solution', &END &VALUE trace_size=1, trace_case=0, &END &DEFN action='endofcase', &END &DEFN actio n='endofjob', &END Table 1 : List of file viewers in RCO TOOLS.
The lines 14 and 15 insert a DEFN and a VALUE group, t ypical of NDARC input, into mynml Namelist using the Command Viewer Name “ inset_group ” mehthod. Finally, line 18 prints out the mynml Namelist as a string, which is shown in Listing 3.
niview NDARC Input Viewer Changes to the original namelist , other than formatting , are nsview NDARC Solution Viewer highlighted in yellow.
ciview CAMRAD II Input Viewer Input and Output File Viewers csview CAMRAD II Solution Viewer The application wrappers in RCOTOOLS allow specification of i nput and output variables using Fortran These viewers have nearly identical form and function, the namelist - style strings. These strings specify the sequence of primary difference between them is the type of data file that dictionary keys and list indices that identify the variables in they read and display. Because of their similarities, the use input and output data structures. Although these strings are of only one of these applications, the NDARC Input Viewer, constructed using a definitiv e logical sequence, generating is described below.
them manually is error prone and time consuming. To If RCOTOOLS has been installed using either the terminal address this problem, a set of Graphical User Interface (GUI) applications are provided that allow users to visually command “ python setup.py install ” or “ pytho n view and browse through existing input and output data f iles setup.py develop ,” then the NDARC Input Viewer to find variables and display namelist - style access strings can be launched from a terminal window using the niview that are used by the RCOTOOLS wrappers. The currently command. niview has an optional argument, filepath , available viewer applications and the commands used to call that is the path of the NDARC input file to be viewed, as them are listed in Table 1.
shown below: niview [ - h] [ - i filepath ] Figure 2 shows a typical NDARC Input Viewer window annotation (2). Checking “Whole word” will only find keys after a solution has been l oaded. Annotation (1) shows the where the search text matches entire words within th e key button used to load a new NDARC input file name. Clicking string. Checking “Values too” will extend the search to this button brings up a file browser which is used to identify include searches of the string equivalent of data structure an NDARC input text file to be loaded. If the GUI is values, numerical values included. A search is initiated by launched without a designated filepath , then this button pressing either the “Find Next” or “Find All” buttons shown is used to load one. Once a solution file is loaded, its in annotation (3). If any matches are found, they are contents can be browsed using a tree - view of the NDARC displayed in the panel below. Both the namelist access string data structures. Clicking on a data structure item will rev eal and the data structure value is displayed. Selecting a match, as shown in annotation (4) will display the namelist access all of its sub - structures. If the data structure contains a scalar value or an array of scalar values, that data is displayed. string and the data structure va lue in text fields as shown in Individual array items can also be viewed as a sub - structure annotation (5) and (6). The selected item will also be of an array. A structure variable is highlighted when selected displayed and selected in the main viewer window, as shown in Fig. 2 .
i n the GUI , as shown in annotation (2). The namelist string used to access this structure variable by RCOTOOLS is then displayed in the “ Namelist String ” field of the GUI window, as shown in annotation (3). This string is pre - selected and can be copied to the clipboard using the “Copy” menu item Figure 3: A typical niview “Find” dialog window with annotations for several elements.
NDARC Wrappers The NDARC core wrapper is defined in the rcotools.nadarc.ndarc_core module. Two Figure 2: A typical niview window with annotations for vers ions of the OpenMDAO wrappers for NDARC are several elements.
currently provided, one for OpenMDAO version 1.7+ and in the “File” menu or using the standard copy commands for preliminary one for OpenMDAO version 2+. The the operating system being used. If this structure contains OpenMDAO 1.7+ wrapper is defined in the scalar data or an array of scalar data, then that data (or rcotools.nadarc.ndarc_mdao1 module, while the array) is displayed in the “ Value ” field a s shown in OpenMDAO 2+ wrapper is defi ned in the annotation (4). To save time browsing through a data rcotools.nadarc.ndarc_mdao2 module.
structure looking for specific items, a find dialog can be NDARC Core Wrappers used, which is activated by clicking the “Find” button shown in annotation (5) .
N DARC uses internal data structures that are organized into a single hierarchical structure that is represented in outline Figure 3 shows a typical “Find” dialog window for th e form in Fig. 4 . The structure variable names presented in viewer applications. This example is for an NDARC input this f igure are the names used by NDARC and are intended data structure viewed with niview . This dialog will search to be descriptive of the structure content. Indentation level is for text in the key names for items in the data structure. The used to show which structures are contained in a higher - text is entered in the “Find Key Text” field as shown in level structure within the hierarchy. NDARC uses namelist annotation (1). The search is case - insensitive, so formatted input files to i nitialize the values in these capitalization does not matter. The search parameters can be structures and the NDARC solution output file is a modified using the “Matching” checkboxes as shown in representation of the final value of these data structures in a an ordered dictionary of NDARC data structures.
namelist format. However, the group names and the NdarcJob sequencing of the groups in the solution file namelist is ver y The simplest use of NdarcJob would be as follows: different from that of the input file namelists. One of the goals of the RCOTOOLS NDARC core wrappers is to hide import rcotools.ndarc.ndarc_core as nc the namelist formatting details as much as possible and # initialize NDARC job allow the user to reference the data in both input and output njob = nc.NdarcJob(namelist, execution_directory, files as members of a h ierarchical data structure similar to NDARC_executabl e_path, **args) what is presented in Fig. 4 . This mapping to the NDARC # *** make namelist modifications *** internal data structures is not exact, especially for NDARC # execute NDARC job input, which has some variations to handle specialized input exitonerror = njob.execute(output_file_path) features. However , the file viewers niview and nsview , The initialization argument, namelist , can be a previously described, can be used to visualize and Namelist object, a file object, a string containing namelist interrogate the RCOTOOLS data structures for NDARC input, a string repre senting a file path or the Python value, input and output files.
None . NDARC execution scripts can be used as input, since The rcotools.nadarc.ndarc_core module defines the parser will ignore lines of text that do not contain two classes, NdarcJob and NdarcSolution . The namelist information. If the default value of None is NdarcJob class is used to read in an NDARC job provided, then the namelist can be read in lat er using the namelist, modify the namelist and then execute the namelist.
NdarcJob.read() method. The Namelist object is The NdarcSolution class is used to read in and parse an accessible using the namelist attribute of an NdarcJob NDARC solution file (which is in namelist format) . After object.
parsing, the solution file variables can then be accessed as Figure 4: Hierarchical grouping of data structures used by NDARC. (F rom NDARC 1.12 documentation.)
updatedict = {'Geometry%loc_tail(1)%XoL': 1.10, The execution_directory parameter is the directory 'Geometry%loc_tail(1)%YoL': 0.00, in which the namelist NDARC will be executed. Before job 'Geometry%loc_tail(1)%ZoL': - 0.25, 'Rotor(1)%MODEL_in t': 0, execution, the current wo rking directory will be saved, the 'Rotor(1)%SET_limit_rs': 2, working directory will then be changed to 'Rotor(1)%fPlimit_rs': 1., 'Rotor(1)%incid_hub': 0.} execution_directory for job execution. Following job execution, the working directory will be changed back updates = getNdarcUpdate(updatedict, asString=True) to previous working directory. If no print(updates) execution_directory is provided, th en the parameter is set to the current working directory. This would print the following namelist string.
&DEFN quant='Geometry', &END The NDARC_executable_path is the path to the &VALUE loc_tail(1)%XoL=1.1, loc_tail(1)%YoL=0.0, NDARC executable. If the path is not provided, then the loc_tail(1)%ZoL= - 0.25, &END &DEFN quant='Rotor 1', &END executable path is set to variable &VALUE MODEL_int=0, SET_limit_rs=2, rcotools.NDARC_CMD , which is set in the fPlimit_rs=1.0, incid_hub=0.0, &END rcotools/rcotools.ini configuration file.
The namelist variable strings provided to the Once a namelist is input, the NdarcJob object has several getNdarcUpdate() f unction use the “ quant ” value for the DEFN/VALUE input pair as the first argument of the methods for interrogating and modifying the internal Namelist object before execution. Two methods are namelist variable string, preceding the first “ % ” symbol. If the quant value includes a number, such as “ Rotor 1 ”, provided to modify NDARC job namelist, updatecaseparams() and amendcase() . then the number i s converted to a namelist array index, for example: “ Rotor(1) ”. The niview viewer utility can be The updatecaseparams() method will update the last used to identify these namelist strings from an NDARC “Cases” namelist group in an NDARC input case using the input file. If the input file contains valid paths to imported dictionary updatedict . The targeted case is the last one files, the viewer will try to parse them a nd include their in the input namelist, unless a caseindex is provided. Its var ia bles in the data structure.
usage is “ njob.updatecaseparams( updatedict, According to NDARC input rules, Namelist definitions caseindex= - 1) ”.
in the addgroups value passed to amendcase() will The amendcase() method inserts namelist groups, override previous definitions. Given this rule , the following addgroups , at the end of a NDARC job input case . The two cautions are noted . First, for NDARC data structures targeted case is the last one in the input namelist, unless a like “ Rotor ”, amendments to the first instance should be caseindex is provided. Its usage is referred as “ Rotor(1) ” not just “ Rotor ”, as this will “ njob.amendcase(addgroups, ca seindex= - actually add a new rotor. Second, if the copy command is 1) ”.
used to create several objects, like “ Rotor ”, then the amendment must sp ecify updates to each copy for which the To facilitate defin ing the namelist groups for use as the update is desired.
addgroups variable, ndarc_core provides the getNdarcUpdate() function. This function takes a As a final note, if the NdarcJob methods do not fully dictionary of key , value pairs, where key is a namelist provide the wanted functionality, one can work directly with variable string and value is the de sired corresponding value.
the namelist attribute of an NdarcJob object using This function converts these (the pairs??) to a Namelist Namelist class method.
for updating an NdarcJob using amendcase() . The following code shows how an example input dictionary is converted to namelist groups. (Note that an OrderedDict is not neces sary, it (what?) just preserves the variable order in the resulting namelist.)
NdarcS olution should be represented as an array. As new NDARC data The NdarcSolution class reads and converts an structures are developed, they can be simply added to this NDARC solution file to an ordered dictionary representing dictionary in the source code.
data for NDARC data structures as shown in Fig . 4 .
Once a solution file is loaded, data structure values can be NdarcSolution pars es the namelist data in an NDARC accessed using the retrieve() method, as follo ws: solution file in two passes : the first pas s identifies major import rcotools.ndarc.ndarc_core as nc sections in the solution file and the second pass performs soln = nc.NdarcSolution(solution_path) value = soln.retrieve(access_query) detailed namelist parsing of these sections. To save execution time, detailed namelist parsing is only performed The access query identifies a variable in the solution, where on requested sections. This process is referred to as “lazy” the variable is identified by either a namelist variable string eval uation. Loading an NDARC solution file for lazy or a list o f ( key , index ) tuples. The ( key , index ) tuples are evaluation would be done using the code used to traverse the solution data structure to yield the “ NdarcSolution(nmlpath, dolazy=True) .” requested variable value. An example access string would be: To properly parse an NDARC solution file, the parser needs information on the top - level data structures in the solution.
Size%SizeMission(1)%MissParam%WFUEL_MISS(1) The dat a structures Size, OffDesign, Performance and The corresponding list of ( key , index ) tup les would be: FltState have specific parsing procedures, but the other top - [('Size', None), ('SizeMission', 0), level data structures are parsed in a generic fashion. The (MissParam, None), ('WFUEL_MISS', 0)] currently defined additional top - level data structures are For the NdarcSolution object, soln , this would be the provided in the dictionary, _to plevel , which is defined same as: in the ndarc_core module and is presented in Listing 4.
soln['Size']['SizeMission'][0]['MissParam'] This (what?) is a dictionary of key , value pairs, where the ['WFUEL_MISS'][0] key is the data structure name and value is a bool (boolean?)
indicating if the structure can have multiple instance s and Listing 4 : Dictionary defining NDARC data structures, in rcotools.ndarc.ndarc_core.
# NDARC top level data structures # Specifiy available NDARC data structures, (Name, isArray) # Note: Size, OffDesig n, Performance and FltState are handled seprately _toplevel = Odict([('Cases', False), ('MapEngine', False), ('MapAero', False), ('Solution', False), ('Cost', False), ('Emissions', False), ('Aircraft', False), ('Systems', False), ('Fuselage', False), ('LandingGear', False), ('Rotor', True), ('Wing', Tr ue), ('Tail', True), ('FuelTank', True), ('Propulsion', True), ('EngineGroup', True), ('JetGroup', True), ('ChargeGroup', True), ('EngineModel', True), ('EngineParam', True), ('EngineTable', True), ('RecipModel', True), ('CompressorModel', True), ('MotorModel', True), ('JetModel', True), ('FuelCellModel', True), ('SolarCellModel', True), ('BatteryModel', True), ]) prepended by “ % ”. So to get the NDARC OpenMDAO Wrappers NdarcWrapper.nw_.success flag, the Two versio ns of the OpenMDAO wrappers for NDARC are ndarc_access_string would be “ %success ”. Another currently provided, one for OpenMDAO version 1.7+ and a example would be to use the ndarc_access_string w ould be preliminary one for OpenMDAO version 2+. The “ %converged ” to get the state of the OpenMDAO 1.7+ wrapper is defined in the NdarcWrapper.nw_.converged flag.
rcotools.nadarc.ndarc_mdao1 module, while the OpenMDAO 2+ wrapper is defi ned in the The optional meta_data_dict items are the optional rcotools.nadarc.ndarc_mdao2 module. The parameters passed to a call to OpenMDAO 2+ wrapper is still in the early stages of NdarcWrapper.add_param( openmdao_variable_nam development, so only the OpenMDAO 1.7+ wrapper will be e, val=<object object>, **kwargs ) for inputs or to presented.
N darcWrapper.add_output( openmdao_variable_na me, val=<object object>, **kwargs ) for outputs, where key The ndarc_mdao1 module defines the class is the ndarc_access_string . If the meta_data_dict is not NdarcWrapper , which is subclass of the OpenMD AO provided or if the meta_data_dict does not include the key Component object and serves as a wrapper for NDARC.
“ val ” then meta_data_dict[‘val’] = 0.0 is The NdarcWrapper initialization method reads in an assumed. Note that while OpenMDAO variables can be NDARC namelist, makes user specified modifications and mapped to more than one NDARC input value, there has to then sets up OpenMDAO inputs and outputs. The be a one - to - one mapping of OpenMDAO variables to NdarcWrapper.solve_nonlinear() method NDARC output (or solution) variables.
modifies th e NDARC job namelist based on OpenMDAO inputs, executes the NDARC job and then passes on An example showing how the NdarcWrapper can be selected outputs from the NDARC solution file to used for con strained optimization using OpenMDAO 1.7 is OpenMDAO. Most of the initialization parameters are presented in Listing 5. This example is based on an example stored as attributes in NdarcWrapper.nw_ to avoid provided in the RCOTOOLS distribution that models a 90 - potential namesp ace conflicts with attributes or methods in passenger, tandem, compound helicopter. The inputs to future versions of the Component object.
NDARC are wing loading and disk loading, and the outputs The simplest initialization of an NdarcWrapper object from NDARC are empty weight, mission fuel, engine would be as follows: power, rotor aspect ratio and rotor radius. The outputs for empty weight, mission fuel and engine power are passed to NdarcWrapper(jobfile, inputs, outputs) a utility function, CostFunction , that produces a single weight ed value as a cost function. The values for rotor The parameter jobfile is a n NDARC job file path, aspect ratio and radius are used as constraints on the inputs is a list of a OpenMDAO variable inputs and their solution. A line - by - line description of this example is mappings to NDARC input variables and outputs is a list provided in the RCOTOOLS documentation.
of the OpenMDAO variable outputs and their mappings to NDARC solution variables. The parameters inputs and the outputs are list s of ( openmdao_variable _name , ndarc_access_string ) tuples or ( openmdao_variable_name , ndarc_access_string , meta_data_dict ) tuples.
The ndarc_access_string items in these tuples are specified as Fortran namelist variable names for values in the NDARC data structure. For data stru ctures that have multiple instances, such as Rotor, they are referenced using an index in prerentheses. For example, for two rotors you would have a Rotor(1) and Rotor(2) data structures.
Attributes of the NdarcWrapper object can also be specified by ndarc _access_string . For these, the variable name is the attribute name (from NdarcWrapper.nw_ ) Listing 5 : Example using NdarcWrapper under OpenMDAO 1.7 for constrained optimization.
from openmdao.api import IndepVarComp, Problem, Group from openmdao.api import ScipyOptimizer from rcotools.ndarc.ndarc_mdao1 import NdarcWrapper from rcotools.utils.mdao1 import CostFunction # Setup NdarcJob component jo bfile = '/path/to/tc90_size_init.job' inputs = [ ('wingload', 'Wing(1)%wingload'), ('diskload', 'Rotor(1)%diskload'), ('diskload', 'Rotor(2)%diskload'), # 'diskload' sets two NDARC inputs ] outputs = [ ('w eightempty', 'Aircraft%Weight%WE'), ('miss_fuel', 'Size%SizeMission(1)%MissParam%WFUEL_MISS(1)'), ('engine_power', 'EngineGroup(1)%PENG'), ('aspect_ratio', 'Rotor(1)%AspectRatio'), ('radius', 'Rotor(1)%Radius'), ] NdarcJob = NdarcWrapper(jobfile, inputs, outputs) # Setup cost function component (name, weight) for each factor factors = [('weightempty', 1.0), ('miss_fuel', 5.0), ('engine_power', 12.5), ] cost = CostF unction(factors) # Set up the MDAO Problem top = Problem() root = top.root = Group() # Add components to the OpenMDAO problem root.add('p1', IndepVarComp('wingload', 100.0)) root.add('p2', IndepVarComp('diskload', 11.0)) root.add('ndarc', NdarcJob) root.a dd('ndarc_cost', cost) # Make connections between components root.connect('p1.wingload', 'ndarc.wingload') root.connect('p2.diskload', 'ndarc.diskload') root.connect('ndarc.weightempty', 'ndarc_cost.weightempty') root.connect('ndarc.miss_fuel', 'ndarc_cos t.miss_fuel') root.connect('ndarc.engine_power', 'ndarc_cost.engine_power') # Set up optimizer SLSQP or COBYLA top.driver = ScipyOptimizer() top.driver.options['optimizer'] = 'SLSQP' # Set the design variables top.driver.add_desvar('p1.wingload', lower=7 0.0, upper=120.0) top.driver.add_desvar('p2.diskload', lower=6.0, upper=15.0) # Set the objective to be optimized top.driver.add_objective('ndarc_cost.cost') # Set the design constraint variables top.driver.add_constraint('ndarc.radius', upper=37.0) top. driver.add_constraint('ndarc.aspect_ratio', upper=20.0) # Setup and run the problem top.setup() top.run() Monitoring NDARC Run Convergence run. The results from a job that did not converge may still be N DARC can potentially run succes sfully, but not return a reasonable, but one should be aware about how they might converged solution. (RCOTOOLS considers an NDARC run affect results from an optimization. Figure 5 shows the to be successful if it doesn’t generate an error and there are optimization steps for the example op timization presented in no “NaN” values in the solution.) The NdarcWrapper Listing 5 . In this figure, cost is a function of the design class has a flag, NdarcWrapper.nw_.converged , that variables wingload and diskload. Th e background contour is determines co nvergence from NDARC output files for each based on a 20x20 grid of solutions, with circles plotted at calculates performance, loads, vibration, response, and stability for a wide variety of rotorcraft over for p rescribed operating conditions .
The CAMRAD II application wrappers provided in RCOTOOLS are intended to be “ light - weight, ” with minimal computational overhead. CAMRAD II is written in the Fortran programming language and compiles to three executables, CAMRA DII, INPUT and OUTPUT, which are listed in Table 2. The paths to these executables are saved in the rcotools.CAMRAD dictionary using the keys Figure 5: Optimization results provided for an NDARC job camradii , input_camrad and output_camrad , running under OpenMDAO superimposed on a contour plot respectively. The CAMRADII executable performs the of solution results over the design space. Filled red circles rotorcraft analyses, while the INPUT executable is used to represent the wingload and diskload inputs resulting in non - produce binary files representing inputs and tables for use converged solutions.
by CAMRADII. The OUTPUT executable is used to the wingload and diskload values used for each soluti on.
examine CAMRAD II plot file outputs. The OUTPUT The NDARC solutions that did not converge are represented executable is not currently used or supported by by circles filled in red. The contour lines near solutions that RCOTOOLS.
did not converge are relatively smooth, indicating that their Table 2 : CAMRAD II Executables results are consistent with nearby solutions that did converge. Figu re 5 implies that gradient - based optimization Name Description Path Key runs with evaluations that are only occasional near non - CAMRADII Rotorcraft Analysis camradii converged evaluations may still provide good results.
INPUT Input and Table File Preparation input_camrad OUTPUT Plot File Examination output_camrad The orange dashed line shows the steps in an optimization Use of the RCOTOOLS CAMRAD wrappers assumes a that is constrained by havin g a solution with a radius of less working knowledge of CAMRAD II, as viable CAMRAD II than 37 feet. The solution space traversed during inputs are required as a starting point. CAMRAD II input optimization is relatively free of non - converged solutions so typically consists of separate files for tables, basic shell the result should be good ; the solution was confirmed by ‡ input and job input. The INPUT executable is used to repeating the optimization with different starting c onditions.
generate binary files for tabl es and basic shell input that are On the other hand, an unconstrained optimization (see to be read in by the CAMRADII executable based on ndarc_tc90_unconstr.py in the RCOTOOLS distribution ) commands given in the job input file.
probably would be suspect as the minimum cost function region contains numerous non - converged solutions.
Similar to the RCOTOOLS NDARC wrappers, the Repeat ed optimization runs using different starting RCOTOOLS CAMRAD II wrappers consist of “core” conditions resulted in the number of evaluations required wrappers which are generic Python wrappers t o read, varying dramatically with the final results hav ing significant modify and execute program input files and to read and variation. Often, convergence will be successful if some extract data from solution files. These do not rely on or use iteration input parameters changes, so such changes should OpenMDAO software. A specific, OpenMDAO wrapper is be considered if convergence may be affecting optimization also provided, which inherits from OpenMDAO objects.
results.
This wrapper is built on to p of the “core” wrappers, but is designed to interface with the OpenMDAO optimization CAMRAD Wrappers CAMRAD II is a comprehensive helicopter analysis tool 2,3 developed by John son Analytics . CAMRAD II performs ‡ CAMRAD II utilizes “shell” and “core” inputs, where aeromechanical ana l yses for complex rotorcraft systems “shell” inputs simplify the definition of typical system using a com bination of advanced technology models , models and “core” inputs allow for more detailed and multibody dynamics, nonlinear finite elements, structural flexible system model definitions.
dynamics, and rotorcraft aerodynamics. CAMRAD II architecture. The OpenMDAO wrapper was designed to be Finally, any “:” characters at the end of the key are stripped.
flexible and to work “out - of - the - box” for most needs. For example: RCOTOOLS provides t wo command - line functions that • The namelist input “ &NLDEF read and di splay CAMRAD II input and output files in a class=’ROTOR’,type=’FLEXBEAM’, Graphical User Interface (GUI) to help users identify name=’ROTOR 1’,&END ” would be represented by references to CAMRAD II input and output variables which the key “ ROTOR:FLEXBEAM:ROTOR 1 ”.
are used in the CAMRAD wrappers. These are the • The namelist input “ &NLDEF CAMRAD Input Viewer ( ciview ), which is instantiated class=’FLUTTER ROTOR’,name=’ROTOR us ing the ciview command from a terminal or console, 1’,&END ” would be r epresented by the key and the CAMRAD Solution Viewer ( csview ), which is “ FLUTTER ROTOR::ROTOR 1 ”. (Note the two instantiated using the csview command. Their use is consecutive colons in the middle of the key.)
similar to the NDARC Input Viewer, that was described in • The namelist input “ &NLDEF the Utilities section.
class=’FLUTTER’, &END ” would be represented by the key “ FLUTTER ”.
CAMRAD Core Wrappers CamradJob objects have a jobtype attribute and an Th e CAMRAD core application wrapper is defined in the exed ict attribute. The jobtype attribute should be camrad_core module, which defines several functions either camradii or camradii_input to specify which and classes. The two principal classes providing the core CAMRAD II executable to use. This attribute is set wrapper interface are CamradJob and automatically by the parseCamradInput() function if CamradSolution .
the input is a csh file for a CAMRAD job. The attribute can The CamradJob class is usually not instant iated directly, also be set directly or overridden when using the execute() instead a CAMRAD II job file is read and processed by the method. The exedict attribute can also be set directly or parseCamradInput() function. This function takes a overridden when using the execute() method .
CAMRAD II job file as an argument and parses the contents exedict defaults to the CAMRAD dictionary specified in to return either a CamradDict or CamradJob object. A the rcotools.ini file. The simp lest use of CamradJob is only re turned if the input file contains a parseCamradInput() and CamradJob would be as NLJOB namelist group. Once a CamradJob is created, follows: modifications can be made and then the object can be import rcotools.camrad.camrad_core as cc executed to produce CAMRAD II output files. Both CamradDict and CamradJob are nested dictionary type # parse CAMRAD II job file and # produce the CamradJob object, 'job' objects that re present the namelist input in the source files job = cc.parseCamradInput(infpath) used to initiate them. The dictionary keys for CamradDict and CamradJob objects are based on the NLDEF namelist # *** make namelist and job mods *** groups used to define them. There are four optional # ex ecute the CAMRAD II job variables used in NLDEF groups, CLASS , TYPE , NAME and exitonerror = job.execute() ACTION . The key will be of the form “ CLASS : TYPE : NAME : ACTION ” which is populated by the values assigned to each variable. If any of these variables are undefined, then they are represented by an empty string.
CamradSolution objects are nested , dictionary - type Not all sections of CAMRAD solution output files have objects that represent parsed values from CAMRAD II parsers defined and the existing parsers are not all analysis output files. The dictionary keys are based on thoroughly vetted . (Fully vetted means that each variable section titles and variable names in the an alysis output files. output in a section has been verified to be included in parsed data structure . ) Users are encouraged to submit new parser These outputs are formatted to be easily read and requests and submit bug reports if parser errors are found.
understood by human readers, not computer algorithms, so section titles and variable names are very descriptive. This Table 3 provides a list of CAMRAD II solution output results in dictionary keys that can be quite verbose. A simple sections and the current status of parsers for those sectio ns.
exam ple of how to use CamradSolution is shown in Listing 6.
Listing 6 : Use of CamradSolution to access output data.
import rcotools.camrad.camrad_core as cc # Parse the CAMRAD II solution solution file, 'sample.out' soln = cc.CamradSolution('sample.out') # Access and print the radius of Rotor 1 radius = soln.getByAccesstext('CASE 1%SUMMARY%CONFIGURATION%ROTOR 1%RADIUS (FT)') print(' \ nThe radius of Rotor 1 in the output summary is: %f (FT)' % radius) Table 3 : List of CAMRAD II output sections with current parser status.
CAMRAD II Solution Section Parser Status JOB DESCRIP TION Generic Parser - Not Vetted CASE n LABELS Custom Parser - Vetted ANALYSIS TASKS Custom Parser – Vetted CONFIGURATION Custom Parser – Vetted OPERATING CONDITION Custom Parser – Vetted CONTROL SETTINGS Custom Parser – Vetted TRIM SOLUTION PROCEDURE No Parser FLUTTER EQUATIONS No Parser FLUTTER SOLUTION PROCEDURE No Parser SHELL INPUT DATA NLDEF/NLVAL values G eneric Parser - Not Vetted CORE INPUT DATA No Parser TABLE INPUT DATA No Parser SYSTEM AND FUNCTIONALITY No Parser TRIM CONVERGENCE No Parser TRIM SOLUTION ROTORCRAFT Custom Parser - Partially Vetted ROTOR n Cust om Parser - Partially Vetted ROTOR BLADE LOAD SENSOR Custom Parser - Partially Vetted AIRFRAME SENSOR ROTOR Custom Parser - Partially Vetted ROTOR HUB LOAD SENSOR Custom Parser - Partially Vetted ROTOR BLADE POSITION SEN SO Custom Parser - Partially Vetted ROTOR WING SENSOR Custom Parser - Partially Vetted ROTOR CONTROL LOAD SENSOR Custom Parser - Partially Vetted ROTOR INTVEL TRANSFORM Custom Parser - Partially Vetted ANALYSIS FRAMES No Parser FLUTTER SOLUTION No Parser ANALYSIS OF SYSTEM OF CONSTANT... No Parser CAMRAD OpenMDAO Wrapper The optional meta_data_dic t items are parameters passed to a call to The CAMRAD II OpenMDAO 1.7 application wrapper is C amradWrapper.add.param ( openmdao_variable_na defined in the camrad_mdao1 module. This module me, val=<object object>, **kwargs ) for inputs or to currently implements the class CamradWrapper , which is CamradWrapper.add_output ( openmdao_variable_na subclass of the OpenMDAO Component object, that me, val=<object object>, **kwargs ) for outputs, where the serves as a wrapper for CAMRAD. The CamradWrapper key is the camrad _access_string . If the meta_data_dict is initialization reads in a CAMRAD job file, makes user not provided or if the meta_data_dict does not include the specified modifications and then sets up OpenMDAO inputs key ‘ val ’, then meta_data_dict[‘val’] = 0.0 .
and outputs.
OpenMDAO variables can be mapped to more than one CAMRAD input value, but there has to be a one - to - one The CamradWrapper.solve_nonlinear() method mapping of OpenMDAO variables to CAMRAD output (or modifies the CAMRAD job file based on OpenMDAO solution) variables. An example showing the specification of inputs, execute s the CAMRAD job and then passes on inputs and outputs for creating a wrapper around an selected outputs from the CAMRAD solution file to CAMRAD II analysis job is given Listing 7.
OpenMDAO. Most of the initialization parameters are stored as attributes in self.cw_ to avoid potential A simple example for using the CAMRAD OpenMDAO 1.7 namespace conflicts with attributes or methods in future wrappe r is provided by the script in Listing 8. The versions of the OpenMDAO Component object.
CamradWrapper class has numerous customization options that are set during initialization, which are detailed The essential parameters needed to initialize a in the source code documentation.
CamradWrapper object are a CAMRAD II job file path, a definition of the OpenMDAO variable inputs and their mappings to CAMRAD II input variables and a definition of the Open MDAO variable outputs and their mappings to CAMRAD II solution variables. Both the inputs and the outputs are specified as a list of ( openmdao_variable_name , camrad_access_string ) tuples or ( openmdao_variable_name, camrad_access_string , meta_data_dict ) tup les.
The camrad_access_string items are specified as Fortran namelist variable names for values in the CAMRAD input or output data structures. These can be determined by using the ciview and csview GUI utilities. Attributes of the CamradWrapper object can also be specified by camrad_access_string . For these, the variable name is the attribute name (from CamradWrapper.cw_ ) prepended by “ % ”. So to get the CamradWrapper.cw_.success flag , the camrad_access_string would be “ %success ”.
Listing 7 : Use of CamradWrapper.
from rcotools.camrad.camrad_mdao1 import CamradWrapper inputs = [ ('radius', 'CASE 1%SHELL%ROTOR:STRUCTURE:ROTOR 1%RADIUS', {'val': 20.0}), ('twistl', 'CASE 1%SHELL%ROTOR:STRUCTURE:ROTOR 1%TWISTL', {'v al': - 10.0}), ] outputs = [ ('lift2drag', 'CASE 1%TRIM SOLUTION:ROTOR 1 PERFORMANCE%PERFORMANCE%L/D'), ('Mx', 'CASE 1%TRIM SOLUTION:ROTOR 1 PERFORMANCE%ROTOR FORCES AND MOMENTS%SHAFT AXES%ROLL MOMENT%MX'), ('My', ' CASE 1%TRIM SOLUTION:ROTOR 1 PERFORMANCE%ROTOR FORCES AND MOMENTS%SHAFT AXES%PITCH MOMENT%MY'), ('lift', 'CASE 1%TRIM SOLUTION:ROTOR 1 PERFORMANCE%ROTOR FORCES AND MOMENTS%WIND AXES%LIFT%L'), ('eqdrag', 'CASE 1%TRIM SOLUTION:ROTOR 1 P ERFORMANCE%PERFORMANCE%ROTOR EQUIV DRAG%D=P/V+X'), ] cjob = CamradWrapper("path/to/jobfile", inputs, outputs) Listing 8 : Example use of CamradWrapper with OpenMDAO 1.7.
from openmdao.api import IndepVarComp, Problem, Gro up from rcotools.camrad.camrad_mdao1 import CamradWrapper # Setup the CamradJob inputs and outputs inputs = [ ('radius', 'CASE 1%SHELL%ROTOR:STRUCTURE:ROTOR 1%RADIUS', {'val': 20.0}), ('twistl', 'CASE 1%SHELL%ROTOR:STRUCTURE:ROTOR 1%TW ISTL', {'val': - 10.0}), ] outputs = [ ('lift2drag', 'CASE 1%TRIM SOLUTION:ROTOR 1 PERFORMANCE%PERFORMANCE%L/D'), ('Mx', 'CASE 1%TRIM SOLUTION:ROTOR 1 PERFORMANCE%ROTOR FORCES AND MOMENTS%SHAFT AXES%ROLL MOMENT%MX'), ('My', 'CASE 1%TRIM SOLUTION:ROTOR 1 PERFORMANCE%ROTOR FORCES AND MOMENTS%SHAFT AXES%PITCH MOMENT%MY'), ('lift', 'CASE 1%TRIM SOLUTION:ROTOR 1 PERFORMANCE%ROTOR FORCES AND MOMENTS%WIND AXES%LIFT%L'), ('eqdrag', 'CASE 1%TRIM SOLUTION :ROTOR 1 PERFORMANCE%PERFORMANCE%ROTOR EQUIV DRAG%D=P/V+X'), ] # Create NdarcWrapper component cjob = CamradWrapper("/path/to/job/file", inputs, outputs) # Set up MDAO Problem top = Problem() root = top.root = Group() # add components root.add ('camrad', cjob) root.add('p1', IndepVarComp('radius', 20.0)) root.add('p2', IndepVarComp('twistl', - 10.0)) # add connections root.connect('p1.radius', 'camrad.radius') root.connect('p2.twistl', 'camrad.twistl') top.setup() # Run the problem and print in puts & outputs top['p1.radius'] = 21.0 # Set a new radius top.run() print('Inputs:') print(' Rotor Radius = %0.3f (ft)' % top['p1.radius']) print(' Rotor Linear Twist = %0.3f (deg)' % top['p2.twistl']) print('Outputs:') print(' L/D = %.4f' % top[ 'camrad.lift2drag']) print(' Roll Moment = %.4f (ft - lb)' % top['camrad.Mx']) print(' Pitch Moment = %.4f (ft - lb)' % top['camrad.My']) print(' Lift = %.0f (lb)' % top['camrad.lift']) print(' Equivalent Drag = %.0f (lb)' % top['camrad.eqdrag']) to more users, possibly as part of the NDARC software Concluding Remarks distribution.
RCOTOOLS has already proven to be a useful to ol for References including NDARC and CAMRAD II in multi - disciplinary design and analysis of rotorcraft . Further improvements and Johnson, W., NDARC - NASA Design and Analysis of additions are expected as development continues. Currently, Rotorcraft , NASA TP - 2015 - 218751, April 2015.
one or two RCOTOOLS updates are distributed to users Johnson, W., “Technology Drivers in the Develo pment of each month. Both the NDA RC and the CAMRAD II CAMRAD II,” American Helicopter Society wrappers are actively being used, with users often Aeromechanics Specialists Conference , San Francisco, CA: 1994.
submitting bug reports and/or feature requests. A wrapper Johnson, W., “Rotorcraft Aeromechanics Applications of a for the Numerical Propulsion System Simulation (NPSS) is Comprehensive Analysis,” AHS International Meeting on under development and wrappers for other design tools may Advanced Rotorcraft Technology and Disaster Relief , also be co nsidered for future additions to RCOTOOLS. The Gifu, Japan: 1998.
source code is extensively documented and a user’s guide is Johnson, W., Moodie, A. M., and Yeo, H., “Design and provided with the distribution package . This documentation Performance of Lift - Offset Rotorcraft for Short - Haul is available in both HTML and PDF formats. (The PDF Missions,” American Helicopter Society Future Vertical version is currently over 100 pages in length.) RCOTOOLS Lift Aircraft Design Conference , San Francisco, CA : 2 012.
runs under both Python 2.7 and 3 and is tested on the Heath, C. M., and Gray, J. S., “OpenMDAO: Framework Windows 10, MacOS and Linux operating systems. for Flexible Multidisciplinary Design, Analysis and Optimization Methods,” AIAA Journal , vol. 51, 2013, pp.
RCOTOOLS distribution is currently limited to users in the 2380 – 2394.
US Government or working on US Government contracts.
Avera, M., and Singh, R., “OpenMDAO/NDARC In the future, RCOTOOLS is expected to be made available Framework for Assessing Performanc e Impact of Rotor Technology Integration,” American Helicopter Society Sinsay, J. D., Hadka, D. M., and Lego, S. E., “An 70th Annual Forum , Montréal, Québec, Canada: 2014. Integrated Design Environment for NDARC,” AHS Sinsay, J. D., and Alonso, J. J., “Optimization of a Lift - Technical Meeting on Aeromechanics Design for Vertical Offset Compound Helicopter in a Multidisciplinary Lift , San Francisco, CA : 2016.
Analysis Environment,” A merican Helicopter Society 71st Lytle, J. K., The Numerical Propulsion System Simulation: Annual Forum , Virginia Beach, VA : 2015. An Overview , NASA TM - 2000 - 209915, Jun e 2000.