AGPS(ID:8145/)
Boeing CFD language
for Aero Grid and Paneling System
language for a CFD developed by Boeing
References:
Programming in AGPS
The AGPS language capability allows sequences of steps to be recorded in a command log file and replayed. Users may also capture interactive graphical AGPS sessions through a journaling capability, in which screen picks as well as commands are recorded. The parametric nature of the internal data structure allows users to swap new geometry or design parameters into the recorded log or journal file in place of the original geometry or design parameters and rerun the entire command sequence.
The AGPS programming language uses many features common to other computing languages, such as DO loop statements, IF-THEN-ELSE and WHILE constructs, CASE statements, numeric and character symbols, trigonometric functions, and subroutines. These features can be combined with AGPS commands to yield concise, efficient, automated macro instruction sets we call "command files," as in Figure 2.
Users can customize the menus in their command files to create sophisticated, standalone, interactive command procedures we know as "packages." Command files and packages automate common design processes, thereby allowing repetitive tasks that were once tedious and time consuming to be accomplished quickly and easily.
AGPS instructions are categorized by type: system directive, comment, command file, or command. Generally, commands create or manipulate geometry objects. System directives create or manipulate symbols, which store numeric or text data. Language constructs such as FOR-DO-ENDDO and IF-ELSE-ENDIF are system directives.
The initial character of each line indicates which type of instruction follows: a "$" for system directives, "!" for comments (comments are ignored by AGPS), or "@" for executable command files or log files. All other lines are assumed to be commands and thus need no distinguishing initial character. The first three characters of command lines are abbreviations of the full command names; e.g., CLS stands for the Create-List command.
Character strings following the command abbreviations are parsed into the individual command keywords. The language allows for flexible keyword input order. Note in the command files example the incorporation of the parametric data structure through the "." notation. This convention allows objects to be specified not by their names but by their logical relationships. We call these "ancestor" relationships; thus "ZDATAi" refers to the ith ancestor of the object "ZDATA."
The Boeing-developed Aero-Grid-and-Paneling System (AGPS) was used to generate the primary surface grids from the CAD de nition for the 747PD application, and for subsequent Boeing applications. This step was performed using automated scripts in the AGPS system, and required no more than an hour or two to perform. Thus, in the two baseline con gurations, and in subsequent applications, time spent in the manipulation of CAD surfaces was not included in the CFD process time. Thus, here we have de ned the beginning of the CFD process as the time at which grid-ready CAD surfaces are available.
AGPS Migration History
To set the stage for the recent Java migration of AGP S we will briefly outline the 20-plus year evolution of the program. AGPS originated in the early 1980s, first prototyped on a PDP -11 and then re -hosted on a then newly -acquired VAX 11 -780. This move took AGPS from a 16 -bit overlay -based computer architecture to a 32 -bit virtual -memory architecture. The original source code was written in three languages: VAX -specific FORTRAN for most of the geometry algorithms, Pascal for the recursive language parser, and VAX assembly language for pointer manipulation of the in -core data structure as well as for speed. The display devices included VT -100 terminals for non - graphics use, plus Vector General and Tektronix terminals for displaying graphics. A typical compile and link of the source code took from one to two hou rs. Running AGPS, while it was ?interactive,? took from seconds to minutes for a typical geometry command. During this early stage of AGPS development much of the compute -intensive code was hand written in VAX assembly language to increase performance. The aerodynamics engineering community started using AGPS heavily since there was no other automated tool available to address their geometry needs. In the late 1980s AGPS was also hosted on a MicroVAX II workstation, which had a maximum of 16M of main memory and ran about 2/3 the speed of the VAX 11-780.
From its inception, the underlying architecture of AGPS was designed in a very object -oriented manner with the organization of the geometric object types and also in the various geometry commands. Each share d a base commonality that was extended for specific types and or commands. This architecture for the types and commands was carried over and embellished in the Java conversion. The internal geometric data structure was able to grow dynamically, taking adva ntage of the then -new virtual memory capability. Within the FORTRAN code, large 1 hard - coded arrays in common blocks were used. Over the years, the sizes of these hard -coded arrays were increased as computing hardware was available to allow larger and large r cases to be run. In the Java conversion we removed all of the hard -coded limits and made the architecture completely dynamic to take advantage of new computer architectures in the future.
In the late 1980s, with the emergence of engineering workstations, AGPS was converted to be UNIX -portable using the POSIX standards. The VAX -specific FORTRAN, Pascal, and assembly - language was converted to ANSI -standard FORTRAN and C. Version 5 of AGPS was the VAX -specific baseline, and version 6 was UNIX -portable. This version had so many problems due to the conversion 2 that it wasn?t until version 7 of AGPS was released that the engineering community started using it (this was a critical lesson to remember during the Java conversion). Through the 1990s AGPS was fairly e asily migrated to a host of UNIX workstations, enabled primarily due to the groundwork which was laid during the UNIX conversion. This included workstations from Apollo, HP, Sun, DEC, and SGI, as well as some mid-range systems including Stellar and Convex. The AGPS development team had learned first-hand the importance of having application code as portable as possible, and we were amazed that neighboring development groups would embrace a vendor - specific platform, Apollo workstations for example, only to i ncur a huge migration effort a couple of years later when the engineering community migrated off the Apollo workstations. We have seen continual migrations from one computing platform to another every few years throughout the history of the project.
During the 1990s we were tasked with migrating AGPS to Cray supercomputers (Y -MP and Triton), which were running UNIX. Even though the code was considered portable, the Cray architecture introduced a major new twist. Up to this point, all the platforms targeted by AGPS had two key features in common: 32- bit words and memory was byte -addressable3. The Cray architecture had 64 -bit words and it was word -addressable4. The then-current AGPS code used many thousands of hard -coded 4s in the source code; some of these sp ecifying the word -size, some of these specifying the word -based address -increment, and some that were part of some geometry -related calculation or equation. The challenge with the Cray port was to identify and understand the usage of these 4s in the source code, and convert them to either 8s or 1s for word -size or address -stride respectively, or to leave them as -is for equations. We ended up using conditionally - compiled C code to set the global constants. A few years later, with the arrival of 64 -bit byte-addressable workstations, we were positioned to easily port to that new architecture, specifying 8/8. On the graphics front, AGPS migrated from the various graphics devices on the VAX 11/780 to X -Windows/Motif on UNIX plus a 3D-GL version on the SGI, while still maintaining a non -graphics mode of operation for batch processing. This was the version of AGPS, now called AGPS -classic, which was the baseline for the Java migration.
Periodically the AGPS development team would get requests to port AGPS to the PC. These requests were never taken seriously since the developers knew the dependencies of the code required FORTRAN and C compilers, X -Windows/Motif for graphics, and POSIX-standard system calls.