FIXOM and VAROM vintage dependent?

[doonggus]

Dear,

I believe two attributes, FIXOM and VAROM, are vintage depdent.

For example,

                     FIXOM~2020 FIXOM~2030 Life

Solar Panel         100               50             20

from above example, the solar panel installed in 2020 will have fixed O&M costs 100 per annual over its lifetime (2020~2040), and the solar panel installed in 2030 will have fixed O&M costs 50 per annual over its lifetime (2030~2050).

Is this correct? I just want to check this!

If not, could you please let me know which attribute I should use?

Thank you!

[Antti-L]

FIXOM and VAROM are VEDA aliases for the TIMES attributes NCAP_FOM and ACT_COST.

NCAP_FOM is a fixed cost and is always vintage-dependent in TIMES (unlike in MARKAL). You can also apply MULTI and SHAPE indexes on it, to make it calendar-year-dependent or age-dependent.

ACT_COST is a variable cost and is never vintage-dependent in TIMES.

Yes, it is correct.

[doonggus]

Okay!! It is clear!

Thank you!

[Raulm]

Hey All,

I am experiencing some strange behavior regarding FIXOM values from some of my electricity technologies. 
For instance, I set for EUSW (Urban Solid Waste) a FIXOM equal to 250,000 ($/MW), as presented in the file#1 attached (upper table). I also added the file#2 with the same issue for CSP.

However, if I divide the annual fixed costs by the installed capacity (Cost_Fom  by VAR_Cap) as expected I get 250k, but also very strange values even bigger than 250 K (lower table below). I don't have any additional scenarios for this technology which could be causing conflict between FIXOM values and FIXOM does not increase/decrease along the period.

As I set the FIXOM values only for years 2010 and 2050, WOuld any interpolation settings causing the problem? In order to avoid problems, should I define FIXOM for every year within the period?

   


   



Thanks,
[img]www.google.com[/img]

[Antti-L]

There are I a lot of "variables" at play here, and so I am not able to see the strangeness in what you presented.
There is simply not sufficient information to deduce much out of it, or give any useful answer. One would need to know e.g.:

• All your RUN options (what you have in the RUN file)
  


• The relevant technology data for the process(es) in question (e.g. NCAP_TLIFE, NCAP_ILED etc.)
  


• The period definitions (B(t), E(t), M(t))
  

Anyway, please note that by default the Cost_Fom reporting parameter gives the fixed costs at each Milestone year, while the Var_Cap reporting parameter gives the average available capacity in each period.  I think that most likely explains the variation in the "unit cost" you have calculated. You are probably also using NCAP_ILEDs, which are a major (but not only) cause for such cosmetic variation if you calculate unit costs by dividing the costs in each milestone year by the available capacity in the period.

I am sure you have read the documentation, which says that all cost parameters are by default fully interpolated/extrapolated, and so I don't see why you ask "should I define FIXOM for every year within the period?".

[Antti-L]

Additional comment:

As noted above, by default the Cost_Fom reporting parameter gives the fixed costs at each Milestone year.
But by using the following options, you can have the costs reported in terms of levelized annual costs (over the process lifetime):

$SET OBLONG YES
$SET ANNCOST LEV

Therefore, you should try these options first.  If you then get constant unit FOM costs, you then know why you didn't get such earlier. You can find the OBLONG switch in VEDA-FE, but I am not sure about ANNCOST, which you may need to add to the RUN file template.

[Raulm]

Hi Antti,

sorry for this late reply.

You were right. I made a few modifications and the desynchronization between capacity-related-costs and the current installed capacity at a given milestone year are not in place any more.

As suggested, I set the control switches to $SET OBLONG YES and $SET ANNCOST LEV. Besides, I set the ILED to negative values, as suggested in other post in the forum.

thanks,