Veda2.0 Released!


Divergent LCOE and marginals
#1
Dear all,

recently I came across a strange observation regarding the LCOE value. I had a feasible model and tried to vary the CHPR value and see how the LCOE changes. Few changes went normal, but then as I reached certain value of CHPR (far from the counted limit), LCOE as well as all  marginals raised to the maximum. As I continued to vary CHPR and approached to the counted limit, LCOE and the marginals got back to expected values. Later I found out, that not only CHPR caused the divergent LCOE. For example, I once made user constraints for photovoltaic plant so that I got dummy imports for the UC, and the LCOE raised up as well. Interestingly enough, it raised not only for PV plant, but also for all the other plants.

Please see the screenshots attached. They show the divergent LCOE along with another result parameters of the plant and dummy imports. Note that in this case that I show, there are no dummy imports for the UC restricting the chosen plant. CPLEX status was normal completion, integral solution.

Do you have any suggestions regarding what the problem could be?

Thanks

Lukas Novak


Attached Files Thumbnail(s)
       
Reply
#2
The marginals of the dummy imports may be reflected in commodity prices even when there are no visible dummy import flow levels. I suggest that you try running without dummy imports, to avoid any pollution of the marginals by the dummy import processes. Let me know if that helps. If your model is feasible, there is no need to enable dummy imports, which may also cause numerical instability.
Reply
#3
Thank you Antti.
I will try that and let you know as soon as possible.
LN
Reply
#4
Hello,
I tried turning the dummy imports off. At first there was quite a few dummy imports for user constraints, so I eliminated them step by step and was looking how it changes the LCOE. As I eliminated all of them, the LCOE and marginals got back to normal. I thought that was it, but as I tried the same thiing on a different scenario, the LCOE and marginals was divergent again... So I turned the dummy imports for UC off but t did not help. Then I went back to the previous scenario, did not change anything (except turning the dummy imports for UC off), solved it and it didnt had the divergent LCOE and marginals as well...

It almost seems like the problem is occuring randomly. Is there any other thing that could cause the numerical instability?

Best regards
Lukas Novak
Reply
#5
Sorry, let me rephrase the last sentence in the first paragraph:
"Then I went back to the previous scenario, did not change anything (except turning the dummy imports for UC off), solved it and it had the divergent LCOE and marginals as well..."

 I got confused by the problem Smile
LN
Reply
#6
Dear forum,

I am quite certain that dummy imports are not the problem in case of the divergent LCOE and marginals. As I was trying to solve the problem, I came across an interesting thing. If I switch off the "Discrete Investment" option in the settings of a solver, the solver stops using Barrier and Heuristic during the solution. The only one I can see it is using, is the Primal Simplex. When using (only) the Primal Simplex, I never had the problem with the divergent LCOE and marginals. When I switch the "Discrete Invesment" back on, it uses the Barrier and Heuristic and I have the problem back again.

So naturally, it came to my mind, that either I have wrongfully defined the discrete capacities and the Barrier or Heuristic is "confused" and produces an unstable sollution or one of these methods themselves does not work properly. To distinguish these two possibilities, could you please inspect my definition of discrete capacities? Please see the attachment.

Again, I have got no dummy imports for the thechnologies with the discrete capacity and the solution processes normally. All (of them which I saw) energy flows and corresponding technologies are completely fine and stable between runs but only the LCOE and marginals are messed up.


Attached Files Thumbnail(s)
       
Reply
#7
> Again, I have got no dummy imports for the thechnologies with the discrete capacity and the solution processes normally.

Ok, that is good, but did you actually disable the dummy import processes? Fully disabling them would require that you either 1) import the whole model from scratch after unticking all of the VEDA dummy options (NRG, MAT, DEM, User constraints), or 2) you disable the dummy import processes by defining e.g. NCAP_START(r,p)=2200 or ACT_BND(r,'0',p,'ANNUAL','UP')=2, for p={IMPNRGZ, IMPMATZ, IMPDEMZ}.  So, can you confirm having fully disabled them?

Anyway, if you have a reproducible case, I am willing to look at the issue myself if you provide me the full set of TIMES input data files (*.DD, *.RUN) plus the listing file *.LST, for a case that manifests those "divergent" LCOE values.
Reply
#8
Antti,

I unfortunately disabled only the dummy imports for the UC. There also were the other ones for certain processes in the base year, which I could not get rid of. The problem is, that I did not create the model and therefore it is problematic for me to rewrite the base year with confidence that I did it properly. So disabling only the dummy imports for the UC had no effect on the problem and I (just only) believed that a few dummy imports in the BY would not mess up the whole solver. If I get to disable all the dummy imports some time in the future, I will test the model afterwards and inform you about the result.

Since I am neither the creator of the model nor allowed to share any data I, unfortunately cannot provide you with all the .dd files. I would give you all the others including .dd files of scenarios that I made myself, bud I am not able to post them here. The only thing I can post now is the run log. Please see the attachment.


But as I mentioned before, the problem seemed to disappear after I turned the "Discrete Investment" option off while the dummy imports being the same. Don´t you have any ideas why this happened? It really points to a mistake in discrete capacities..



Please note the run log file saying: "Solver did not provide marginals for model TIMES". Knowing why might lead to the solution of the problem.



Thank you for your time Antti.

Lukas Novak


Attached Files
.txt   testvu3_t_run_log.txt (Size: 862.5 KB / Downloads: 2)
Reply
#9
> "Solver did not provide marginals for model TIMES"

Aha... that is of course crucial here.  I think you didn't mention that before.

That message means that when Cplex runs the final solve (by fixing the integer variables), the fixed problem is reported to be infeasible. Your log file also shows that as a remedy, Cplex suggests that you could use the option "relaxfixedinfeas 1". 

The problem usually points to a poorly scaled model, and so you could also try and fix it by properly scaling your model. But as a first attempt, you could test with a few additional Cplex options like "numericalemphasis=1" and "scaind=1", which aim at improving the numerical behaviour of your model.

Therefore, I would suggest to try running the model with the following Cplex options (in Cplex.opt):

scaind 1  (you may already be using this option)
relaxfixedinfeas 1
numericalemphasis 1

I hope that may help.
Reply
#10
Antti,
I struggle to set these parameters to 1. Could you please tell me, if this is the right way, as I show you in the screenshot?
Is it necessary to resynchronize the whole model or something?
I found mysel using CPLEX and this BA121-7 option.
Thanks
LN


Attached Files Thumbnail(s)
   
Reply
#11
Yes, what you have there is fine. 
Just re-run the model then, no need to resynchronize, but you must make sure VEDA will use the new options file.

Therefore, I guess it is best to rename that edited cplex.opt file to, say TEST.opt , and place it then to the AppData\SolverOptFiles folder under your model folder.  And then in the Run Manager, in your Case settings, specify that file in the SolverOptions entry.
Reply
#12
Thank you Antti.
It seems that now I managed to change the parameters. The solution now takes significantly longer at least.
I will let you know the result afterwards.
Reply
#13
Hello Antti
so I let the solver run during the night with the parameters you mentioned set to one, and it overcapped the time limit of 50k seconds and did not find the solution. So I set the "numericalemphasis" back to zero and loosen the restriction on the new discrete capacity, meaning, for example, that I changed the value of 0.924GWe for 12 SMRs to 0.92. It seems that (or both) of the two changes helped.

I looked up some way to force CPLEX to tell you which bounds are too restricting for its solution (something like set datacheck 2), so if the problem appears ever again, I will try to use this mechanism and rewrite these bounds manually.

Thank you for your help Antti.

Best regards
Lukas Novak
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)