Division by zero

Problems with modeling
Post Reply
Likey
User
User
Posts: 6
Joined: 3 months ago

Division by zero

Post by Likey » 3 months ago

Hi everyone,

I keep getting the same error messages (e.g. *** Error at line 2618: division by zero (0) / **** Exec Error at line 2618: division by zero (0)) in multiple lines, but I don’t know why. Neither for the original code (EMMA.gms) nor for the lst file (EMMA.lst) does the error make sense as there is no division happening these “error” lines. How can that be? How can I find the error? Any suggestions where to look?
grafik.png
grafik.png
(The pictures show line 2618 in the gms and lst files. As far as I can tell no division is happening in these lines (in gms file 2618 is a comment line * and in the lst file values are displayed)

I'd be very thankful for your help!

Cheers
Attachments
grafik.png

User avatar
bussieck
Moderator
Moderator
Posts: 342
Joined: 3 years ago

Re: Division by zero

Post by bussieck » 3 months ago

Instead of pictures please attach the text files. In any case, the line number mentioned in the execution error refers to the line number in the echo print of the input file (see https://www.gams.com/latest/docs/UG_GAM ... eInputFile). The echo print might be suppressed (via $offlisting), so if you are debugging, remove/comment the $offlisting from the model source and rerun. Then find the line number mentioned in the execution error in the echo print and voila that's where you have the error.

-Michael

GFA
User
User
Posts: 8
Joined: 1 year ago

Re: Division by zero

Post by GFA » 3 months ago

Maybe you include some files with $include? Then the line numbering is different because you have to add the number of lines of the included files.
But just look in the listing file, there it will print the GAMS code including the $include files and the numbering will be correct.

Likey
User
User
Posts: 6
Joined: 3 months ago

Re: Division by zero

Post by Likey » 3 months ago

Thanks guys!

Removing the $offlisting helped to find the actual lines in which the error is happening!

The first error (which is similar to the other errors) is in line 2631

2630 test(r) = sum(t,profile(t,"windOn",r)) * sc;
2631 profile(t,"windOn",r) = profile(t,"windOn",r) * i_FLH(r,"windOn") / test(r);

apparently GAMS cannot find/sum up the profiles of (windOn); therefore test is zero, which leads to a division by zero error;

This is in line with findings in the lst file: GAMS does not/cannot read in the profile of windOn


1 .wind 0.706
1 .windOn UNDF
1 .windOf UNDF
1 .windNo UNDF

The fact that the windXX (windOn, windOf, windNo) profiles are undefined is probably the key problem (and most likely also the reason for the other errors); But why are they undefined / zero?

The profiles are define in the gms code in line 1931-1934

profile(t,"wind",r) = i_wind(t,r,year);
profile(t,"windOn",r) = i_windOn(t,r,year);

i_wind... is defined in line 1791-1796

par=i_wind rng=wind!a6:bd8767 rdim=1 cdim=2
par=i_windOn rng=windOn!a6:bd8767 rdim=1 cdim=2

The excel structure is the same for windOn as it is for wind; why does it work for wind and not for windOn? Any thoughts? How can I make sure that the additional wind profiles (e.g. windOn) are correctly read in by GAMS?

Cheers
Last edited by Likey 3 months ago, edited 1 time in total.

GFA
User
User
Posts: 8
Joined: 1 year ago

Re: Division by zero

Post by GFA » 3 months ago

GDXXRW should write the data to the GDX-file "data_ts.gdx", is the data for i_windOn/i_windNo/i_windOf in there?
If not, you can let GDXXRW write a log-file which might give clues why the data is not read in properly:

Code: Select all

par=i_windOn             rng=windOn!a6:bd8767            rdim=1 cdim=2  log=i_windOn.txt

See also:
https://www.gams.com/latest/docs/T_GDXX ... EDIATE_LOG
and
https://www.gams.com/latest/docs/T_GDXX ... IONS_TRACE

Regards,
Auke

User avatar
bussieck
Moderator
Moderator
Posts: 342
Joined: 3 years ago

Re: Division by zero

Post by bussieck » 3 months ago

I guess something goes wrong when you read data from Excel. As Auke says, gdxxrw seems not successful reading the spreadsheet. EMMA.gms ignores good practice when calling an external program: Make sure the return code is good.

Code: Select all

$IFTHEN %LOADDATA% == '1'            
   $CALL GDXXRW.exe        input\data_ts.xlsx     @data_ts.txt
   $IF ERRORLEVEL 1 $abort "Problems with gdxxrw"
$ENDIF   
$IFTHEN NOT EXIST data_ts.gdx        
   $CALL GDXXRW.exe        input\data_ts.xlsx     @data_ts.txt
   $IF ERRORLEVEL 1 $abort "Problems with gdxxrw"
$ENDIF   
$GDXIN data_ts.gdx
-Michael

Likey
User
User
Posts: 6
Joined: 3 months ago

Re: Division by zero

Post by Likey » 3 months ago

Thank you, Michael and Auke!

I had a look at the GDX file and found, that the entries for windOn, windOf, windNo are indeed empty. Here's the link to the GDX file https://gigamove.rz.rwth-aachen.de/d/id/qp6PDYfYaYCXDd

As suggested by Auke I tried to implement a log file (in line 1832) to detect the error / reason why the data is not read in properly:

Code: Select all

par=i_windOn             rng=windOn!a6:bd8767            rdim=1 cdim=2 log=i_windOn1.txt trace = 2
Unfortunately I cannot find the log file neither in the output nor in the project folder, even though I deactivated the following code (in line 3370)

Code: Select all

*execute "del     *.log"
How can I find the log file? More importantly: What is the reason why the data is not read in properly?

PS: @Michael, thanks a lot. I implemented your code (in line 1851) but I don't really know what to do with it or what difference it makes. Could you please elaborate a bit how it can help me and what I have to do with it? Sorry, if some of these things seem obvious for you, but I'm a bloody beginner.

Best,

Leo
Attachments
EMMA lst.txt
(13.44 MiB) Downloaded 20 times
Last edited by Likey 3 months ago, edited 1 time in total.

GFA
User
User
Posts: 8
Joined: 1 year ago

Re: Division by zero

Post by GFA » 3 months ago

I think it is also possible to state the path GDXXRW should send the log-file to (for example log=c:\GAMSmodel\log.txt)
You could also use a "$stop" after the GDXXRW statement, then you don't need to wait for all other GAMS code to be run.
Note that the GAMS-code you turned off is deleting all the .log files (and the log-file itself is states as a .txt, however you can also make a log file with a .log-extension if you want).
It would be easier if you could provide us with you Excel sheet (or the structure of it, if you don't wish to share the data), then it would be possible for us to reproduce the error.

User avatar
bussieck
Moderator
Moderator
Posts: 342
Joined: 3 years ago

Re: Division by zero

Post by bussieck » 3 months ago

Leo, the additions I made were not there to make a difference for the data issues. They were there to catch ($abort) if the gdxxrw misbehaves (reports an error) which is does not the case. It just reads zero for your parameter. We would need to see the Excel file to see why this is. I don't think the log will tell you more. How do you run the model: command line, IDE, Studio, ... There are ways to capture the log (which includes the gdxxrw log). The log is as useful as the lst file. You might want to upload this as well.

-Michael

Likey
User
User
Posts: 6
Joined: 3 months ago

Re: Division by zero

Post by Likey » 3 months ago

Thanks to Michael I managed to solve the problem:

Problem: The key problem was, that the excel data sheet was not correctly structured: As windOn/windOf/windNo represent three dimensional parameter (with indexes t, r, and year), these dimensions need to be correctly indicated in the excel read in range. I omitted the column indicating the time of each cell / element. Hence, GDX could not assign the values to their timeslots which led to the fact that the values weren't read in.

Solution: Adding the (omitted) time dimension / column to the excel sheets of windOn/windOf/windNo and deleting the old (incorrect) GDX files solved the problem. Don't forget to delete the old GDX files, otherwise GAMS won't read in the correct, new values.

Thanks again, Michael!

Post Reply