In the last issue of CHEER, one of us wrote of our plans for a Virtual Economy (see Stark (1998)). This project was funded by the Nuffield Foundation and the work was done by a team from the Institute of Fiscal Studies, the ESRC Macroeconomic Modelling Bureau at Warwick University, Oxford University and Biz/ed. The team has created an on-line model of the economy that users can access to try out a variety of different policies with a range of supporting materials to help them understand more about the economy. The wait for the site is now over and it was launched at the IFS on February 26th to an audience of teachers, lecturers, economists, journalists and representatives from the Bank of England and other institutions. The model is available either from Biz/ed or from the IFS site, on the following URLs:
http://www.bized.ac.uk/virtual/economy/
We wanted the Virtual Economy to be a site that was easy and intuitive to navigate around and so with the help of the User Interface Designer (Jan Chipchase) we came up with the idea of basing the site (very loosely) around Number 11 Downing Street. This is a powerful symbol of the economy and economic policy decision making. The site therefore has five floors, and users are faced on each floor with a different floor plan with a series of rooms. They can click on these rooms to get access to the resources on that floor. Each floor has a slightly different emphasis with a wide range of resources. We are still awaiting our invitation to Number 11 to see how closely it represents it! This method of navigation is clear and simple and is completely intuitive to a wide range of users. The floors available on the site are:
The case studies on the first floor look at a variety of different policies and consider the effect that they may have on different firms, people and governments. They are intended for users who may want to use the model as a basis for discussion of different economic policies. They may be of most value for students of business who want to examine the impact that the external environment has on businesses and individuals.
The 2nd floor (the economic policy floor) is one of the largest. For each of the models policy tools (income tax, government expenditure, VAT and interest rates) there are explanations, details of relevant theories and also worksheets. The worksheets could be used by teachers or lecturers as a way of focusing the use of the model by students. There are printable versions available that have spaces for filling in answers. The same information and worksheets are also available for all the outcomes given by the model (growth, inflation, unemployment, PSNCR and the Debt Ratio).
The library has an extensive glossary and where a term in the glossary appears anywhere in the site there is a book symbol beside it that links directly to the definition. Also in the library is details on different branches of economic thought - Classical, Keynesian and Monetarist and famous economists. These can be accessed through a timeline of economists or by type.
The model itself has two different ways to input the data. There is a relatively simple input form that just has a selection of variables, or for more experienced users there is a detailed form that allows changes to all economic variables. Both input forms run the same model, and give the same output. The output from the model is unique in that it gives both the macroeconomic and microeconomic impact of the policies. At the top of the output page is a series of thumbnail graphs showing the impact on the major economic variables. Clicking on any of these takes the user to full details of the effects they have had on that variable. However, they can also see the effect they have had on a range of sample families. Once again there is a thumbnail graphic of the family which acts as a link to further details.
The economic model used in Virtual Economy is based on the public release of the Treasury model. The full version of the model is very complex and is solved on a powerful mainframe computer at the
University of Warwick. Much of the complexity derives from the simultaneity in the model. For example a change in interest rates has a direct impact on prices. This in turn feeds into output and unemployment which themselves feed back onto prices. This starts the sequence off again. The model is run until all variables settle on new paths. This property of the Treasury model means it is an example of a 'structural form'. Its equations describe all the relationships and feedbacks between economic variables that its builders perceive to exist in the actual economy. However, solution of the model can take some time - not an ideal feature of a Web based model.
The Virtual Economy model is an example of a 'reduced form'. Effectively the complex equations of the Treasury model are rewritten in a form that no longer describes the linkages as they appear in the actual economy but in a manner which lends itself to a quick solution. Interest rates now have a direct effect on the level of GDP where in the full model the impact comes separately through the individual equations for consumption, investment and the other components of the GDP identity. The impact of the individual policy changes are calculated on the full Treasury model. Unit shocks to each of the policy instruments are conducted and the impact on the output variables noted. When the user chooses their policy package the VE model compares the size of the input shocks to the unit shock and scales the results for the output variables.
How the Virtual Economy model uses servlets
In the Virtual Economy model, we use two servlets. One - Model Output - receives the string of data sent from the input form and returns the "Model Output" page which you see on running the Virtual Economy model. To do so, it translates the user's menu selections and writes them into a temporary file. It then calls both the macro and micro models, picks up the results, converts into HTML where necessary, pastes these pieces of HTML into a complete output page, and returns that to the server.
The other servlet handles graph-plotting. When ModelOutput needs to place a graph in the output page, it cannot just include the binary data making up the image, because HTML does not work that way. Instead, it needs to place an HTML IMG tag, which contains another URL pointing at the graph. Normally, this would point at a temporary file holding the graph: for example,
<IMG SRC="/scratch/graph_02758.gif">
However, the URL need not point at a file. Instead, it can refer to a CGI script or servlet which takes the graph's data points and generates the image on demand. This is what we do. ModelOutput generates a URL containing the data points, axis annotations, and other graphical parameters. The URL points at our plotting servlet. When the server receives this URL, it passes the data in it to the servlet, which decodes them and calls JavaChart to generate the graph as an image file, which is then sent back to the browser. A typical URL would look like this:
<IMG SRC="/servlet/Plotter/xs=1999;10&ys=1,1.2;2,2.4;3,3.75&unit=Percent">
Here, xs gives the starting year and increment, and ys the before- and after data points. unit is the y-axis annotation. This technique was suggested to us by Damion Yates of the BBC.
One problem we faced with the plotting servlets was lack of speed. It took about two seconds to generate each graph (each 300 by 300 pixels), leading to at least 16 seconds for the output page, not counting other delays. We tried an alternative plotting library, KL Group's Jclass Chart. Like JavaChart, this library has lots of features, and we would recommend it for many purposes (KLG also sells excellent tabulation and windowing libraries). However, for our graphs, JClass Chart turned out to be no faster than JavaChart. Both libraries create the graphs by drawing them into an instance of the class java.awt.Image and then converting that to a GIF file; discussions with Visual Engineering indicated that this conversion is what produces the delay.
We therefore followed Jan Chipchase's advice, and headed the output page with eight thumbnail graphs, each 40 by 40 pixels. These plotted more rapidly, and can be loaded with little delay, enabling the user to see some output even though the rest of the page may still be loading. Each graph is an image link to its big brother. The thumbnails also let users see immediately the general trend resulting from their changes, without being overloaded with details.
Taxben, the IFS microeconomic model that handles the microeconomic side of the Virtual Economy, is written in Modula-2, using the XDS Modula compiler - a high-quality compiler generating efficient code. One can be glad that the compiler is reliable - it was developed for USSR defence applications such as missile control. With the break-up of communism, the implementers formed a company to sell it, and the IFS has been using it for a number of years.
To communicate with Taxben, the ModelOutput servlet writes the user's data into a scratch file. The servlet then constructs a DOS command line to run Taxben, passing the name of this file as a command-line argument. It uses the exec method to start a process which will run this command. If you look at the model output page, you will see that there are two pieces of output from Taxben - the summary and the family details - separated by some other stuff. Taxben writes each of these out as HTML, into its own scratch file. The servlet then picks up these files and copies them into the correct place in the output page.
Strictly speaking, the macroeconomic model is not the program, but the equations that predict the economy's future state from its past history and the user's changes. These equations can be run by any program capable of solving them. We tried three: WinSolve, Time Series Processor, and the Fair-Parkes modelling program.
Our first attempt used Richard Pierse's WinSolve, However, we found that although it performed well when called from the command-line or from a stand-alone Java program, it crashed when called from a Java program running under our Web server. The reasons for this remain obscure.
We next tried the Time Series Processor. Here again, the program worked perfectly when called from a stand-alone Java program, but crashed when run from one running under our Webserver. TSP is written in Fortran, and uses DOS memory-extender calls to extend its memory beyond the 64K allowed by DOS. These may be interfering with the server's memory allocation, but again, we have not followed the matter up.
Finally, we tried the FairModel modelling program. This is written in standard Fortran, and does not use any special operating system calls or other features, so we hoped that we could get running under our server without problems. Indeed we were able to - but only under Microsoft's Fortran compiler.
Presumably because Fortran lacks dynamic storage, FairModel restricts file names to 16 characters. This was an irritation. We need to generate scratch files to hold model input (FairModel has its own command language, and we need to generate a driver file in this language for each run) and output: to avoid files for one transaction getting mixed up with those for another, the names must be unique. One can generate unique names from the date and time, but only if two transactions can never occur within the same clock interval. On our machine, this is 10 milliseconds, which is not quite short enough Instead, we use unique "session identifiers" generated by the Web server (available by the HttpSession.getId() method). However, these are long, and overflowed FairModel's filename limit.
We circumvented this by generating a scratch directory with the same name as the session identifier, and changing the current directory so as to run FairModel from under that. This meant that it could refer to its files via relative names, which need not contain either session identifiers nor directory names, and so could be very short. Another minor inconvenience was that Java does not provide any means to change current directories (i.e. no equivalent of the cd command). We circumvented that by invoking a Perl script from Java. Perl does know how to change current directories, so the script did that and then ran FairModel.
One final difficulty was that FairModel has its own output format which we were unable to modify. It returns results as blocks of space-separated numbers, giving the values of the macroeconomic variables over time. The servlet has to read these and remove headings and other extraneous text, before outputting them as HTML tables and graphs. Reading this stuff is a non-trivial task, and we used the freeware JavaCC parser-generator to make it simpler. JavaCC, freely available from http://www.webgain.com/products/java_cc/, is an extremely useful program that reads a grammar and generates Java code for parsing according to it. In our case, the grammar is that of FairModel's output file.
Stark, G. (1998). Virtual Economy (the new teaching version of Be Your Own Chancellor) Computers in Higher Education Review. Volume 12 Issue 2 pp25-26
Virtual Economy: | http://www.bized.ac.uk/virtual/economy/ | |
---|---|---|
http://ve.ifs.org.uk/ | ||
IFS: | http://www.ifs.org.uk | |
Graham Stark: | (email: gstark@ifs.org.uk) | |
Jocelyn Paine | (email: popx@j-paine.org) | |
Biz/ed: | http://www.bized.ac.uk | |
Andy Beharrell: | (email: itwg@ebeq.demon.co.uk) | |
Jan Chipchase: | (email: jan.chipchase@bristol.ac.uk) | |
Warwick University: | http://www.warwick.ac.uk/fac/soc/Economics/MMB/ | |
Keith Church: | (email: mbran@csv.warwick.ac.uk) |