$ $ THIS ALTER IS CONFIDENTIAL AND A TRADE SECRET OF THE $ MSC.SOFTWARE CORP. THE RECEIPT OR POSSESSION OF $ THIS ALTER DOES NOT CONVEY ANY RIGHTS TO REPRODUCE OR $ DISCLOSE ITS CONTENTS, OR TO MANUFACTURE, USE, OR SELL $ ANYTHING HEREIN, IN WHOLE OR IN PART, WITHOUT THE $ SPECIFIC WRITTEN CONSENT OF THE MSC.SOFTWARE CORPORATION. qfromdb.rdm INPUT OF MATRICES FROM EXTERNAL DATA BASES, qfromdb.dat M. A. Gockel April 17, 1998 1. Background It is sometimes necessary to bring in matrices from storage devices into a MSC/NASTRAN run. There are many motivations for doing so, and many ways to accomplish the task. This set of examples is motivated by a client's need to take several large matrices named AIC, generated by an external program, and use them to replace the QKKS matrix normally generated in SOL 144. He had been using output4 tapes for this purpose, but found that the storage requirements and the requirement to re-process the matrices on each run were inconvenient and inefficient. A method to read each matrix into a database on a preliminary run is described. Operations on the matrix are made here, so that they need not be repeated every time the matrix is read in. Each data base is attached as an external data base on the production run. Each run requires a considerable number of FMS statements, as well as a DMAP alter, and all of these need extensive modification when used for other data blocks in other contexts. The entire input file for each operation is therefore provided, extensively commented with statements on the design process for generating these input files for other similar tasks, rather than the conventional documentation method of providing include files. 2. SIMULATION OF EXTERNAL PROGRAM, qsetup.dat The AIC data block is expensive to generate with the external program, so the client generates one per run. It is the transpose of the MSC.Nastran matrix QKKS. The client has done some research (see the comments in the next section on QKKS), and found that the QKKS data block is stored with qualifiers imachno, aprch, and highqual. He called his friendly MSC support person who told him that the latter two parameters are provisions for features not yet implemented in SOL 144, so their default values (0) are adequate, hence they never need to be mentioned. (The use of qualifiers may also be researched by compiling all of the SubDMAPs used in a run, then seeing if a qualifier such as highqual is used anywhere. If not, it may be ignored.) IMACHNO, however, is an integer representation of the Mach number used when generating AIC, and each AIC matrix (and its output4 tape) must be tied to the Mach number used when generating the AIC. The practice of using the value of the Mach number as the extension of the tape name is used, to make this process visible. That is, the tape with the name aic.5 has the matrix for a Mach number of 0.5. It is stressed that it is the user's responsibility to correlate the matrix with the Mach number. No checks are made in this series of runs for such checking. A standard test model is used to generate the QKKS matrix at two Mach numbers. It happens that QKKS is the transpose of AIC, so it is transposed here to give it the form that it would have had it been generated by the client's external program. At the end of the run there are two output4 tapes, with extensions of .5 and .6, corresponding to their Mach numbers. Each has a QKKS matrix on it. 3. MOVE MATRICES FROM OUTPUT4 FILE TO DATA BASE, qtodb5.dat, -6.dat There is one such input file for each AIC matrix. It uses the practice of including the Mach number in its file name, and related names. The assign MASTER . . entry names the data base produced by this run. The assign output4 . . entry names the file produced by the external program. SOL 100 is used, to have the standard NDDL assigned to this run. The NDDL file has the names of all data blocks that may be stored in the data base, and their qualifiers. The relationship between the real value of Mach number and its integer equivalent is copied from the PFAERO subDMAP, where QKKS is usually generated. The proper AIC matrix is brought in from the output4 tape, transposed, then automatically stored in the data base with the proper value of IMACHNO. There are separate input files for the two Mach number values. The -5 version has some features which combine all data on one physical file (.MASTER), then automatically eliminates the (empty) DBALL file at the end of the run. This version is also re-entrant, in that it may be run repeatedly, because it first deletes any old data base that may be present before it starts. The –6.dat version uses simpler FMS and DMAP, with the cost that two physical files are needed for the data base, and that each must be deleted manually before the run is repeated. 4. READ MATRICES FROM EXTERNAL DATA BASES, qrfromdb.dat Assign statements are used to attach the external data bases. Dblocate commands are used to identify the data block to be read from them. The design of the dmap alter can require some thought, and tends to differ for each data block. There is logic in the subDMAP where the QKKS matrix is normally generated (PFAERO) to skip over the loop that generates it if it is present. Unfortunately, there are other data blocks generated in the loop that are needed later, so this test is disabled. The statement that generates QKKS is left in, but jumped over so that it is present to pass DMAP compilation rules but never executes. With some more labor the generation of several other expensive data blocks used only to generate QKKS could be jumped over also, but this exercise is left for the user. Note that the transpose operation on AIC is not repeated here, and that QKKS is read directly from the external data base when needed, and not copied to another file. It was found that the results from this file match those from a file made from the first input file described, after the DMAP alter is removed from it.