Variable trimming y area aggregation

[GustavKirkerud]

Variable trimming: an addon that saves computational time by reducing the amount of investment options. An algoritm scans the investment options in each area to identify the ones that are not attractive for investment given the input data on costs, fuel prices and taxes for the model years. It considers dispatchable fuel based power plants, CHP, and heat only boilers.

Area aggregation: The user can specify areas that will be merged. The algoritm then runs through the input data and calculate the appropriate values for the new merged areas and delete values in the areas not used anymore.

[jgeab]

Dear Jon, I have tested the variable trimming add-on and for some reason, when I run the years 2020,2030,2040, and 2050, the objective function in the last year, i.e. 2050, is slightly different, even though it seems like the investments are the same.

Do you get the same problem? My guess is that there is some problem with the set IAGK_HASORPOT, IAGKNY and IAGKN, since by the time you redefine the sets, you have already done something with these sets (defining upper levels for instance), although I have not confirmed the theory. The difference is so small that I would say that either o&M or fixed costs are responsible for this. AGKN could also be key here. If you do not find what the cause of this problem is, I suggest you call this add-on right after the definition of IAGKNY, which in my opinion is the place where it should go to avoid confusions and possible errors with these sets. To do so you probably need to move the definition of the Balbase4 models to Balmorelbb4.inc, but I think this is totally fine since it is "input data". I actually think that we should also move the definition of IAGKN and the rest of the stuff that does not need to be inside the loop of the simulations to Balmorelbb4.inc.

Additionally, I could not test the Area Aggregation add-on because I am missing the file "AREA_AGGREGATION".inc, could you create also a pull request for this data change?

[GustavKirkerud]

Juan, Great that you’ve tried it. Not great that it gives a different result…

Q1. Did you run it myopically or every year in one optimization? I will try to reproduce the issue.

Q2. Does it really work to define the balbase 4 models in balmorelbb4.inc (outside the IYALIAS loop)? Because the sets, like e.g. IY411, changes dynamically in each IYALIAS.

From: jgeab notifications@github.com Sent: tirsdag 4. desember 2018 15:08 To: balmorelcommunity/Balmorel Balmorel@noreply.github.com Cc: Jon Gustav Kirkerud jon.kirkerud@nmbu.no; Author author@noreply.github.com Subject: Re: [balmorelcommunity/Balmorel] Variable trimming y area aggregation (#1)

Dear Jon, I have tested the add-on and for some reason, when I run the years 2020,2030,2040, and 2050, the objective function in the last year, i.e. 2050, is slightly different, even though it seems like the investments are the same. [Image removed by sender. image]https://user-images.githubusercontent.com/45488361/49445905-43a75500-f7d3-11e8-883e-4acd0c4acbce.png

Do you get the same problem? My guess is that there is some problem with the set IAGK_HASORPOT, IAGKNY and IAGKN, since by the time you redefine the sets, you have already done something with these sets (defining upper levels for instance), although I have not confirmed the theory. The difference is so small that I would say that either o&M or fixed costs are responsible for this. AGKN could also be key here. If you do not find what the cause of this problem is, I suggest you call this add-on right after the definition of IAGKNY, which in my opinion is the place where it should go to avoid confusions and possible errors with these sets. To do so you probably need to move the definition of the Balbase4 models to Balmorelbb4.inc, but I think this is totally fine since it is "input data". I actually think that we should also move the definition of IAGKN and the rest of the stuff that does not need to be inside the loop of the simulations to Balmorelbb4.inc. [Image removed by sender. image]https://user-images.githubusercontent.com/45488361/49444869-b400a700-f7d0-11e8-8f5c-739a27ca70ac.png

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHubhttps://github.com/balmorelcommunity/Balmorel/pull/1#issuecomment-444111545, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AgS6lBARjQvIuTFKoOW8OdgYJTDZ_manks5u1oGegaJpZM4ZARBQ.

[GustavKirkerud]

A pull request for area aggregation data file has been made.

From: jgeab notifications@github.com Sent: tirsdag 4. desember 2018 15:08 To: balmorelcommunity/Balmorel Balmorel@noreply.github.com Cc: Jon Gustav Kirkerud jon.kirkerud@nmbu.no; Author author@noreply.github.com Subject: Re: [balmorelcommunity/Balmorel] Variable trimming y area aggregation (#1)

Dear Jon, I have tested the add-on and for some reason, when I run the years 2020,2030,2040, and 2050, the objective function in the last year, i.e. 2050, is slightly different, even though it seems like the investments are the same. [Image removed by sender. image]https://user-images.githubusercontent.com/45488361/49445905-43a75500-f7d3-11e8-883e-4acd0c4acbce.png

Do you get the same problem? My guess is that there is some problem with the set IAGK_HASORPOT, IAGKNY and IAGKN, since by the time you redefine the sets, you have already done something with these sets (defining upper levels for instance), although I have not confirmed the theory. The difference is so small that I would say that either o&M or fixed costs are responsible for this. AGKN could also be key here. If you do not find what the cause of this problem is, I suggest you call this add-on right after the definition of IAGKNY, which in my opinion is the place where it should go to avoid confusions and possible errors with these sets. To do so you probably need to move the definition of the Balbase4 models to Balmorelbb4.inc, but I think this is totally fine since it is "input data". I actually think that we should also move the definition of IAGKN and the rest of the stuff that does not need to be inside the loop of the simulations to Balmorelbb4.inc. [Image removed by sender. image]https://user-images.githubusercontent.com/45488361/49444869-b400a700-f7d0-11e8-8f5c-739a27ca70ac.png

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHubhttps://github.com/balmorelcommunity/Balmorel/pull/1#issuecomment-444111545, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AgS6lBARjQvIuTFKoOW8OdgYJTDZ_manks5u1oGegaJpZM4ZARBQ.

[GustavKirkerud]

I did some testing and I managed to reproduce a similar error. To me it seems like the problem is related to running very small problems where the model can find two solutions that both are optimal. Then in the next simulation there are some change in conditions like decommission, where the solution found in the previous simulation matter.

E.g. in 2030, the model invested the same Muniwaste plant, but in a different area within the same region in SE3. The model showed the same VOBJ in both cases. In the next simulation year the different location did matter and so the objective value also shows a difference.

I did some testing and when I increase the amount of time slices and investment horizon the difference are reduced. This is, according to my explanation, because the probability of finding to equal solutions are minimized.

See attached excel sheet for differences in VOBJ both for the variable trimming addon and Area aggregation addon. For VT the difference is reduced to zero % when running just a little more complex problem. For area aggregation the difference is stays well below 0.1% in tested cases. Usually around 0.02%

VT_VOBJ.xlsx

[jgeab]

That is great to see! Thanks Jon! Anyway, I think moving this "add-on" to the beginning of the .sim file would be a convenient thing to do to avoid possible discrepancies with the rest of the .sim file. Do you agree? I see this as a very useful balmorel option instead of an add-on ;)

[GustavKirkerud]

I think it would be ok to put it earlier in the .sim file, the only thing is that it's nice to have it inside the IYALIAS loop because I need some of the sets defined there. But that can also be done in the beginning og variable trimming scrips. Exactly where do you suggest to call it?

Variable trimming now adds quite a few parameters and sets, so to keep the main code "clean" it would be nice to keep it somehow separate I think.

[jgeab]

Dear Jon, I have had a look again at the pull request and I believe that both add-ons should be moved to the folder "auxils". Both add-ons are purely data processing and I foresee potential unnecesary conflicts with other add-ons in the future which can be easily avoided. The idea would be to read the original files, apply the processing and create as an output the new .inc files. What do you think? Do you see any major need to keep them inside the code?

[GustavKirkerud]

Juan,

Area_aggregation I think works ok with what you propose even though it will make it a little less convenient to use.

For Variable_trimming it's the same issue except here it becomes more important. Because a very useful utilization of variable trimming is that with a change in tax, fuel prices etc. which is common in sensitivity analyses, technologies are trimmed away accordingly. Executing the module in a separate run would be tedious. It also depend on model settings such as Y and WMODEL. Also, input parameter AGKN is not defined over Y set. So I suggest to keep it in the model somehow.

[jgeab]

Dear Jon,

I understand what you say. Let's so far just include them as they are ;)