Download the latest version of VEDA-FE (45824) and VEDA-BE (492012)

Veda Application Installation guide


Solve Time Under SO2,NOX,PM2.5 Taxes
#1
I have a VEDA/EPAUS9rT question. I am running the model with a SO2, NOX, and PM2.5 tax. Unfortunately the model takes about 14 hours to run and then gives me a GAMS Status prompt "Resource Interrupt/Intermediate Infeasible/0.0002".

It seems that there isn't anything wrong with VEDA it may be that the optimization is running up against a time limit. 

What is best to do in this situation? Is there a way to increase the time limit? Or is there another strategy you use in this type of situation? I haven't heard of the model taking this long to solve for others, usually about an hour, but I also haven't heard of others implementing these taxes.

Thank you,

Mike
Reply
#2
Indeed, I can see the default "resource limit" being defined by RESLIM=50000 in the RUN files VEDA generates. That is 50000 seconds wall-clock time, which is about 14 hours.  So, if you really need more time, you can just adjust that, in the RUN file template.

But there are some more limits: The default iteration limit may also be imposed (I am seeing ITERLIM=999999).

However, as you say that the model takes usually about one hour to solve, the solver may well be having numerical problems with your current runs. If the model is numerically stable, you should see that after the barrier and crossover phases the solver will spend only a short time in the final simplex iterations.
Reply
#3
(17-03-2019, 12:36 AM)Antti-L Wrote: Indeed, I can see the default "resource limit" being defined by RESLIM=50000 in the RUN files VEDA generates. That is 50000 seconds wall-clock time, which is about 14 hours.  So, if you really need more time, you can just adjust that, in the RUN file template.

But there are some more limits: The default iteration limit may also be imposed (I am seeing ITERLIM=999999).

However, as you say that the model takes usually about one hour to solve, the solver may well be having numerical problems with your current runs. If the model is numerically stable, you should see that after the barrier and crossover phases the solver will spend only a short time in the final simplex iterations.


Hi Antti,

Thank you for your message. Interestingly the SO2,NOX,PM2.5 taxes solved by themselves all solve in about an hour.

I tried to solve the SO2,NOX,PM2.5 tax scenario with RESLIM=100,000 but it an optimal solution is not reached in this time frame either. Interestingly, when I also add a CO2 tax to the SO2,NOX,PM2.5 taxes, the model solves. I added a small CO2 tax of $0.01 per ton of CO2 and then the model solved in about 8 hours. Is this strange/should I be concerned that something is not working properly?

Thank you,

Mike
Reply
#4
You provide rather little information about the performance issue. When the model runs take a long time, can you give the split of this time into barrier time, crossover time, and the time for the iterations after that?  If you use the option SYSOUT=ON you will have this info in the listing file.

As mentioned before, long run times often signify numerical problems, and I think your report fits well with that explanation. Numerical problems often manifest in the way you describe: some runs may go well but others don't. But usually the extra time is spent after barrier and crossover, signifying numerical problems.

If you want to go after it, I would say the first thing to try for improving numerical stability is to get rid of the dummy import processes (disabling them altogether).  Of course, that requires that your model is first verified feasible. If you have any dummy import flows in the solution, your model is in fact infeasible, and the dummy flows just give you a "fake" feasible solution.
Reply
#5
(23-03-2019, 03:21 AM)mbr1818 Wrote: I added a small CO2 tax of $0.01 per ton of CO2 and then the model solved in about 8 hours. Is this strange/should I be concerned that something is not working properly?

Concerning this specific question, in addition to general numerical problems, this might specifically be related to modelling mistakes leaving some free flows into the model. Free flows are one of the many causes of numerical problems. You should check that the QA_check.log produced in the working folder does not contain errors or warnings, or if it does, you as the modeller know that they are in fact harmless.

Specifically, warnings under the following title indicate likely free flows, and those with IO=OUT are most likely serious:  *** RPC in TOP not found in any ACTFLO/FLO_SHAR/FLO_FUNC/FLO_SUM
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)