Yes, in certain circumstances -- if automatic accuracy is used. Having range restrictions on the values of selected Coefficients (see here) helps.
Below we give 2 examples. The first is a simple, non-economics one. The second comes from giving the standard GTAP model a very large shock - too large for it to handle.
Consider the levels equation Y = 6 - X^2 where both X and Y must be non-negative. Suppose that X is exogenous and Y is endogenous. Suppose that, initially, X=2 so that Y is also equal to 2.
Suppose that you try to shock X to increase its value from 2 to 3. What happens to Y? Well Y will be equal to 6-3^2=-3 which is negative. So this "model" (in which X and Y must be non-negative, as is usual for economic models) has no solution.
You can download GPNOSOL1.ZIP. This contains the TAB file NOSOL1.TAB and the Command files NOSOL1.CMF and NOSOL1A.CMF.
Firstly have a look at NOSOL1.TAB and NOSOL1.CMF. Notice the initial values of X and Y in NOSOL1.TAB and the shock to c_X (the change in X) in NOSOL1.CMF. Notice also that automatic accuracy is requested in NOSOL1.CMF.
Try running NOSOL1.CMF. [You will first need to run TABLO and then either GEMSIM or the TABLO-generated program.]
You will see that the run crashes. The LOG file NOSOL1.LOG indicates that the program has completed about 44.948 percent of the simulation. The
relevant line (just before the end of the LOG file) is:
[Have completed about 44.948898 percent of the simulation.]
Just above that is a note that the updated value of Y has failed the "GE 0" test - that is, Y has become negative.
This is just what you should expect, given that X cannot become larger than SQRT(6)=2.449489 without Y becoming negative. Notice that, after 44.948 percent of the simulation, c_X is 0.44948 so that X has incraesed from 2 to 2.44948 which is very close to SQRT(6).
So here is a simple example of GEMPACK being able to tell that a simulation has no solution.
Finally, it should be possible to increase X to just less than SQRT(6). This is done in Command file NOSOL1A.CMF where the shock to c_X is equal to 0.445. If you run NOSOL1A.CMF you will see that it solves ok. If you look at the Solution file in ViewSOL you will see that the post-simulation value of Y is about 0.0219. That is correct since 6-2.445^2=0.21975.
In the standard GTAP model, there are lots of range restrictions. For example, Coefficient VDGA is declared with a line beginning "Coefficient (GE 0)". In the example below, we have taken the standard GTAP.TAB (GTAP Version 6.2, September 2003) and GTAP.STI as supplied with RunGTAP from 2005. The data files are the standard 3x3 ones supplied in version ACORS3X3 with RunGTAP. The closure is the standard GTAP closure. We have given a large negative shock to variable "to" (percentage change in the power of output taxes/subsidies). The shock is -50% but that is ok since in the levels, TO_L is always positive so that a shock of -50% leaves all values positive.
You can download GPNOSOL2.ZIP. This contains the GTAP.TAB, GTAP.STI, various data files from ACORS3X3 (such as BASEDATA.HAR), and Command files NOSOL2.CMF and NOSOL2A.CMF.
Look in NOSOL2.CMF. You will see that the shock is a uniform shock of -50 to variable "to".
Try running NOSOL2.CMF. [First you will have to run TABLO taking inputs from GTAP.STI. If you produce a TABLO-generated program, you will need to compile and link it using LTG.]
You should find that the simulation ends with an error. The end of the LOG file NOSOL2.LOG will tell you that the program has completed about 90% of the simulation (taking many, many subintervals). You will see that it failed because some value (prossibly some component of EVOA) has gone negative.
So here is a second example of GEMPACK being able to tell that a simulation has no solution, this time using a standard GE model.
Finally, if the program was able to complete about 90% of the simulation keeping all required Coefficients positive, it should be possible tp give a shock of a bit less than 90% of the original shock and get a solution. That is what is done in Command file NOSOL2.CMF in which the shock is a uniform -40 shock to variable "to". Try running NOSOL2.CMF and check that you do get a solution and that the convergence is more than satisfactory.
So, when GEMPACK tells you there is no solution, you can also infer a smaller shock for which there should be a solution.
If you have access to RunGTAP, you can carry out the simulation in NOSOL2.CMF. Change to version ACORS3X3, enter the statement "shock to = uniform -50 ;" into the Shocks memo (after clearing it). Select automatic accuracy and Euler 2,4,6 under Solution method on the Solve page. Then click on the Solve button.
This is another non-economic example. There are no range constraints on the Coefficients in the TAB file.
You can download GPNOSOL3.ZIP. This contains the TAB file NOSOL3.TAB and the Command files NOSOL3.CMF.
Try running NOSOL3.CMF. [You will first need to run TABLO and then either GEMSIM or the TABLO-generated program.]
You will see that the run crashes. The LOG file NOSOL3.LOG indicates that the program has completed about 25.00 percent of the simulation. Since B is shocked from 0 to 1.0 in the simulation, after 25% of the simulation, B has reached the value of about 0.25. You can check the levels equations in the TAB file and see that X=0.5 is a solution of those equations when B=0.25. Indeed, if you look in NOSOL3.LOG not far from the end, you can see that X has values near 0.5, just a little bigger or smaller depending on the step number. [The value of X is written in the LOG file at every step because of the statements "xwrite X to terminal ;" and "dws = yes ;" in the Command file.]
The simulation stops because the Variable accuracy is too low - see the line
Variable accuracy "face" number is 0 (out of 10).
near the end of the LOG file.
Again you can tell that if the shock is reduced (to no more than 0.25 or a bit less), the model will have a solution. You might like to try that.
See here to learn how automatic accuracy varies the length of subintervals to keep the values of Coefficients within their prescribed range (if possible).
Go back to
GEMPACK FAQ Page