Below is the uncorrected machine-read text of this chapter, intended to provide our own search engines and external engines with highly rich, chapter-representative searchable text of each book. Because it is UNCORRECTED material, please consider the following text as a useful but insufficient proxy for the authoritative book pages.
FUTURE COMPUTING ENVIRONMENTS FOR MICROSIMULATION MODELING 179 and output routines and for adapting the FORTRAN source code to the target system's FORTRAN compiler. Availability, Customer Base, and Technical Support ASPE is currently the principal sponsor of TRIM2. In the 1988 budget year it spent approximately $650,00020 using and maintaining the TRIM2 model. Approximately $125,000 was spent for computer resources used at the NIH computer center, and the other $525,000 was paid to the Urban Institute. The Urban Institute work included creating a new TRIM2 database from the current March CPS data file, modifying the current operating characteristics to match current legislation or ASPE-proposed scenarios, and general model maintenance. Approximately 80 percent of the money was for routine TRIM2 model development and maintenance, and 20 percent was for using and interpreting the model for policy analysis. There is no significant current use of TRIM2 other than the work sponsored by ASPE, CBO, and the Department of Labor for two major reasons. Over the years staff expertise in using TRIM2 has become heavily concentrated at the Urban Institute. Therefore, prospective government or private users of TRIM2 must approach the Urban Institute for assistance in using it or face substantial initial start-up costs. With the cost of mainframe computer time at private computer centers being approximately three times that at the NIH center21 and since TRIM2 cannot be easily ported to smaller, less expensive computers, any research carried out for a private organization would be very expensive. Future Work The TRIM2 system is largely in a âmaintenance-onlyâ mode. Some development work is being done on revising old master routinesâfor example, work on a new participation methodology for the AFDC module and work on completion of the newer HEALTH master routine. Comparison TRIM2 and SPSD/M are strikingly similar and strikingly different. The similarities reflect both the similarity of the substantive issues that the models address and the fact that both computer implementations must address similar problems in providing the desired combination of flexibility and efficiency. The differences reflect the state and orientation of the computing technology available 20 Joan Turek-Brezina, HHS, personal conversation, 1989. 21 Dick Michel, Urban Institute, personal conversation, 1989.
FUTURE COMPUTING ENVIRONMENTS FOR MICROSIMULATION MODELING 180 during the implementation and evolution of the models as well as differences in approach to their use. The following points highlight the two products' similarities and differences: â¢ Execution mode One of the most significant differences between TRIM2 and SPSD/M is their execution modes. SPSD/M is an interactive system that permits the user to interactively specify what a model run is to do and to interrupt the execution of the model to check intermediate results. This type of design is natural for a system that runs on today's class of personal MS-DOS microcomputers. SPSD/M can also be used in batch, since it is possible to create a file of the appropriate keyboard responses and then have SPSD/M read this file instead of awaiting input from the keyboard. TRIM2 on the other hand was written during the golden era of batch systems, and today the model is still executed in batch. In many cases large model runs must be submitted for overnight execution. The only interactive facilities available to the TRIM2 analyst or programmer are the interactive edit facilities used to prepare the TRIM2 JCL and control cards. â¢ Model execution speed and cost While this study has not attempted to quantify the exact execution speed and costs of running SPSD/M and TRIM2, it is possible to draw conclusions about their impacts. An average complete SPSD/M run takes about 20 minutes of wall-clock time on a Compaq Deskpro 386/20. This time can be decreased by using faster MS-DOS machines. The interactive mode of SPSD/ M also greatly impacts total development time and therefore cost for a research study since it permits an analyst to run a reliable subsample of the database or to interrupt a model run when required. Average production TRIM2 runs require 5â10 minutes of IBM System 3090 CPU time and one or more tape mounts. These types of jobs cost $300â$800 at NIH's current charge-out rates. To compare these jobs with SPSD/M's wall-clock time, their turnaround time (i.e., the time from job submission until the time the programmer can review the job's output) also must be considered. Response time largely depends on the scheduling algorithm and machine load at the time-sharing center being used. For example, it is not unusual for a TRIM2 programmer at the Urban Institute to be able to run only two or possibly three of the above-sized jobs in one day. In fact, larger jobs are run overnight to take advantage of a 50 percent cost discount and because it is unlikely they would be run during the day due to the scheduling algorithm. It is possible for a TRIM2 programmer to decrease the turnaround time for a series of similar jobs by transferring a small amount of required input data from tape to magnetic disk. This initial transfer requires processing the original TRIM2 input tape, but subsequent jobs run much faster since they can be run in a different job class that does not require operator intervention for the tape mount.
FUTURE COMPUTING ENVIRONMENTS FOR MICROSIMULATION MODELING 181 It can thus be concluded that an SPSD/M analyst or programmer would be able to complete a research project at lower cost and at a faster rate than an analyst or programmer carrying out a similar task on TRIM2. This assumes that the work being compared is that of similarly experienced analysts or programmers and that the task undertaken is equally feasible in both systems. â¢ Software development environment In the same way that each model's execution mode (i.e., batch versus interactive) affects its pattern of use, the mode of software development is equally important. SPSD/M is developed in an interactive software development environment rich in programmer tools (e.g., Make). This powerful development environment becomes visible to the glass box SPSD/M user since parts of it are included in the SPSD/M product to facilitate modeling that requires changing the SPSD/M internals. The SPSD/M development environment can be further enhanced if it is migrated to a UNIX workstation that provides one of the more recent interactive-based programming environments, such as Saber-C (Kaufer, Lopez, and Pratap, 1988). TRIM2, on the other hand, uses a largely batch environment where the tools available are meant only to allocate the mainframe system's shared resources rather than increasing the individual programmer's productivity. No special tools are provided to assist a programmer new to TRIM2 to make internal changes to the system. â¢ Portability and use of new graphical user interfaces SPSD/M was written in the C language to permit it to be ported to the next generation of personal workstations. For example, the current system could be ported to a UNIX workstation, such as the Sun 4 SPARCStation, with less than 1 week of development effort. On the other hand, moving TRIM2 away from its IBM MVS environment would be a major software development effort. The IBM Assembler language input and output routines would have to be replaced and the FORTRAN source code adapted for use with the target system's FORTRAN compiler. The SPSD/M user interface could be adapted to a graphical user interface such as Sun's Open Look with approximately 2 person-months of time. Such an adaptation is not even appropriate for TRIM2. â¢ Implementation language As mentioned above, the primary reason for selecting the C language for the development of SPSD/M was the prospect of future portability. In fact, the choice of language also determined many of the internal design features of the system. For example, the C language's ability to portably recast a memory location's data type was a technical requirement for implementation of the data compression used for the SPSD. The C language standard library also contains a function that permits a programmer to dynamically allocate memory at execution time. For example, this can be used very effectively to allocate memory for user-defined tables whose dimensions are unknown at compile time. In the same way, the choice of FORTRAN as the implementation language
FUTURE COMPUTING ENVIRONMENTS FOR MICROSIMULATION MODELING 182 for TRIM2 greatly affected the TRIM2 internals. For example, the FORTRAN language used for TRIM2 lacks a built-in dynamic memory manager, therefore, such a subsystem was implemented in FORTRAN as part of TRIM2 by using different-sized COMMON blocks that could be selected at compile time. It is important to note that for any complete translation of TRIM2 to another environment, it would have to be determined whether the target environment's dynamic memory allocator would be used to replace some or all of this part of TRIM2. The input and output routines in TRIM2 were coded in IBM Assembler language for efficiency purposes. The C language was used for these operations in SPSD/M since it provides very fast input and output routines in its standard subroutine library. â¢ Software leverage SPSD/M is attractive to new users because of the leverage it obtains from other MS- DOS software packages that can be used in conjunction with it. An example of this leverage is embodied in the facility that permits a user to load SPSD/M tables from two different runs into a Lotus 1â2â3 spreadsheet and then permits the user to directly manipulate the SPSD/M output. The TRIM2 XPORT module can generate TPL codebooks and SAS input code to facilitate moving data to these tabulation and statistical analysis packages. Some work has been done by downloading the mainframe-based TRIM2 data to a personal computer for use with Lotus 1â2â3. The inconvenience of the downloading operation is a major hindrance in obtaining software leverage from TRIM2. â¢ Extensibility No microsimulation modeling system can anticipate all future user requirements. Both SPSD/M and TRIM2 include a rich set of parameters to control the basic operation of the model and the individual simulation modules. Both systems also include a standard set of reports that satisfy ma ny user needs. If a simulation module does not handle a user's scenario, each system requires that a programmer modify the C (SPSD/M) or FORTRAN (TRIM2) source code. If the standard TRIM2 reports are not adequate, a programmer must code a custom TALLY routine or the required data must be exported for use with a statistical package. Although SPSD/M can also export data in native SAS format, the system permits the user to dynamically define new variables and new tabulations. These execution time facilities become even more powerful when combined with SPSD/M's interactive mode of operation because they permit a user to rapidly debug any use of these facilities. â¢ User community SPSD/M is experiencing a continuing growth in its user community as more individuals and organizations have become interested in using it to participate in the current tax reform debate in Canada. (It remains to be seen what the longer-term demand will be.) Most are using the model in the black box mode of operation. These users have received no formal training
FUTURE COMPUTING ENVIRONMENTS FOR MICROSIMULATION MODELING 183 from Statistics Canada, but they appear to be using the model successfully based on the SPSD/M documentation and the model's interactive mode of operation. Several independent researchers are modifying the model's internals (i.e., glass box mode), with minimal assistance from Statistics Canada. TRIM2 is currently used nearly exclusively by the technical programming staff at the Urban Institute. No outside researchers are attempting to enhance the model by modifying the internal FORTRAN source code. The Urban Institute provides a 10-hour course for programmers and analysts that permits them to submit simulation runs but not to change the TRIM2 FORTRAN code. Over the life of TRIM2, about one programmer per year is trained to the level of being able to modify TRIM2 code or create new modules as well as submit complex simulation runs. â¢ Database compression and size The designers of SPSD/M and TRIM2 dealt with the size of their respective input database file using similar techniques even though this work was done a decade apart. It should be noted that compression was used in SPSD/M to ensure that the SPSD would fit on the limited disk space of microcomputers, whereas data compression was originally used in TRIM2 to minimize the number of basic input operations required to read a TRIM2 data file. Both systems compress qualitative data fields into the minimum number of bits required. The two systems also use the general principle of transposing the data into separate files that are optionally merged at execution time. The two systems took different approaches to handling quantitative dollar-based variables. TRIM2 does not attempt to compress these variables, while SPSD/M achieves a very high level of data compression by suppressing the occurrence of zero values. TRIM2 instead uses the concept of an active file that contains only the variables of interest for a study. In effect this suppresses all variables not needed, not just zero values. TRIM2 also does not compress variables on an active file to save the CPU time required to convert the variables to the format required internally. Interestingly, research has shown that the decompression time required in SPSD/M takes less than 5 percent of a total job's execution time. â¢ Model parameters Both SPSD/M and TRIM2 provide analysts with over 400 parameters to control their supported simulation modules. The major difference is in the manner that parameters are stored and modified by analysts. TRIM2 takes a more centralized approach to this problem in that its design requires that all parameter definitions and their default values be predefined in the CTD. Multiple sets of values for each parameter can be stored in the TRIM2 CTD. For example, one set of values for each of the AFDC benefit-level parameters is stored for each year. TRIM2 obtains values from the CTD for all parameters not explicitly specified in a run. In the case of parameters like the AFDC benefit-level parameters, the TRIM2 supervisor will automatically select the correct set of
FUTURE COMPUTING ENVIRONMENTS FOR MICROSIMULATION MODELING 184 default values based on the year being simulated. The TRIM2 user can specify values for any parameter in the run setup and these values will override the default values. This is not a surprising design for a system that is run on a batch facility by a small group of people. The CTD permits new parameters or scenarios to be easily defined without modifying the TRIM2 system directly. SPSD/M, on the other hand, defines the supported parameters at compile time since they are defined in the model's source code. SPSD/M takes a more decentralized approach to defining the values for its parameters by permitting the parameter values for each different scenario to be stored in a different set of MS-DOS files. This permits a more personal approach to parameter definition, which is more appropriate for an implementation based on a personal computer. Since defining new parameters to SPSD/M is a difficult task not often executed outside Statistics Canada, it might be appropriate to replace this design with one that permitted parameters to be bound at execution time instead of at compile time. The description above indicates the importance of the principle of binding in computer systems development. Major differences in systems can occur depending on when information is bound into each system. â¢ Aging and behavioral response As described above, SPSD/M permits simple static economic aging and demographic aging to be carried out, whereas TRIM2 supports a more sophisticated form of aging that, unfortunately, is not often used. Neither system permits an analyst to easily simulate behavioral responses to tax or transfer program changes. The importance of aging to microsimulation is discussed in more detail under Recommendations and Conclusions. â¢ Model outputs Both systems can produce a standard set of tabulations. SPSD/M does this with a fixed set of summary tables; TRIM2 permits each simulation module to output its own summary. A powerful feature of SPSD/M is the ability of analysts to define user variables and custom tables at execution time without modifying the systems's internals. This feature is an important difference between the two systems since TRIM2 offers no equivalent function. SPSD/M was initially designed with an emphasis on the calculation of overall winners and losers based on their disposable or consumable incomes. TRIM2 does not support such a built-in form of analysis, although a programmer could create a custom TALLY module to calculate these statistics. The design of the SPSD/M result file was originally limited to saving either the disposable or consumable income, but other statistics can now be saved for future study. The original TRIM2 design was based on the premise of using the self-defining active file as both an input and an output file; thus, this facility provides a much more powerful generalized form of result file. Again, a contrast can be seen in the overall approach of designing a microsimulation system. SPSD/ M's initial orientation of measuring winners