XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX''"> Aerodynamic and Aeroelastic Databases
While MSC.Nastran has a very sophisticated automated restart capability, in aeroelastic analysis, it is often the case that the aerodynamic data are updated relatively infrequently relative to the structural data. Also, once the computationally intensive unit solutions are obtained, they can be reused in TRIM analysis very rapidly (nearly interactively) to generate distributed trimmed loads.
While MSC.Nastran’s NDDL, FMS and DMAP have always allowed the reuse of these data, it was not a trivial matter to define the collection of datablocks that would constitute the minimal archival set for reuse that also had the appropriate functionality (supply all the requisite pieces). Further, to reuse the data blocks (as opposed to automated restart), the DMAP needs to “look” for the data blocks and, if already present, explicitly branch around the “creation” step.
In MSC.Nastran V70.7 (as part of the FlightLoads development), the NDDL and DMAPs associated with SOL 144 were updated to create two collections of data: an aerodynamic database and an aeroelastic database. These collections are implemented in such a way as to simplify the user input requirements, remain compatible with automated restart and allow data “reuse” using the DBLOCATE technique.
The modifications made are primarily in DMAP and, in particular, NDDL. A hierarchy of aerodynamic and aeroelastic paths was defined in NDDL that allows the user to archive and reuse the aerodynamic and aeroelastic data (somewhat independently). This is accomplished by created two new LOCATION values in the NDDL (and DMAP): the ADB and the AEDB. Aerodynamic data (completely independent of structural data) is associated with the ADB and aeroelastic data (coupling a particular aerodynamic model with the current structure and/or structural boundary condition) is associated with the AEDB. To direct the aerodynamic data onto a particular DBSET, one simply adds the appropriate INIT and ASSIGN statements and includes in bulk data the definition of the location parameters (PARAM,ADB,logical_adb_name).
Paths
A hierarchy of paths has been established for aerodynamic and aeroelastic data. These paths start at a minimal set at the top level and expand in scope as we move lower in the hierarchy. The top level is “geometry,” recognizing that the user has ultimate control and may choose any relationship among disparate instances at this level. In other words, two distinct “geometries” may be the same vehicle with differing mesh topologies or it may be completely unrelated data or even duplicate data.
While the NDDL language cannot support PATHs that include other PATHs, the PATHs will be shown as additions to or unions with other PATHs to facilitate understanding of the hierarchy. In NDDL, they are, of necessity, expanded.
For aerodynamic data, the basic path is:
path aegeom aeconfig,symxy,symxz,APRCH,HIGHQUAL $
path aegeomf modltype + aegeom $
representing a (centroid and corner point) mesh topology. Notice that symmetry is included, meaning the mesh is reinstantiated for each symmetry option. This redundancy eliminates a layer in the hierarchy for almost no cost (the number and size of data blocks that would be a function only of AECONFIG is very small) and so has been adopted.
Geometry and Mach dependence:
PATH aegm IMACHNO + aegeom $
Geometry, Mach and Reduced Frequency:
PATH aegmk ikbar + aegm $
These paths handle all the steady and unsteady datablocks that comprise the ADB. These datablocks are a function only of the aerodynamics. No structural data are involved with one exception that has not been addressed:
Note: | MSC.Nastran aeroelastic analyses all assume that the basic coordinate system of the structure and that of the aerodynamic model are the same. This is in contrast to superelements, in which each superelement has its own basic system that is then related to the overall solution basic at the time the model components are assembled. This limitation has not yet been addressed. |
The aeroelastic paths are essentially the union of the aerodynamic paths with the appropriate structural path. As a consequence, there are many more aeroelastic paths, but most are dealing with structural sets:
PATH aepeid PEID,AUXMID + aegeom $
PATH aeaset a-set + aegeom $
PATH aelset l-set + aegeom $
and a similar set that includes Mach number and/or dynamic pressure:
PATH aegsetq g-set + aegm + iq, iqr $
PATH aeasetq a-set + aegm + iq, iqr $
PATH aelsetq l-set + aegm + iq, iqr $
PATH aelsetm l-set + aegm $
and, finally, for unsteady aeroelastic analysis in modal coordinates, the generalized forces must be qualified by the modal reduction qualifiers and the aerodynamic paths:
PATH aegenf aegmk + a-set + modal method + TFL/damping/etc. $
PATH aegenfl aegeom + generalized boundary condition $
PATH aegenfs aegeom + superelement generalized boundary $
Aerodynamic Database
The aerodynamic database consists of the following data blocks and paths. All the datablocks use the ADB location parameter.
Data Block | Path |
ACPT | AEGEOM |
AECOMP | AEGEOM |
AECSTM | AEGEOM |
AERO | AEGEOM |
AMSPLINE | AEGEOM |
CONTROL | AEGEOM |
D1JK | AEGEOM |
DJX | AEGEOM |
FAJE | AEGEOM |
HMKT | AEGEOM |
TRX | AEGEOM |
WGJ | AEGEOM |
SRKT | AEGEOM |
GDKSK | AEGEOM |
GPKSK | AEGEOM |
AEBGPDTS | AEGEOMF |
AEBOXS | AEGEOMF |
AEUSETS | AEGEOMF |
D2JK | AEGM |
LAJJ | AEGM |
QKINTER | AEGM |
QKKS | AEGM |
QKPRESS | AEGM |
QKX | AEGM |
UAJJ | AEGM |
AJJ0 | AEGMK |
AJJT | AEGMK |
LAJJT | AEGMK |
UAJJT | AEGMK |
DJK | AEGMK |
SKJ | AEGMK |
Note: | The aerodynamic data are archived without the weighting and correction matrix WKK. These weighting data need to be included in the bulk data on each reuse. |
Aeroelastic Database
The aeroelastic database then consists of the following datablocks and paths. All these datablocks use the AEDB location:
Data Block | Path | Data Block | Path | Data Block | Path |
GDKA | AEASET | | | | |
AEQGDKA | AEASETQ | AEQGDKL | AELSETQ | GPGK | AEPEID |
KAAX | AEASETQ | URLR | AELSETQ | GDGK | AEPEID |
UUXAX | AELSETQ | ERHM | AELSETQ | SPLINE | AEPEID |
UXAX | AELSETQ | EUHM | AELSETQ | PGR | MLL |
GPGK0 | AEGEOM | HP | AELSETQ | | |
GDGK0 | AEGEOM | HP0 | AELSETQ | | |
PERGX | AELSETQ | IUXLR | AELSETQ | | |
PERKSX | AELSETQ | KRZX | AELSETQ | | |
PEUGX | AELSETQ | KSAZX | AELSETQ | | |
PEUKSX | AELSETQ | RHMCF | AELSETQ | | |
PIRGX | AELSETQ | RSTAB | AELSETQ | | |
PIUGX | AELSETQ | RUXLX | AELSETQ | | |
PRGX | AELSETQ | Z1ZX | AELSETQ | | |
PRKSX | AELSETQ | ZZX | AELSETQ | | |
UERKSX | AELSETQ | | | | |
UERGX | AELSETQ | | | | |
UEUKSX | AELSETQ | | | | |
UEUGX | AELSETQ | | | | |
Note: | Of necessity, the aeroelastic data includes the weighting matrix corrections. |
Inputs and Outputs
To make effective use of the aerodynamic and/or aeroelastic database for reuse, you must have some familiarity with the FMS statements of MSC.Nastran. No new functionality has been introduced, it is merely that a coherent collection of paths and location parameters have been defined to allow basic FMS statements to redirect whole, consistent collections of data to particular DBSETs for reuse. Restart does not require nor is it affected by these modifications.
In particular, you should acquaint yourself with the INIT and ASSIGN statements in the MSC.Nastran Quick Reference Guide, and some familiarity with the concepts in NDDL would be helpful.
In the Bulk Data Section, you must define the ADB and AEDB location PARAMETERs (which are just PARAMs, like any other) to have the logical name of the DBSET to which you want the aerodynamic and aeroelastic (respectively) datablocks to be placed. These PARAMs are only needed on the job submittal(s) that create(s) the database.
To create both an aerodynamic and aeroelastic database, for example:
INIT, MASTER, LOGICAL=(MASTER(1000MB))
ASSIGN MASTER=’adb144.master’
INIT, DBALL, LOGICAL=(DBALL1(1000MB))
ASSIGN DBALL1=’adb144.dball’
INIT, myADB, LOGICAL=(myADB(1000MB))
ASSIGN myADB=’adb144.adb’
INIT, myAEDB, LOGICAL=(myAEDB(1000MB))
ASSIGN myAEDB=’adb144.aedb’
...
BEGIN BULK
param,adb,myadb
param,aedb,myaedb
...
In the case of multiple instances (an instance is a single data block that is associated with a particular set of qualifiers) of the datablocks on the aerodynamic or aeroelastic database, all of them will be located onto the DBSETs associated with the ADB and AEDB parameters.
To reuse an existing database, you need only ASSIGN the MASTER file and DBLOCATE all data blocks and parameters
ASSIGN AeroDB=’adb144.master’
dblocate where (dbset=’myadb’ or dbset=’myaedb’) logical=aerodb
In the case of reuse (using DBLOCATE), the DBALL component of the initial database can be deleted (it then appears “offline” to the reuse, but there are no components on DBALL that are required for the reuse). The MASTER and ADB must be saved and DBLOCATEd to reuse the aerodynamic model. The MASTER, ADB and AEDB must be saved and DBLOCATEd to reuse the aeroelastic data.
Note: | For MSC.Nastran to “find” the data blocks on the database, the set of qualifiers (the “path”) of the required data blocks in the reuse job must EXACTLY match those on the archived database. Be careful that the AECONFIG name (the only completely arbitrary value in the path) is the same. Also, if the Mach or Dynamic pressure is not found, new computations will occur without warning. This is really a feature since this is usually what you want to do: reuse the existing aerodynamic geometry and compute new rigid data. Further, you can “append” to the database by using the PARAM, ADB or PARAM, AEDB in conjunction with the DBLOCATE to create a new MASTER that includes both the original database and the new datablocks. This extension can be continued indefinitely. |
Guidelines and Limitations
Be aware that the aerodynamic datablocks (in particular QKK and AJJ matrices) are fully dense (subsonic) and unsymmetrical. Consequently, the DBSETs of the aerodynamic and aeroelastic database may become very large. Archiving data for reuse is effective only when the tradeoffs between computational expense and data storage requirements are such that you want to store the data. These data are both large and computationally intensive to create, so typically archiving for reuse only makes sense if you know you intend to reuse the data.
In MSC.Nastran V70.7, the aeroelastic database is only defined for the static aeroelastic problem. The aerodynamic database, on the other hand, is defined for both the steady and unsteady data for all aerodynamic theories.
Examples
A number of examples of both the aerodynamic database and aeroelastic database are included in the TPL. Because they are database creation and reuse examples, the order in which you execute the samples is important. In the procs directory of the MSC.Nastran delivery, there is a procedure aero_db.com that can be used to execute the tests in the appropriate order and performing the appropriate clean up between multiple executions. The following bullets list the samples in order of intended execution and describe the feature illustrated by the example:
1. adb144_1: Perform a static aeroelastic analysis and save the ADB and AEDB components for reuse.
2. adb144r1: Replicate adb144_1, reusing the ADB and AEDB components. The original aerodynamic model and spline (aeroelastic) model is described in bulk data, but these data are not used in the run.
3. adb144r2: Replicate adb144_1, reusing the ADB and AEDB components but, this input deck doesn’t include any aerodynamic model. The entire aeroelastic model is retrieved from the archived database. (This is the case in adb144r1 also, but the original bulk data was left in place to show that its presence doesn’t affect the run.)
4. adb144r3: Replicate adb144_1, reusing the ADB and AEDB components but neither the aerodynamic model nor the spline data are present in the input stream. This illustrates that the full aeroelastic model is retrieved from the ADB/AEDB and the bulk data is not used.
5. adb144_2: Create a new aerodynamic and aeroelastic data base by attaching the original from adb144_1, but utilizing a new configuration name and/or new Mach number/dynamic pressures, “append” new data to the database. The MASTER from this run can subsequently be attached and ADB, AEDB datablocks DBLOCATEd and both models will be available for reuse.
6. dumpadb: This illustrates a mini-DMAP solution that attaches an aerodynamic database and dumps rigid aerodynamic data to the XDB that allows visualization of the aerodynamic data. No data on the structural mesh is dumped, because the structural geometry/connectivity is not on the ADB or AEDB components, so XDB cannot associate the data to grids/elements.
7. dumpaedb: Similar to dumpadb, but includes the aeroelastic unit solution data. In this case, the aeroelastic data on the aerodynamic mesh are dumped to the XDB (in addition to the rigid aerodynamics). No data on the structural mesh is dumped, because the structural geometry/connectivity is not on the ADB or AEDB components, so XDB cannot associate the data to grids/elements.
8. adb145_1: This deck generates an unsteady aerodynamic database and also performs flutter analysis at a single Mach and altitude.
9. adb145r1: This deck reuses the unsteady aerodynamic database of adb145_1 to perform a complete Mach and altitude sweep for the archived Mach numbers.