Notes for Module Developers

This help topic is long and complex. Try maximizing the Help window: you will still need to scroll to

read the whole topic. We suggest that you PRINT the topic from within Help (via right-click).

Then read the printed sheet twice. Later, refer to the printed sheet as you work with RunGTAP.

NO! In the context of RunGTAP, version means database. You must learn to talk the talk. Instead think about creating a custom module which will replace the standard GTAP module and will be be named GTAPxxxx. Your new module will be used with one or more versions (aggregations). The most important component (file) in your new module will be called GTAPxxxx.TAB.

First create a new version, called perhaps NEWVER1, which is based on some existing version. You will work in the NEWVER1 folder so that your mistakes do no lasting damage. Now, in DOS go to the RunGTAP folder (probably C:\RunGTAP) and issue the following command:

The effect is to create copies of all files in the standard GTAP module. The copies are located in the NEWVER1 subdirectory and are named GTAPCOOL.

Now start up RunGTAP, change to the NEWVER1 version and launch the Version..Modules dialog. Click on the Version-specific, Main model, TAB file box (at top right): the Choose TAB file dialog will appear. Choose the stored in version folder option; GTAPCOOL should appear in the list below. Click on GTAPCOOL; the module components will be listed at right. They should be all present and up-to-date. Click OK to return to the Version..Modules dialog where you will now see that the GTAPCOOL files will be used instead of GTAP for the current version. Click OK again and run an experiment -- the progress indicator should inform you that your GTAPCOOL module is being used.

Thus far, of course, all GTAPCOOL files are identical to their GTAP counterparts. Probably your next step would be to exit RunGTAP, modify GTAPCOOL.TAB in some way, edit GTAPCOOL.STI (changing GTAP to GTAPCOOL in 3 places) and use TABLO to create AXS/AXT/EXE or GSS/GST files. Then go back into RunGTAP and test the modified GTAPCOOL model. Remember that if you add a new variable, it must be listed in GTAPCOOL.MAP to appear on the results page. You might also have to modify the closures in GTAPCOOL.EXP, GTAPCOOL.CLP and GTAPCOOL.CLG.

When RunGTAP notices that you have changed a TAB file, it may delete older files that depend on that TAB file. You might be warned that these files are missing. Usually the files will be regenerated next time you run a simulation and so the warnings will go away.

You must choose a name for your module by adding a few letters to the original name. The new name cannot be more than 8 letters long. Since most of the original module names are 6 letters, this means that often your module is distinguished by an additional 1 or 2 letters. For the main module (GTAP) you can add up to 4 letters. The 8-letter restriction is required so that RUNGTAP works with GEMPACK 6.0. The requirement that the first letters of your module name match those of the orginal module is enforced so that RunGTAP can tell the purpose of a TAB file from its name. Thus RunGTAP does not allow the user to choose, say, DECOMPX.TAB as a replacement for SHOCKS.TAB.

(b) The Version..Archive command stores all version files within a single ZIP -- including your new module. So you can back up your work. You could also send the zip archive by email to another RunGTAP user; she can load the archive to create a new version which will automatically be set to use your new module. Even if she had herself recently created her own module with the same name as yours, there would be no conflict.

The disadvantage of locating your new module in a version folder is that it can be used only for that version. You might end up with multiple copies of your new module, duplicated in several version folders. You could avoid that by locating it in the main RunGTAP folder.

Suppose you created a new improved DECOMPX module which worked with the standard GTAP module and data files. It would be logical to place it in the main RunGTAP folder and you could specify that it be used by default in place of the supplied DECOMP module.

Suppose again that you created a new GTAPOIL module to replace the main GTAP model. Suppose you have 5 alternative databases for GTAPOIL -- so you need 5 different version folders. And suppose that GTAPOIL requires some extra coefficients on the parameter files so that it will not run with the standard versions. In this case it would be natural to place GTAPOIL in the main RunGTAP directory so that all your 5 versions could use it. However, you should not assign GTAPOIL to be the global replacement for GTAP, since it requires special parameter files. Instead, you must change to each of the five versions in turn, and use the Version..Modules command to specify that GTAPOIL is used for the current version.

You have to ensure that your changes to the main model (GTAP module) do not conflict with the requirements of the other modules (Decomp, GtapVol, etc), or else you must disable them until you can create new modules to replace them. In general, it will be easier to add things than to take them away. If you remove or redimension data items used by the other programs, problems will arise. Similarly, omitting, substituting, or backsolving variables which were not so treated before could cause problems.

Another factor that constrains your changes is that RunGTAP writes the CMF files. Therefore, your modules must use the same set of file-names for input and output as the original modules. You cannot add new input or output files (but see XSETS and the CMFSTART file). Instead you should put new input data on one of the existing input files: SETS.HAR, BASEDATA.HAR, or XXX.PRM. To create new output headers, add write statements to the GTAPView TAB file.

Variables with more than 3 dimensions do not appear in the RunGTAP user interface.

If you find you are diverging too far from the RunGTAP framework, consider using the standard GEMPACK program RunGEM. Although similar to RunGTAP, it lacks many of its GTAP-specific features. It will work with nearly any GEMPACK model.

Sorry, yes. Of course, you have the option of directly editing (without renaming) a standard file (perhaps GTAP.MAP) which is used by default for all versions. But be careful !

GTAP.MAP:	controls which results the user sees.
GTAP.EXP:	The default experiment.
GTAP.MIN:	Model Information file made by TABLO.
GTAP.SIN:	Sensitivity Information file: if in doubt, copy existing file. First line of SIN file must be #Parameters; any more is optional (see SSA.CHM for syntax rules).
GTAP.CLG:	the closure used for SAGEM GE Elasticities.
GTAP.CLP:	(most of) the closure used for ALTERTAX runs.
DECOMP.MAP	pipes results to DECOMP and GTAPVOL programs.
GEELAS.MAP	pipes results from SAGEM to GEELAS program.

Mostly, yes, although RunGTAP does not officially support GEMPACK 6.0. But you should be aware that some new features of later GEMPACK versions will not be supported by modules created with GEMPACK version 6.0. Long directory names are an example. If you installed RunGTAP in C:\My Projects\RunGTAP you might find that modules created with GEMPACK 6.0 would not run. The AnalyseGE tool also requires that the main GTAP module was made with GEMPACK 7.0 or later. Also, executables made with GEMPACK 7.0 or later will flexibly handle both Formats of HAR files.