Cautions about dynamic /static calculations

 Top  Previous  Next

The types of calculations are very important for 2 reasons

•When static or repeated static calculations are present and some of the calculation input data are revised between the point where the calculations executed in the model solve statement appears then you must repeat the static calculations if you want the results to be current
•When you have repeated static calculations then the data changes may buildup and you may need to reset the data to base levels if you want your data always to revert back to the base case

Examples:

(nondyn.gms)

Below the first two solves are identical even though the Price parameter is altered. Why?  The answer is because the calculation for Revenue is not updated after the Price change.  The repeated Revenue calculation and second solve corrects this.

 

set crop /corn/

parameter price(crop),yield(crop),cost(crop),revenue(crop);

Price(Crop) = 2.00;

Yield(Crop) = 100;

Cost(Crop) = 50;

Revenue (Crop) = Price(Crop)*Yield(Crop)-Cost(Crop);

Equations        

obj                 objective function

Land                  Land available;

Positive Variables         Acres(Crop)        Cropped Acres

Variables                 Objf        Objective function;

obj..                objf=E=Sum(Crop, Revenue(Crop)*Acres(Crop));        

Land..                Sum(Crop, Acres(Crop))=L=100;

Model                FARM/ALL/

SOLVE FARM USING LP Maximizing objf;

Price ("corn")=2.50;

SOLVE FARM USING LP Maximizing objf;

Revenue (Crop)= Price (CROP)*Yield(Crop)-Cost(Crop);

Solve FARM Using LP Maximizing objf;

 

One can revise the model so it contains a dynamic calculation that eliminates the problem.  Namely, computing revenue in the objective function corrects this. (see the bottom of nondyn.gms)

 

Obj..         ObjF=E=SUM(Crop,(Price(CROP)*Yield(CROP)

                         -Cost (CROP))Acres(CROP);

 

Note one can go too far with this making a model too complex.

 

Another example is also in order on data preservation/cumulative data changes in the case of repeated static calculations. (repstatic.gms)

 

GAMS lives for the moment, when a calculation is issued then all prior values are overwritten for calculated items.

 

SCALAR LAND /100/;

PARAMETER SAVELAND;

SAVELAND = LAND;

SET LANDCHANGE  SCENARIOS FOR CHANGES IN LAND 

/R1,R2,R3/

PARAMETER 

VALUE(LANDCHANGE) PERCENT CHG IN LAND

                                /R1 +10 , R2 + 20 , R3 +30/

LOOP ( LANDCHANGE,

       LAND = LAND * (1 + VALUE ( LANDCHANGE ) / 100. )

       display "without reset" ,land);

 

Running this model yields

 

----      9 without reset

----      9 PARAMETER LAND      =      110.000 = 100*1.1

----      9 PARAMETER LAND      =      132.000 = 100*1.2*1.1

----      9 PARAMETER LAND      =      171.600 = 100*1.3*1.2*1.1

 

Here I see cumulative changes and need to ask if they are intended.

 

If you want to revert to the original values then you have to instruct GAMS to do that.  Replace the loop with (repstatic.gms)

 

LOOP ( LANDCHANGE,

      LAND=saveLAND*(1+VALUE ( LANDCHANGE ) / 100. )

      display "based on saveland" ,land);

or

LOOP ( LANDCHANGE,

       land=saveland;

       LAND = LAND * (1 + VALUE ( LANDCHANGE ) / 100. )

       display "with saveland reset", land);

 

Both yield

 

----   12 PARAMETER LAND     =      110.000 = 100*1.1

----   12 PARAMETER LAND     =      120.000 = 100*1.2

----   12 PARAMETER LAND     =      130.000 = 100*1.3

 

Generally if you are changing items between solves, then reset them to base values to avoid accumulating changes.