Division by Zero
I do not understand why GAMS is not running due to division by zero, see error from lst-file below.

**** Exec Error at line 38675: division by zero (0)
---- 38675 Assignment RTCS_SFR      0.016     0.827 SECS     41 Mb 63420

The model runs if I use a given set of S_COM_FR. However, if I change the S_COM_FR to another profile I get "Gams run ended”. I am sure there is a logic explanation but I cannot really understand why this happens. The number of S_COM_FR in each regions and period is 1008 with 21 stochastic and 48 time-slices. The S_COM_FR represents the PV production profile, and is consequently zero in many of the time-slices.

How can I interpret this error message? How can I change the model or model input to make this work?



If there is a divide by zero, some calculations have undefined values, and GAMS can thus not proceed to solving the model.

S_COM_FR is a multiplier for COM_FR, and I suspect that the divide by zero is caused by S_COM_FR being defined also at some timeslices having a zero COM_FR value.  Therefore, if you have defined any such  S_COM_FR, try removing these unnecessary multipliers. A zero value cannot be multiplied to get anything but zero anyway.

Let me know if this helps...

Thank your help!

I have set COM_FR = 1 for all time-slices so this does not seem to be the solution.

Ok, then it must be something else...

Another possibility: Do you have S_COM_FR defined zero in all DAYNITE timeslices under some parent timeslice?

BTW: Did you find out the reason for the strange demand problem (http://iea-etsap.org/forum/showthread.php?tid=84)

Yes, this was the solution. Thank you!

Some scenarios had no PV production in all daily periods of winter and I guess this was causing that GAMS was not running. Right? For me, this was not obvious since there were PV production in the other seasons.

The model runs if I include a small dummy production in one of the time-slices in the winter season.

Regarding the strange demand problem, I still have not found a solution.

I am glad that the cause for the divide by zero was found. The problem will be fixed in the next version, so that no small dummy production will no longer be needed to avoid the error.

But I am very sorry to hear that the demand problem remains unresolved!


Forum Jump:

Users browsing this thread: 1 Guest(s)