Veda2.0 Released!


simulating technology economies of scale
#1
Hi,
first post on the forum.  I have a few questions about different potential methods for simulating economies of scale for a technology. 

1) Is it possible to assign a fixed cost to a technology (i.e. an absolute value $X million dollars) irrespective of capacity rather than a cost that is proportional to capacity ($X million per PJ capacity)?

2) Is there a way to set or enforce a minimum size for a certain process via user constraint?  The goal is to either have the capacity of a technology be zero or greater than or equal to a minimum size.  i.e. VAR_Cap = 0 or VAR_Cap >= MinSize

3) Is it possible to have a supply curve for a resource that starts off more expensive and decreases the more of the resource you use?

4) If these options are not possible, then I think I can probably accomplish something with lumpy investment, but I was hoping to accomplish this without resorting to lumpy investment, which I believe can up model run time significantly. 

Any answers, suggestions, comments are greatly appreciated.  Thank you. 

Chris
Reply
#2
Dear,
I do not think any of these are possilbe with standard LP. Lumpy can, but than your marginal values are not always easy to interpret.
Hope this can be of help.
Wouter
Reply
#3
I'm still open to any other thoughts on these options, but in the meantime, I'm also trying to get discrete investments to work.  I can get the example that Amit provides on this website (http://support.kanors-emr.org/VEDA-FE/SubFile_CaseManager/SubFile_TimesVariants_Switches/DISCRETEINVESTMENTS.htm) working.  However, when I try to apply to my model, I'm not entirely sure what changes need to be made. 

Figure 3 on that webpage shows an absolute lower bound on activity for discrete investments.  I assume that is not required but please let me know if this assumption is incorrect.  My approach to getting my model to handle lumpy investments has been to add an additional column (NCAP_DISC) to my SUBRES_B-NewTechs file.  And for each lumpy technology, add a new row after all of the technology specifications, with a 1 in the Other_Indexes column and the discrete capacity in the NCAP_DISC column. 

Then check the "discrete investment" checkbox in VEDA-FE. 

Is there something else that I am missing? 

thanks!
Reply
#4
I have no experience until now with lumpy investment in TIMES. But can you see the discrete processes in VEDA FE browser ? If you followed all steps (including defining the set of capacities for this discrete invetment like 1,1.5,etc...), I only see the solver to be a problem. Does your solver allow MIP ? Is it solving but without discrete choices ?
Wouter
Reply
#5
I have only set up one discrete capacity size, rather than multiple sizes.  The model is solving but it is not solving without the discrete size.  I've specified 5 PJ/a as the only choice of size for this one plant, but it is giving me a capacity of 2.28 PJ/a in the results.  My solver allows MIP since it solved the example that Amit provides on the webpage. 

I can see in the VEDA FE browser (Process Master) that it is indeed obtaining a value of 5 for NCAP_DISC and the RES looks fine. 

I'm not sure if I followed all of the steps since there appears to be an activity bound on the discrete investments in the instructions, but I didn't do that, because I don't want this to be a constraint (i.e. the model shouldn't have to pick this plant, but if it does it needs to be 5 PJ/a capacity).   
Reply
#6
If you want I can have a look to your example but in this case please upload the template that is not working.

Mauri
Reply
#7
Thanks to Maurizio for his offline help via email! 

After some back and forth, he figured out that the model I was running had some infeasibilities that didn't get caught in my version of Times V296 but wouldn't run in V331 (related to the use of availability factors).  Also had a mistake in the technology process sheet where I was incorrectly specifying the set as DISCINV instead of DSCINV. 

Thanks again for the help!  I'm really glad that there's a good resource here to help me get things working.


Reply
#8
So I spoke a little too soon.  I am definitely getting lumpy investment behavior out of the model, however, it isn't acting as it should. 

The H2 plants (which I specified lumpy investment for) are only built with a certain capacity.  However, it looks like the model is building capacity even when capacity isn't needed.  As soon as the process start year passes, the model is building capacity even if there is no demand for the plant output (i.e. H2).  And it is building capacity each and every model year, even when the capacity is unwarranted.  So plant capacity grows much larger than the capacity shown when there is no lumpy investment.  Also I have specified two possible plant sizes and the model is picking the larger of the two, again even when there is no demand for the plant output. 

I don't have any user constraints (share, growth or capacity constraints) on this technology so I'm not sure why it would be building excess capacity beyond the minimum lumpy capacity requirement. 

I've uploaded a zipped excel file so you can see the strange model behavior.  The lumpy investment sizes are 3.5 and 5.5 PJ/yr.  The plant capacity in the lumpy investment run is as much as 20 PJ/yr higher than in the non-lumpy investment run. 
uploads/116/Output.xls.zip

Also here is a screenshot of the technology specification
uploads/116/Screen_shot_2012-05-07_at_11.30.20_AM.png


Attached Files Thumbnail(s)
   

.zip   Output.xls.zip (Size: 14.46 KB / Downloads: 6)
Reply
#9
Looking at the Output.xls, it seems to me that the odd behaviour might be explained. You allow only a capacity increse of either of 3.5 or 5.5 in each period, and never any more than that. However, it seems that the demand for the capacity (according to the continuous case) appears to be over 41 in the year 2055. Consequently, it may be that in the discerete case the only way (or the optimal way) to satisfy the demand in the later years is to start building the capacity already in 2007, even though the demand is still zero. Does this make sense to you?
Reply
#10
Oh I think I understand what you are saying.  I thought the way I specified the process characteristics was that the model could add capacity in increments of 3.5 or 5.5, not that those were the only possibility for a given year.  But that makes sense.  The model can't add 7, 10.5, 14, etc. . . or 11, 16.5, 22, etc. . . of capacity just 3.5 and 5.5. 

So if I want it to be able to add multiples of these capacities I need to add more sizes past number 2?

thanks Antti!  That is quite helpful.  I will modify the inputs and see if I get different results.


Reply
#11
Hi

Just ran the model with slightly different inputs and it doesn't seem like Antti's hypothesis is correct. 
I changed the discrete sizes so that the largest size would be enough to meet the capacity requirements in any given year and it still starts building early (in the first year the technology is available). 

Here's a new output file:  uploads/116/Output3.xls.zip

Any other suggestions to try or check would be greatly appreciated. 

Chris


Attached Files
.zip   Output3.xls.zip (Size: 19.96 KB / Downloads: 1)
Reply
#12
Hi, is it possible that the model only allows the building of 1 unit size during a period ? I remember in Markal there was an option to allow only binary (0/1) or an integer multiple of the discrete number.
Wouter
Reply
#13
Chris: You are right: my hypothesis was too hastily formulated. Embarrassed

I just run a demo model using your continuous capacity development as a demand for both a process with continous capacity additions and a process with discrete capacity additions (3.5 and 5.5). The results were as shown below:
---- VAR VAR_NCAP  New capacity of a process

                         LOWER          LEVEL          UPPER         MARGINAL

REG.2007.CONTINUS          .              .            +INF            0.2424     
REG.2007.DISCRETE          .              .            +INF            0.7107     
REG.2010.CONTINUS          .              .            +INF            0.1763     
REG.2010.DISCRETE          .              .            +INF            0.6446     
REG.2012.CONTINUS          .              .            +INF            0.0831     
REG.2012.DISCRETE          .              .            +INF            0.5514     
REG.2016.CONTINUS          .             2.2786        +INF             .         
REG.2016.DISCRETE          .             5.5000        +INF             .         
REG.2020.CONTINUS          .             4.5572        +INF             .         
REG.2020.DISCRETE          .             5.5000        +INF             .         
REG.2025.CONTINUS          .             5.6966        +INF             .         
REG.2025.DISCRETE          .             5.5000        +INF             .         
REG.2030.CONTINUS          .             5.6966        +INF             .         
REG.2030.DISCRETE          .             5.5000        +INF             .         
REG.2035.CONTINUS          .             5.6966        +INF             .         
REG.2035.DISCRETE          .             5.5000        +INF             .         
REG.2040.CONTINUS          .             5.6966        +INF             .         
REG.2040.DISCRETE          .             5.5000        +INF             .         
REG.2045.CONTINUS          .             5.6966        +INF             .         
REG.2045.DISCRETE          .             5.5000        +INF             .         
REG.2050.CONTINUS          .             5.6966        +INF             .         
REG.2050.DISCRETE          .             5.5000        +INF             .         
REG.2055.CONTINUS          .              .            +INF            0.0239     
REG.2055.DISCRETE          .              .            +INF            0.0239     

So, with such an evolution in the demand the discrete investments start only in 2016, just like in the continuous case. Anyway, for me it looks like the TIMES DSC facility appears to work well. But why it does not seem to work for you could be very hard to tell without seeing the full model...
Reply
#14
With lots of help, I figured out that the problem was a model problem with my computer (still haven't figured out why yet though).  Mauri and I ran the same model and got very differnet results (his correct and mine very strange, also his model solved in 8 min and mine took over 2 hrs).  I used a different computer and now my results look to be correct and the model solved in 13 min. 

So I think for now I will use the other computer to run the model and try to figure out why the original computer is so messed up.  Maybe a question for Antti: How would I go about trying to figure why the results (and modeling times) are so different.  Would looking at the LST files be of help?

thanks again for all your help (especially Mauri who spent quite a bit of time via email helping me get to the bottom of this).

Chris
Reply
#15

It is very good to hear that you have made progress with your problems.

If you can identify any suspicious differences in the listing files, that might be helpful. Investigating the listing files can often be very useful, but because in this case there seems to be little clue as to where the root cause of the problem is, it is hard to say how much you might be able to conclude out of that.

Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)