Welcome to MVS Class I - Session 1 - Part 1!
The structure of this course is fairly simple. Each class will present it's information in a briefing style followed by a class assignment designed to,
- Utilize the current class information,
- Exercise the student's imagination, and,
- Prepare the student for the next class.
The series of "briefing slides" which are presented will each be followed with a short commentary about the information presented on each slide/graphic, essentially the same words which would be used in a live presentation. The only thing that will be missing is the interaction between the student and the lecturer which occurs during a live presentation. This is where e-mail should prevail.
It is very important, also, that the student complete each assignment, or at least give it a strong effort, to maintain the continuity of this training. Again, I point out that this WEB centered training is new for me and I wish to interact with each student in a personal manner through the magic of the electronic messenger, i.e., e-mail. So, always feel free to contact me through the e-mail channels and always feel free to ask any question, argue any point, etc. You may contact me at either e-mail address, email@example.com and firstname.lastname@example.org but preferably you should use both in the case that I am on the road where only the AOL address is accessible to me (for the present).
TRAVEL NOTE (12 Aug 98): Please note that I will be inaccessable during the period of 26 Aug through 14 Sep 98 as I will be traveling in Russia! (Yup!)
We begin our studies in the MVS world in Session 1 of Class I with an introduction to the basic structure and implementation of the program and to the infamous I/O format (X5) that has given the program a bad name over the years - bad because it is highly structured requiring close attention to column position in each line of input.
ASIDE: I recently asked Jan Prazak at Aerospace if he could identify the source of the term X5, like was it the fifth in the "X" series of formats? Jan could not recall where it came from. He said that for as long as he could remember it just ... was. If anybody knows (Ahem, Marty) drop me a line.
As you learn how to use the program, hopefully you will begin to appreciate the thinking that went behind this inovative (in the 1960's) I/O. So sit back and let me guide you through this series of "briefing slides" which have been developed over the years to capture your interest and convince you that the MVS system is unique, efficient and powerful.
The Class I assignment for this into lecture is fairly simple. Ranther than expect you to have a full grasp of the X5 format at this point, I am giving you the complete input for your first problem, A Falling Stone (Simulation).
(Note: I am providing this problem set of inputs to you below in fixed width format. If your window is not wide enough, it will cause text wrapping. Widen your window so that a full 80 columns of information is presented in each line.)
MMMMM XX*DvvvvvAxxxxxxiiisscccDvvvvvAxxxxxxxxxxxxxxDvvvvvAxxxxxxxxxxxxxx H **** Class I Problem 1: A Falling Stone C1P1-01 A **** Simple Trajectory Simulation C1P1-02 10E Test Case C1P1-03 10LD 3 TD 4 0. D 5 FP1 C1P1-04 20E Ground Impact Event C1P1-05 20LD 3 H 4 0. D 5 VDR C1P1-06 CYCXM 10 DTEA 1. LFDT1 1. C1P1-07 DPGXM 10 IGCF 2. C1P1-08 TM0TM 10 DIN G DL0 2 C1P1-09 TM0TM 10 LATL 45. L0NL 45. HSLL 10000. C1P1-10 TM0TM 10 VMI 1000. AZVI 45. GAMI -45. C1P1-11 C 0. C1P1-12 C 1. C1P1-13
Your problem 1 assignment, then, is to simply reproduce these inputs as you see them here in an input file on your MVS execution computer and follow the instructions provided to you by your local MVS expert for execution of the program. Note that you can actually highlight these lines here and copy/paste them to a file. Saves typing! I have actually done your homework for you in Handout No. 1 where I have annotated the output from this small set of inputs. Handout Number 1 has been converted to a PDF formatted file and can be downloaded from here: C1HOUT1.PDF (27 kbytes) or can be read online if you have the Adobe Acrobat Reader plug-in with your browser.
Problem 2 will be covered in a later session. Now let's look at some of the many MVS capabilities.
MVS has been, over the years, both an analytic tool and a test bed. You will find virtually all data forms used in the analysis of moving and static objects along with their sensors from internal telemetry accelerometers to long reaching remote sensors. The beauty of the modularized concept is that most if not all of these prototypes remain in the program and can be used not only as independant data analysis models but more powerfully as the various parts and contributors to metric fusion with cross correllation in tact. One item not on the list above is the project for which Marty Rademacher recently upgraded the MVS capabilities to the FK5 and Y2K standards - the calibration of GPS.
Finally, if you do not find a model you want to use because it has not been programmed into MVS yet, you can use the General Argument Functions or ARG functions to model it yourself much like you build a macro in more recent codes and without having to recompile the massive MVS FORTRAN code. If it happens to be a popular model, you can bet that Marty is already working on coding it into the program. More on ARG functions later.
One interesting and rather latent aspect about MVS is the fact that it IS both a 3-degree and a 6-degree of freedom simulator. 6-D, however, has not been used very much but as a reminder, you ALWAYS have to tell MVS not to use it! The default is 6-D and every set of inputs has to be told not to use it. You turn it off with the Guidance Command Flag (GCF) and you will find the GCF is set to the value of 2 in the Class Problem 1 input set, for 3-D angle steering.
I have been surprised at the number of people in our work who do not know the difference between 3-D and 6-D modeling. If you think you know the difference, drop me an e-mail line describing what that difference is in 25 words or less or let me know that you do not know the difference and I will tell you. Don't be embarassed to be possibly wrong, it's better to know you are wrong here than on MIR.
ASIDE: At this point in my stand-up lecture I usually bring up several of the unique points that make people either love or hate MVS. One of those on the "make things easier" side is the fact that the naming convention for program variables is such that realistic acronyms are used to help the user always identify what the variable does for a living. The Giudance Command Flag is an example using the initials G.C.F. to identify the variable. Virtually all of the variables in MVS are like this (although a few unmentionables have been slipped in by not so aware support programmers). Examples might be WPI for Weight of Propellant at Initialization or TFG (Time From Greenwich). While you are browsing the documentation, see if you can guess the process from the name before you actually read the definition.
Another point that I try to bring up as early as possible in the beginner's mind is the ZERO (0) vs. OH (O) controversy. This has been a killer over the years (primarily spitting out input sets as unacceptable, I'm not sure about users). So, a little more history might help you remember...
Back in the dark ages, most program generation, compilation and execution was initiated through the use of the original floppy, the IBM Card (storage capacity 80 bytes, WORM). This little beauty was the source of great groups of underpaid, slave laborers sweating over giant devices (about the size of an executive desk) known as key-punch machines.
Programmers or users would print their programming code or execution commands on 8 1/2 by 14 format sheets (they were below using the machines themselves and they couldn't type anyway) and these sheets would be fed to the sweat shops for conversion to card decks. The card decks would then be submitted to the "I/O area" and a day later, the computer run would be picked up and dropped off on the programmer's or user's desk. (Of course, many of these steps could be done by the programmers or users themselves but go figure. Rank had its bene's.) Hence, if one little word were spelled incorrectly on these "floppys" a programmer or user may actually lose a day or two (and this was worse than Grace Hopper's BUGS!).
Aerospace Corporation, probably the largest producer of scientific code and paper trash during the 1960's, knew that this problem could cause delay's in completing their work on the Titan II. In a flash of insight, some anonymous genius at Circle-A cried out, "0reka" (spelled with a ZER0, he was eating creme filled cookies at the time) and declared that the letter "Oh" was off limits at Aerospace. [This one little burp in the galaxy of social entropy may have saved the scientific community millions of dollars in software development and cost the government billions of dollars in psychotherapy expenses! ... talk about Y2K!] Of course, FORTRAN and other languages screamed back and said that, "Variable names cannot begin with numbers!" So the first (and only if I recall) ammendment to the ZERO law at Aerospace was declared, "ZER0's except at the beginning of words!" which also had a fallout that contributed to confusion outside of the Circle-A fence. Engineers and programmers and users were told that if they wrote anything that needed an "oh," they should put a diagonal slash across it (which, in Europe means zero! meaning that they couldn't hire foreign keypunch operators - but that was before Equal Opportunity Laws).
Without getting too carried away with this (since I managed to survive that period - a pretty good keypuncher myself - but that's another story), the fallout was that MVS uses ZER0's except at the beginning of variable names: i.e., OLSTM, for the Open Loop Steering Module and OMYB0 for, "Omega about the Y Body axis at initialization, zero." Note that OMYB0 epitomizes the Circle-A ZER0 Law!
Moving on ... Just remember that if it moves, it can probably be simulated in MVS and if something is sensing that motion, MVS can probably reconstruct it ... with your help.
The facts in the above VG vary with time. For instance, I have never asked Elizabeth or Jan at Aerospace if they are distributing their version of MVS to others but I have run into situations where an analyst will declare, "This has been validated with TRP!" and I find that it is the Aerospace version of the program that was used. I am not sure of the extent to which these two version of MVS have diverged but I have initiated communications with Jan Prazak with the idea in mind that we try to bring the two back together. So far we have just talked but I hope to pursue a reconciliation if only to insure that we have a subset of inputs that work equally well on both systems. Ideally, I would like to incorporate all of the models into one code without losing or dropping any on either side. The modularized structure of the program would support that. Funding is something else!
It is, again, the Logicon-GeoDynamics version of the program that I am addressing in this study program and which is currently installed at the location where the majority of my current students are located. Jan, you're welcome to use this training as well if you feel that it is in your best interest - and of course, any input from the Aerospace gang will be welcomed with pleasure.
The above VG is one that I try to dwell on and make sure all of my students are awake. When I say, "You DO have to be a rocket scientist to understand TRP" in another part of this course, I say it with tongue in cheek. Former Bronco and now sportscaster Dave Logan, who broadcasts the Bronco games locally and also covers the Colorado Buffalos has a habit of saying that you do not have to be a rocket scientist to understand this or that football or philosophical concept. It irks me every time he says it! A couple of years ago, he had used that statement in referring to his divine knowledge that the Buffs would beat Nebraska that year (which they did not, by the way, Duh!). I called the radio station and told him that I was a rocket scientist from Nebraska and I didn't get it!
Take heed, then, with the comments in the above VG. No, you do not have to be a rocket scientist to understand MVS but you do have to be the kind of person who has curiosity and fortitude and who will stick with a problem knowing that with tools like MVS, they can be solved, studied and productive in understanding the science around us. The complexity of MVS lies in its depth of content. Many scientists have dedicated much of their prime efforts to the incorporation of TRP in their problem solving set of tools and contributing to MVS's capabilities. But one guy stands out, Marty Rademacher. Without Marty, MVS would not exist as it does today. It's his baby. He was there when it was born and he was it's nursemaid. He introduced it to me in 1968 and there isn't a day that goes by when I'm working with it that I am not awed by what it represents. What about me? Well, yes, I've been tagging along but I'm only a zealot and an apostle!
This wiring diagram comes right out of the 1966 MVS System Engineering Manual, Volume I unchanged. This is a flag to tell you that the primary concepts of simulation have not changed in over 30 years (but then, again, how long has Newton and Kepler been around unperturbed?!). My one complaint about this diagram is that it does not show input and output blocks, but if we call it the Simulation Engine using a more modern representation, it is the guts of the simulation black box. One of the comments in the 1966 manual was that each of the Modules act as independent computer programs depending on the others only for input (and output). This is somewhat simplistic because the thing that is missing is a sense of CONTROL.
The next VG begins to show that control through the MVS Executive modules. When I was putting together the Certified Analysts Training (CAT) lessons, I was a bit concerned about how I would present this control. I soon settled on an idea that worked, I treated MVS as a corporation and manned it with modules (See CAT Lession 12). MPEXM (the Master Program Executive Module) is a grisly old CEO who only has to make one decision each day (run), he has to determine whether the current run is going to be a simulation or a reconstruction run. His primary contribution being the Iteration Reference Flag (ITRF). Actually, he has a third option, optimization, but he hasn't done it since he was a young and agressive Boolean.
MPEXM's support staff consists of the simulation executives (TSPXM, CYCXM, DPGXM, INFXM and INTXM) and his old gaussian friend, PFRPM (the Post Flight Reconstruction Processing Module). PFRPM is not an executive, more of a chief scientist type and was originally added to the senior staff to support NASA. The people who really run the simulation show are two women executives and close friends, TSPXM (the Trajectory Simulation Processing eXecutive Module) and CYCXM (the CYCling eXecutive Module), TSPXM being the overseer of the simulation process and CYCXM making sure that things were done on time. The real simulation grunt work gets done by INTXM (the INTegration eXecutive Module), [I quote from Cat/Mat lesson 12:]
"As with most functional organizations, there is a level of middle management which usually monitors and controls the primary function to which the organization attributes its existence. In TRP, this function is the simulation and propagation of the equations of motion through time and space. The junior executive in charge of this function is the former director of NASA and Doctor of Science and Engineering, INTXM.
"INTXM is in charge of the entire TRP Engineering Directorate which includes such greats as Runge-Kutta (mathematician and MENSA member), Translational Motion (remember him in the 1963 Rose Bowl), Aerodynamics (Howard's right hand man in the construction of the Spruce Goose) and Environment (you can catch her on Channel 7 Weather)."
As you can see, I try to grab your attention with anything I can find! A few more comments on the members of this MVS organization. The SERVice Module (SERVM), which is detached from but addressable by all other modules is actually the self-contained MVS math library providing most of the complex functions required for program operation and using the simplest of the FORTRAN library functions to build them. This plus the policy of compiling MVS as a STATIC executable makes the program extremely portable between most if not all computers and operating systems.
Actual input processing is controlled by a pair of modules, INP1M and INP2M but referred to in the chart as INPMM (INPut Modeling Module). These guys are akin to a security section ("if you don't fill out the forms right, you ain't gettin' in!" - it doesn't matter whether your cleared!). Their task is not an easy one because, like security, they must be ready to perform at a moments notice. Translating this back to running a program, MVS is designed to GO the moment the GO control command is given. Translating this further, this means that after each input line is read into the BUCKET (we'll talk about BUCKET later), it must be completely processed before another line is read in: i.e., MVS is always ready to GO. Of course, you have to have given it something to GO with. Picky, picky, picky!
On the simulation side again, output formatting and control is handled by INFXM (the INFormation eXecutive Module), whereas ITERM (ITERation Module) and ITIFM (ITeration InFormation Module) perform the I/O processing and formatting for the Post Flight Reconstruction process. The Data Processing and Control eXecutive Module (DPGXM) is probably the least used member of the team under current operations. An expert in guidance and control theory, he's one of those guys who might be looking for retirement options but still holds onto a small but necessary part of the operation. He controls options for both closed loop (DPG1M & DPG2M) guidance and open loop stearing (OLSTM) and, by the way, holds the keys to 6-D and 3-D options, and to keep him busy until the real full up 6-DOF user comes along, he controls the TRAcKing Module (TRAKM) which is not used by some and overworked by others with it's ability to model 30 orbital tracking sensors using full Runge-Kutta 4th order integration for their orbits while simulating and/or reconstructing the primary missile/aircraft vehicle.
The remaining modules, again, are the work horses under INTXM. These include (note the zeros in the names):
- STRTM (STRucTures Module)
- C0NTM (C0NTrols Module)
- ENVRM (ENViRonment Module)
- AERMM (AERodynaMic Module)
- PR0PM (PR0Pulsion Module)
- RM0TM (Rotational MOTion Module)
- TM0TM (Translational MOTion Module)
- SENSM (SENSor Module)
- JUNKM (JUNK Module - actually it's the Miscellaneous Module and does not contain junk. It's a parking place for algorithms and other convieniences but the name MISCM just didn't fly!
I try to anticipate problems. So I'm giving you a few minutes to complain. Please read this slide out loud 5 times and then PUT IT TO BED!
If you haven't taken a break for awhile, you should now 'cause we are going to tackle X5 in all of its glory. ... go ahead, I'll wait.
As for the possibility of replacing X5 for MVS, no way, but help is on its way. I like to give good news first then I can slam you with the bad. The GOOD news is that Scott Lutz is busy down in Colorado Springs writing GUI's for not only MVS but also for KADRE and SABER. Let's hear it for Scott!! I have included several of his windows below to show you what's coming, an example of what you will see in RAM, Ed and Scott's name for this progressive step in the lives of weird but effective simulation and reconstruction programs. The BAD news is, you're going to have to learn X5 anyway if you are to become an effective MVS analyst.
The graphic below is Scott's introductory Menu and if I remember correctly, it remains on your desktop as you work in the other windows providing you with a quick jump capability to other windows as needed. This Menu fits across your 17 to 20 inch monitor and is a lot easier to read than this example. To help you out, however, I have included a copy of all of the buttons at true scale below.
Looks pretty impressive, what?
If all of those things work, we're in pretty good shape!
(Just kidding, Scotty!)
Go ahead and scan down through these sample windows. Scott sent them to me via e-mail. Isn't it wonderful! But I probably would tell you something wrong about them so I won't try. [Scott and Ed, if you are looking and you've got some ideas about some words to go with this set, send 'em to me.]
Please Go On To Part 2