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 163 TRIM2 History17 TRIM2 (Transfer Income Model Version 2) is the latest descendant of a cumulative 20-year effort to accurately and efficiently model tax and transfer systems in the United States. The first model in this lineage, RIM (Reforms in Income Maintenance; Wilensky, 1970), was designed and developed in 1969 by President Johnson's Commission on Income Maintenance. The commission attempted to document and evaluate the effectiveness of the various cash or in-kind programs aimed at the needy. Available aggregate data could not help the commission determine whether and by how much the income transfer programs needed revision. To determine how effective the different programs were, it was necessary to develop a system that indicated what, if any, multiple benefits were being received by families. Initially, RIM used data from the 1967 Survey of Economic Opportunity (SEO). RIM was used by the commission to simulate various universal income-conditioned transfer programs that were being considered as alternatives to existing welfare programs. The model also simulated payroll tax and federal income tax liabilities. RIM underwent substantial changes during 1970 and 1971, as it was used to simulate the administration's family assistance plan and various congressional alternatives. These changes included added complexity in filing unit definitions and the ability to handle state-specific benefit levels. One use of RIM required that the system be able to simulate 13 different grant/tax program reforms in one pass of its data file. RIM was converted in 1971 to use data from the 1969 Current Population Survey (CPS). This new source of data was more recent than the 1967 SEO and had the advantage of being updated annually. RIM was developed at the Urban Institute, with programming and computing responsibilities handled by the Hendrickson Corporation. RIM was programmed in FORTRAN and was run on a CDC 3600 and later on a CDC 6600 computer. RIM's major shortcomings were of the kind that are frequently found in computer systems developed by a small group of people to meet their immediate needs. There was no overall architecture or framework to the system, and lack of documentation made it difficult to use and modify. In 1970 the Urban Institute attempted to build a more robust system by modifying the original RIM model. This project was unsuccessful, and instead, over a period of 3 years, the institute built an entirely new system called TRIM. The initial TRIM work was funded by the Office of the Assistant Secretary for Planning and Evaluation (ASPE) of the U.S. Department of Health, Education, and Welfare. 17 Much of this section is based on Webb, Michel, and Bergsman (1990).
FUTURE COMPUTING ENVIRONMENTS FOR MICROSIMULATION MODELING 164 ASPE continued to provide support to the Urban Institute during the 1970s for maintenance, documentation, and further development of TRIM and for training ASPE staff in its use. TRIM was developed with the following functional requirements in mind: support for a modular structure to permit a wide variety of tax and transfer operating characteristics to be simulated; the ability to simulate programs that used different filing units in the same model run; the input data file must contain microdata sufficient to permit reporting simulation results for very disaggregated groups; the ability to model alternate versions of a single program and/or different program interactions in a single model run; support for flexible specification of operating characteristics to be executed and their parameters; documentation not only adequate to permit the system's effective use by programmers and analysts but also sufficient to convince users or critics of the validity of the system's output; execution fast enough to support use during a policy debate; robust software environment to easily permit new operating characteristics to be added or changes to be made to existing operating characteristics. These functional requirements were provided for in TRIM by the following design solutions: â¢ Flexible modular structure TRIM consisted of a supervisor that controlled a set of operating characteristics or master routines. Each master routine simulated one tax/transfer program or performed specific data transformations or input-output functions. The user selected, via parameter cards, which master routines were required, and the ordered set of master routines in a model run was the run sequence. Each master routine was called multiple times by the supervisor. During the initialization phase the supervisor called each selected master routine to determine the required variables and parameters and to inform the master routine of their in-memory location. During the execution phase each master routine was called once per household. Finally, the supervisor called the master routines one more time during the termination phase to permit them to print their summary tables. â¢ Parameterization Each master routine was programmed using a number of parameters to control the master routine's execution. Parameters had default values and the user needed only to override those that were to be changed. Different master routines handled parameters whose values varied from year to year in different ways. Some used parameters with arrays of values; others used completely different data blocks for each year's values.
FUTURE COMPUTING ENVIRONMENTS FOR MICROSIMULATION MODELING 165 â¢ Database A binary file format named CPSEO (after the two principal sources of data, CPS and SEO) was defined to permit different sources of data to be used, to ensure efficient access, and to permit data to be passed from one run to the next. The CPSEO file format defined a set of basic variables that were always present regardless of the data source. The file format also permitted auxiliary variables that varied depending on the source of the data to be present. In addition, the file format permitted other variables to be appended to the file during model runs. The in-memory structure used to hold the household data placed the basic variables in fixed locations while permitting the simulation variables to âfloat.â This design also supported multiple occurrences of a simulation variable to support the requirement of running one master routine more than once in the same model run. â¢ Filing units and status definitions These variables were computed on the fly in RIM, which caused problems when two operating characteristics defined a variable differently in the same model run. TRIM was designed to ensure that filing units and status variables were uniquely defined in a model run. This was done by creating the variables at database creation time and storing them in the database. â¢ Documentation Extensive factual documentation was provided, including the TRIM CPSEO Codebook (Koenig, 1973), the TRIM Technical Description (Moeller, 1973), and the TRIM User's Guide (Bergsman et al., 1975). The original TRIM documentation was organized for programmers, and the complete information for a single master routine could be found only by referring to several manuals. Later an analyst's guide to TRIM was produced (Sulvetta, 1976) to bring together on a module-by- module basis the most important information required by TRIM analysts. â¢ Efficiency A major consideration in the design of TRIM was the need to minimize the amount of memory required to execute a model run. This was carried out by using an overlay structure that included only those master routines requested by the user and by relinking the TRIM system for each model run. The user could also limit memory usage by selecting a pool size that determined the amount of data space available for program parameters and summary tables. Temporary space came from a separate pool and was shared among master routines. â¢ Table generation Each TRIM master routine was programmed to provide several hard-coded tables. TRIM had a limited internal table generator, SUMTAB, which could process several different filing units. It also included an external table generator, TROUT, which could read TRIM files directly. Character files could be output for use by general-purpose statistical packages. â¢ Software engineering practices The overall modular structure of TRIM, with each master routine having an initialization, execution, and termination phase, was one of the system's major design features. Many requirements
FUTURE COMPUTING ENVIRONMENTS FOR MICROSIMULATION MODELING 166 used across master routines were programmed consistently using a common set of subroutines. Each master routine also provided optional debugging facilities, such as the ability to dump a household at the end or during execution of the module. After the collapse of the family assistance plan proposal in Congress, ASPE used TRIM to develop a highly complex reform proposal called the income supplement plan. During this time the Urban Institute was responsible for the annual update of benefit parameters, for implementing major programming changes that required extensive testing, and for programming new operating characteristics (e.g., a food stamp module). When ASPE stopped working on the income supplement plan in 1975, the TRIM model appeared to be headed for a period of disuse. Two institutional developments occurred in the mid-1970s that altered the course of TRIM and microsimulation in general. First, several TRIM analysts left the Urban Institute and joined Mathematica Policy Research, Inc. (MPR). At first MPR used an unchanged version of TRIM but later modified it and named the derivative MATH (Micro Analysis of Transfers to Households model) (Doyle and Neyland, 1979). MPR's new MATH group did not have the type of institutional support that ASPE provided the Urban Institute and therefore became aggressive marketers of the use of microsimulation. MATH thus became a fixture in several departments of the federal government, including Energy, Labor, and Agriculture. Also during this time, the Congressional Budget Office (CBO) became actively involved in using microsimulation to study the distributional consequences of legislative decisions. Previously only the executive branch was able to perform this type of study. The work was carried out by MPR using the MATH model, and CBO's cost and distributional analyses eventually became the standard by which legislative proposals were judged. The U.S. Department of the Treasury began using its own version of TRIM in 1973. Since Treasury did not have an IBM computer facility, the TRIM system was converted to run on Treasury's UNIVAC mainframe computer. The initial database preparation from the annual CPS files was done by the Urban Institute, which also wrote the program to convert the data files from IBM format to UNIVAC format. The Hendrickson Corporation converted and maintained the TRIM model for the Treasury Department. Treasury's version of the TRIM data from the 1973 CPS was statistically matched to its personal tax model data for the same year, so each model could append data from the other database. When Treasury adapted the MATH food stamp module, its software became a hybrid of TRIM and MATH. Later the MATH model incorporated ma ny of Treasury's extensions to the TRIM federal tax operating characteristic. Althougth this golden age of demand for microsimulation left the TRIM and MATH models much broader in scope, several problems existed. As during
FUTURE COMPUTING ENVIRONMENTS FOR MICROSIMULATION MODELING 167 the development of RIM, the demand for rapid production of analyses and the ever-increasing policy agenda left little time for effective software engineering (e.g., good documentation and structured programming). Because of this, TRIM was viewed as difficult to understand and use. Also, by 1977, when the Carter administration turned to ASPE for research on a new major welfare reform initiative, ASPE had lost many of its TRIM analysts and the only sources of knowledge about the system resided at the Urban Institute and MPR. In addition, this new initiative was based on a linked public-jobs-and-cash strategy that did not fit the current law structure embedded in TRIM. As a result, ASPE developed a special-purpose in-house model that became known as KGB, after its authors' initials (Betson, Greenberg, and Kasten, 1980). KGB was developed in approximately 5 weeks by using data files derived from TRIM and simplified tax and transfer operating characteristics. Although KGB was heavily used for several years, it exhibited the worst characteristics of RIM and TRIM. It lacked a generalized software framework, its operating efficiency was only barely adequate, and it was usable only by its creators. While ASPE was using KGB, its support for TRIM continued, and in 1978 the maintenance contract included funds for improving the efficiency and usability of TRIM. A design proposal was completed in March 1979 (Webb, 1979), development began in mid-1979, and the new systemânamed TRIM2âwas operational by the end of 1980. The design of TRIM2 was based on RIM's shortcomings and TRIM's deficiencies, as demonstrated by ASPE's decision to develop KGB. The overall objectives of the new design were to improve overall efficiency, improve printed output, and develop new kinds of input to make the resultant system easier to use by analysts and easier to develop and modify by programmers. TRIM2 consisted of three critical features: (1) a new, flexible, and efficient structure for data files and efficient routines for reading and writing that structure (see Database Creation below); (2) a central database, the Central TRIM2 directory, which contains all variable definitions, all parameter definitions, and default values for all parameters; and (3) revisions to software engineering practices, including automation of the procedures used by TRIM master routines to process input and output microfile variables. This processing is handled by the TRIM2 supervisor, and the initialization code of a master routine, which represents over half of the code in a TRIM master routine, is almost completely automated. FORTRAN coding conventions were established, and documentation of master routines, parameters, and microfiles was automated. Implementation of TRIM2 coincided with the election of President Reagan, whose election platform called for decreasing the size of the federal government. Early legislation by the Reagan administration cut government spending but reduced federal income tax revenues by a larger amount, resulting in a large structural deficit. The deficit problem affected the use of microsimulation in two ways. First, as administrators became less interested in the distributional