Posts: 1,959
Threads: 26
Likes Received: 57 in 49 posts
Likes Given: 16
Joined: Jun 2010
(17-04-2019, 02:52 AM)ach Wrote: Thanks! I didn't know about this variable since it isn't mentioned in the documentation (part II, IV) and I didn't think it would impact deployment.
NCAP_SEMI is not a variable, but an input parameter, just like NCAP_DISC is an input parameter. I believe it is quite well documented in Part II, so I think you could take a look at it there?
Posts: 47
Threads: 13
Likes Received: 0 in 0 posts
Likes Given: 0
Joined: Nov 2018
Thanks for the quick responses. I was able to fix the overproduction issue using semi-discrete intervals.
Posts: 1,959
Threads: 26
Likes Received: 57 in 49 posts
Likes Given: 16
Joined: Jun 2010
Thanks for acknowledging that you found the documentation of NCAP_SEMI.
(17-04-2019, 02:19 AM)ach Wrote: I was unable to find the all DD files, but the RUN files are attached. The directory with DD files is polluted with multiple DD files that seem to match multiple models, and I picked the most obviously relevant one. Please let me know if this isn't adequate.
As it seems that you have not found any technical problem in the model to be investigated, there is no need to have the files now. But for your information: The
*.DD files and the
*.RUN file comprise the
full set of model input data for TIMES, and so to reproduce any problem in a model run, one would need to have these files. However, your ZIP file (veda files.zip) contained only a single DD file, jpn_main_ts.dd, with the sole declaration SET ALL_TS / ANNUAL /.
Concerning the modelling problem: "
I was hoping it would retire in a more sensible way. That is, producing a gradually declining amount of electricity from nuclear, for instance, instead of switching off nuclear for 20 years and turning it on for 3 years before switching it off again."
Earlier you said that "
I explicitly defined STOCK values for it, hoping it would retire gradually, interpolating between these points." This earlier statement can be verified correct: 1) you have defined the STOCK (=PRC_RESID) values, and 2) the capacities are indeed retiring gradually, interpolating between the data points. However, I can see nothing in the model that would correspond to the additional requirement of retiring "in a more sensible way". There are many options available, but I see none taken in your model.
Posts: 47
Threads: 13
Likes Received: 0 in 0 posts
Likes Given: 0
Joined: Nov 2018
Thank you for your response. As I said, I considered forcing the generation of an intermediate commodity to an amount that corresponds to the capacity/STOCK values (as I did for hydro, but there it was easier because it was only one STOCK value), but despite looking at the documentation again, I'm unable to come up with a more elegant way. Could you please be so kind as to share any tips that you may have? I basically want nuclear's existing, "unretired" capacity to be operating at a 100%, as it would in real life.
Posts: 1,959
Threads: 26
Likes Received: 57 in 49 posts
Likes Given: 16
Joined: Jun 2010
Oh, but that's quite easy then. Just define NCAP_AFA(LO) for the existing process, starting from 2020 (you cannot change the history). Operating at 100% annual capacity factor is hardly possible in real life, due to maintenance outages, but perhaps 95% could be. So, maybe NCAP_AFA(reg,2020,prc,LO)=0.95, and NCAP_AFA(reg,0,prc,LO)=5 for the interpolation option.
Posts: 47
Threads: 13
Likes Received: 0 in 0 posts
Likes Given: 0
Joined: Nov 2018
Yup, 90-95% would be realistic, thanks!