Veda2.0 Released!


reporting UC created by VEDA-BE?
#1
Hi,

I have some UserConstraints in VEDA-BE that don't exist in VEDA-FE: IMP, EXP, LUMPINV, INSTCAP (in the two lattest's case, associated with Cap_New Attribute).

What bothers me is that I do not seem to have activated any lump investment switch, and those "user constraints" do not appear in VEDA-FE. They show up in VEDA-BE when I somehow force massive investment in renewable energy sources through a  "UC_COMPRD" constraint.

If someone could explain what those "user constraints" mean, and where they come from, that would be really nice!

Thanks,

Sebastien
Reply
#2

This is not actually a VEDA issue. 

The dimensions of the reporting parameters are defined in the file Times2Veda.vdd.  Initially (in 2004), they appear to have been defined to be the following:

[Dimensions]
Attribute attr
Commodity c
Process p
Period t
Region r
Vintage v
TimeSlice s

However, then someone thought that it would be nice to have the user constraint marginals reported as well.  Consequently, in 2006 the new dimension  UserConstraint (uc_n) was added at the end.

Nonetheless, over time there were further requests for new reporting parameters. At that point, there were already so many VEDA-BE databases in use that it would probably have caused problems to add more dimensions (and it would also make the databases bigger).

Therefore, the UserConstraint dimension has basically become as an Other_indexes dimension, which is used by the following reporting attributes not related to UC_N:

  • VAR_NcapR -  for the name of the cost/benefit indicator
  • EQ_IreM  -  for IMP/EXP
  • Cap_New  - for the name of the reporting indicator (LUMPINV, INSTCAP)
  • Cost_Inv   -  for the  hurdle rate indicator
  • Cost_Invx  -  for the hurdle rate indicator
  • Cost_NPV  -  for the hurdle rate indicator
  • Time_NPV  -  for the annualising type indicator
  • Reg_wobj -  for the objective component indicator
  • Reg_ACost -  for the objective component indicator

It would be easy to change the name of the dimension in the file Times2Veda.vdd (you could even do that by yourself).  But I suspect that you would then no longer be able to import new results into existing databases, and that's why it has not been renamed thus far.

Reply
#3
Thank you Antti for this explanation. I do not need to change it at all, it works well this way, but I'm glad to have the "translation" as well now :-)

One last thing, I did not find a description for LUMPINV/INSTCAP, my first guess is that it would be reporting the nature of the investment made by TIMES as described p.148 and next in the manual (then my modeling would be wrong somehow since the LUMPINV relates in my case to wind turbines but this is an unrelated issue :-) ), is it the case?

Thank you very much!
Reply
#4

Hmm..., page 148 and next?  I just looked at Part II, page 148, and there starts the section 5.2.4 Decommissioning (dismantling) capital costs. ???

In any case, the Cap_new reporting attribute reports the lump sum investment costs (as opposed to annualized investment costs) and the corresponding new capacity installed in each period.  The lump sum investment cost thus represents the total investment costs discounted to the beginning of the commissioning year (so including any interest during construction and the impact of any hurdle rate).

Concerning the UC_N issue, I think we could add a subset of the proper user constraint names automatically into the results database, to make it more clear. I will see if that can be added in the next version.

Reply
#5
Well, for some reason in my documentation p.147 is the beginning of the explanation about the case disjunction for investment (Cases 1a, 1b etc.), so I thought this was what it was about. Anyway, my interpretation was wrong, so thanks for correcting me!
Reply
#6
Just saw this post and would like to add on Antti's comment on CAP_NEW - Is it correct that CAP_NEW discounts from the middle of a period to it's start year if no NCAP_ILED is defined for a technology? In the global model, where periods have 10 years duration, this discounting factor increases the reported lump sum investment (LUMPINV) costs significantly compared to the calculation based on pure investment costs and new capacity (NCAP_COST x VAR_NCAP), in particular when NCAP_DRATE is high (e.g. as I assume for residential solar PV). 
Reply
#7
See: CAP_NEW discounting?
Reply
#8
Hi there Antti, I'm also interested in Tom's question above but the link seems to be broken?

I tried to calculate LUMPINV manually just to check I understand how the model treats technology-specific hurdle rates, but I can't seem to generate the same results I get in BE.

My example for solar PV is attached. My understanding, as per the TIMES documentation and definition above, is that the 2010 LUMPINV should be the total of annualized investments for the total technology lifetime (including NCAP_DRATE), discounted by G_DRATE to the beginning of the commissioning year (which in this case is the same as the investment year, i.e. 2010, since I have specified no ILED). 

The result I get is close (see attached Excel) but not quite right. I presume I'm missing something very basic. Any guidance would be much appreciated Smile  

Thanks!


Attached Files
.xlsx   LUMPINV.xlsx (Size: 15.61 KB / Downloads: 11)
Reply
#9
Dear okerr1,

Thanks for your question. However, I think the link above does work OK.  Shy

I cannot reproduce your LUMPINV value myself, using the data you provided. 
Before I can explain in detail how the value you reported is computed, I of course need to be able to reproduce your result. Therefore, could you please first post a fully expanded view of the data for the process, from Browse -> TIMES View.  In addition, please also disclose your settings for MID_YEAR and DISCSHIFT (in the VEDA Control Panel), as well as you period definition for 2010 (the B/E years).

Checking it quickly again, I think the LUMPINV reporting is quite correct with the default settings (no MID_YEAR, no DISCSHIFT), but I can also see that with non-default settings it may not be fully consistent, and so it is good to check it now, before the upcoming TIMES v4.0 release.
Reply
#10
Thanks for the quick response Antti.

Not sure why the link wasn't working for me before but seems to be now--very helpful! I've attached the relevant process information and control panel settings. Does that help?

On a related note, I'm curious how the same process works for technologies where I *have* specified a lead time (e.g. nuclear and hydro). My understanding is that ILED is essentially the equivalent of construction lead time i.e. the gap between when an investment decision is made and the capacity becomes available. Over this period, investment during construction (IDC) accrues based on whatever you set as the NCAP_DRATE. Will this IDC show up in LUMPINV the first year capacity is available? E.g. for a technology with an ILED of -8, if I postpone the technology availability to a certain start year e.g. 2020, is the investment decision made in 2012, with LUMPINV in 2020 reflecting IDC as well as NCAP_COST * VAR_NCAP?


Attached Files
.docx   ESOPV105 key data in TIMES view.docx (Size: 60.42 KB / Downloads: 9)
Reply
#11
Apologies for the link confusion. ETSAP website has been revamped and moved to a new hosting environment. You caught the forum in transit...
Reply
#12
(13-08-2016, 02:17 PM)AKanudia Wrote: Apologies for the link confusion. ETSAP website has been revamped and moved to a new hosting environment. You caught the forum in transit...

No problem, thanks for the clarification. I'd noticed issues with a few links and still getting Error 404 messages for some things (e.g. accessing TIMES documentation), but I've found I everything works if you go directly through the ETSAP website. Just in case anyone else has been having similar issues during the transition.

I'm guessing the answer is no, but I don't suppose this could be affecting other things like licensing? I've been having an issue with my Veda license that suddenly started yesterday (see: http://forum.kanors-emr.org/showthread.php?tid=470) Could this be linked to ETSAP moving to a new hosting environment?
Reply
#13
Ok, I see you are using the modified OBJ formulation.

Note that because the investment costs decrease between 2006 and 2010, the Milestone Year definition affects the investment cost (the investment for T=2010 is spread on the years M(T-1)+1,...M(T)).
I was able to reproduce the value you reported by assuming that you have 2006 also as a MILESTONE year, i.e. the new investments for 2010 are then spread over 2007, 2008, 2009, 2010.

Can you confirm that 2006 is also a Milestone year?  If so, I will then post the detailed calculation reproducing the value in an Excel file, with explanations.
Reply
#14
(13-08-2016, 06:45 PM)Antti-L Wrote: Can you confirm that 2006 is also a Milestone year?  If so, I will then post the detailed calculation reproducing the value in an Excel file, with explanations.

Yes, that must be it! 2006 is a milestone year. That would make more sense.
Reply
#15
Ok, yes, that seemed to make sense, if 2006 is indeed a Milestone year in the model.

However, now I discovered from the new screenshot that you have defined NCAP_TLIFE=25, although you had used 20 years in your own Excel file!
Using TLIFE=ELIFE=25, my attempt to reproduce the value now again no longer works.  Can you still check again whether TLIFE is really 25 and not 20 for this process in USA, and whether no ELIFE has been defined for it?
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)