I would like to ask for your experience and a little help defining supply curve using own-price elasticity rather than different technologies.
The reason we would like to use this (more like a top-down approach) method is that our team is considering to model several industry sectors, however some of those are quite heterogeneous and therefore data intensive.
Moreover, due to the lack of time we have, we would like to model the supply-side of these sectors by not defining any technologies (and their cost and technology parameters), but rather considering the technological change as a change in the fuel mix for the given sector. Therefore, we would take into account the fuel costs of the relevant energy carriers as building blocks of the short-run supply curve and aggregate these blocks into one final supply curve.
As quantity "range" (defined by a minimum and a maximum value for an energy carrier as quantity demanded - horizontal axis of the inverse supply curve) for any energy carrier we would provide parameters exogenously (similarly to the own-price elastic demand curve method and based on previous energy balances for Hungary).
My question would be if any of you have met the same challenge and - if you would be kind to share - what were your solutions? Also, do you find this method possible to insert in TIMES?
I have read Antti's paper from 2010 on "Elastic supply cost curves in TIMES" and the related "Appendix B Damage Cost Functions" part from the "Documentation for the TIMES model - Part II", which I found very useful and thank you for those. However, if it is possible, could you please provide an example from TIMES that you have been worked with before, in order to be able to see how it looks in "real life"?
Thank you very much for your answer and help in advance!
Any help is very much appreciated!
01-07-2019, 03:05 PM (This post was last modified: 01-07-2019, 03:06 PM by Antti-L.)
I am not sure what kind of an example you are looking for, but I just tested the example given in the note on Elastic Supply curves, using an exogenously specified Base price (defined by DAM_COST(r,y,c,cur)) and Base quantity (DAM_BQTY(r,c)), and it worked well. So, at least the example given in that note is a working example, which just has to be supplemented with the Base price and Base quantity when these are exogenous. In VEDA the limitation is that VEDA only supports DAM_BQTY for defining the Base quantity and it has no year index.
It is of course possible to model such supply curves manually, by introducing a process (or a process flow) for each step of the curve. I have a vague feeling that Amit Kanudia (the main VEDA designer) may have done some automation for creating such under VEDA.
Thank you very much for your help. Indeed, the note on Elastic Supply curve is very helpful and it seems the we have managed to apply elastic supply curves based on exogenously specified Base Price and Base quantity.
May I have another question that is related to demand functions with constant elasticity of substitution (CES) ?
I have found that in the DemoS examples there are practices about how to define elastic demand curves. Is there maybe an example about how to precisely define elastic demand functions with CES?
The reason why I am asking because after I have read the TIMES Micro note on Elastic Demand Functions I am a bit confused on which parameters should be provided by the user:
1) In the last paragraph of section 2.3 (pp. 5) it is written that the own-price elasticity for the component demand (Ei) /defined by COM_ELAST(r,t,c,s,lim=LO/UP)/ and also for the aggregate demand (Ek) /defined by COM_ELAST(r,t,c,s,lim=FX) for the linear case/ have to be defined along with the substitution elasticities of aggregate demands (sigma k) /defined by COM_ELAST(r,t,c,s,lim=N)/.
2) However, in the paragraph after eq. 22 in section 3.2 (pp.7) it is stated that "As the own price elasticity of the CES component demands are equal with the common ubstitution elasticity (Ei=- sigma k)". Could you please help me how should one understand this? Thank you!
I would also have another question about defining the "substitution elasticity of component demands of the demand aggregation represented by commodity c": COM_ELAST(r,t,c,s,lim=N).
Does it mean that COM_ELAST(r,t,c,s,lim=N) should be defined for each component demand? The reason I am bit confused here is that as far as i understood, a component demand can belong to more aggregate demand: e.g. we are trying to model modal shift in the transport sector, where the component demands are the different modes of transportation (e.g. car, train, bus etc.) and the aggregate demands are represented by a matrix of distance (short-long) and type (person vs. freight), therefore there are 4 different aggregate demands. However a component demand (let's say car) can be allocated to both "long- and short-distance person travelling" aggregate demands. In this case one should define two "car" component demands one for each aggregate demand in order to be able to use two different CES parameter for two the aggregate demands?
I am sorry for the long post and thank you for your help.
I am sorry, I cannot see any reference to COM_ELAST on page 5, and neither should there be any such.
The TIMES user interface is described in Section 4 (pages 9-10), which states that you should use COM_ELAST(r,t,com,ANNUAL,'N'), where com is the aggregate demand, for defining the substitution elasticities for the component demands. It is also said there that the own price elasticities can be defined by COM_ELAST(r,t,com,ANNUAL,bd), where bd=UP/LO/FX. Thus, for a CES demand function you should define:
• COM_VOC(r,t,c,bd) for the component demands c
• COM_STEP(r,c,bd) for the component demands c
• COM_VOC(r,t,com,bd) for the aggregate demand com
• COM_STEP(r,com,bd) for the aggregate demand com
• COM_ELAST(r,t,com,'ANNUAL','N') for the aggregate demand com (substitution among components)
• COM_ELAST(r,t,com,'ANNUAL',bd) for the aggregate demand com (own price elasticity of com)
• COM_AGG(r,t,c,com) for the aggregation of components c into com
Specifying any COM_ELAST for the component demands of a CES function is discouraged.
I don't think you can feed the same component into several aggregate demands, but you should split "car" into short-distance car travel and long-distance car-travel, because using car in both would clearly seem inconsistent to me. I would say that any such "loops" in the CES structure (which should have a tree topology) are unsupported...
Thank you very much for your quick and helpful reply. You made thinks more clear.
May I ask two more questions?
1) In regards to your answer and the example we have mentioned above: does it mean that the component demand c is e.g. short-distance car-travel, while the aggregate demand com is e.g. short-distance travel? And the demand projection /COM_PROJ(r,t,c)/ then should be exogenously provided only for the component demand c (in our example for short-distance car-travel) ?
2) Could you please describe from TIMES Micro note the definition of "dag_k,i (t)" and "alpha_k,i(t)"? Are they related to each other?
Does the aggregation of components c into com /COM_AGG(r,t,c,com)/ describes any of these? Or should one only use /COM_AGG(r,t,c,com)/ to "link" the component demands to the appropriate aggragate demand? If the latter case holds, should we use the parameter "1" (which would indicate in the above example that e.g. 100% of the short-distance car-travel is considered to be allocated to the short-distance travel)?
1) Yes. All component demand should have baseline demand projections. Surely one would usually not let the model optimize between short distance/long distance, but their baseline demands are defined exogenously.
2) In a proper CES function, Com_Agg should be set to zero as mentioned in the doc, and the model then internally derives the aggregation parameters according to the price ratios (in the elastic policy runs).
22-11-2022, 09:34 PM (This post was last modified: 22-11-2022, 10:12 PM by Sandro_Luh.)
(08-08-2019, 10:26 PM)Antti-L Wrote: I am sorry, I cannot see any reference to COM_ELAST on page 5, and neither should there be any such.
The TIMES user interface is described in Section 4 (pages 9-10), which states that you should use COM_ELAST(r,t,com,ANNUAL,'N'), where com is the aggregate demand, for defining the substitution elasticities for the component demands. It is also said there that the own price elasticities can be defined by COM_ELAST(r,t,com,ANNUAL,bd), where bd=UP/LO/FX. Thus, for a CES demand function you should define:
• COM_VOC(r,t,c,bd) for the component demands c
• COM_STEP(r,c,bd) for the component demands c
• COM_VOC(r,t,com,bd) for the aggregate demand com
• COM_STEP(r,com,bd) for the aggregate demand com
• COM_ELAST(r,t,com,'ANNUAL','N') for the aggregate demand com (substitution among components)
• COM_ELAST(r,t,com,'ANNUAL',bd) for the aggregate demand com (own price elasticity of com)
• COM_AGG(r,t,c,com) for the aggregation of components c into com
Specifying any COM_ELAST for the component demands of a CES function is discouraged.
I don't think you can feed the same component into several aggregate demands, but you should split "car" into short-distance car travel and long-distance car-travel, because using car in both would clearly seem inconsistent to me. I would say that any such "loops" in the CES structure (which should have a tree topology) are unsupported...
Dear Antti
You stress that "Specifying any COM_ELAST for the component demands of a CES function is discouraged.".
Still, I found a publication by quite well-known modelers (see here) where own-price elasticities for component demands (Table 1) have been combined with substitution elasticities (Table 2). Perhaps you know this publication. As far as I understand the publication, they apply a combined approach of cross-price (substitution) elasticities and own-price elasticities. Do you also understand it like this?
If yes, do I understand correctly that such an approach is exactly what you referred to with your "[...] is discouraged" statement above?
In any case, I would be very curious to understand why you concretely discourage using COM_ELAST for component demands of a CES function. Could you please elaborate on this?
The paper you referred did not actually use the linearized CES formulation, but the volume preserving variant (negative substitution elasticities). If you define component-specific elasticities, the substitution elasticities will then neither correspond to a standard CES demand function. That was the reason for my discouragement: while it is supported by the model generator, the resulting demand function will not quite work like a CES demand function. So, it was like a word of warning: you can use it "at your own risk".
The documentation indeed mentions that you can define such also for the component demands:
"The substitution elasticities can be defined by specifying COM_ELAST(r,t,com,ANNUAL,'N') for the aggregate demands. However, 'FX' elasticities for the component demands can be optionally specified for defining component-differentiated substitution elasticities. Nonetheless COM_ELAST(r,t,com,ANNUAL,'N') always defines the minimum substitution elasticity among the component demands of com."
Multi-level nested CES demand aggregations are also supported both in the non-linear and in the linearized case, and so you can of course define substitution elesticities for the component demands when they are themselves demand aggregates with lower-level components.
23-11-2022, 03:16 AM (This post was last modified: 23-11-2022, 05:08 AM by Sandro_Luh.)
(22-11-2022, 10:23 PM)Antti-L Wrote: The paper you referred did not actually use the linearized CES formulation, but the volume preserving variant (negative substitution elasticities). If you define component-specific elasticities, the substitution elasticities will then neither correspond to a standard CES demand function. That was the reason for my discouragement: while it is supported by the model generator, the resulting demand function will not quite work like a CES demand function. So, it was like a word of warning: you can use it "at your own risk".
The documentation indeed mentions that you can define such also for the component demands:
"The substitution elasticities can be defined by specifying COM_ELAST(r,t,com,ANNUAL,'N') for the aggregate demands. However, 'FX' elasticities for the component demands can be optionally specified for defining component-differentiated substitution elasticities. Nonetheless COM_ELAST(r,t,com,ANNUAL,'N') always defines the minimum substitution elasticity among the component demands of com."
Multi-level nested CES demand aggregations are also supported both in the non-linear and in the linearized case, and so you can of course define substitution elesticities for the component demands when they are themselves demand aggregates with lower-level components.
Dear Antti
As always, your comments are very insightful. Thank you. I didn't realize that your comment was not valid when using the volume preserving variant.
I was reading the same part of the documentation, and have a question regarding this quote
Quote:"The substitution elasticities can be defined by specifying COM_ELAST(r,t,com,ANNUAL,'N') for the aggregate demands. However, 'FX' elasticities for the component demands can be optionally specified for defining component-differentiated substitution elasticities. Nonetheless COM_ELAST(r,t,com,ANNUAL,'N') always defines the minimum substitution elasticity among the component demands of com."
Let me provide an example: Assume I have the component demands TPCAR (car) and TPRAIL (rail), which are aggregated by the aggregated demand TPPKM (passenger kilometer).
To enable modal shift: COM_ELAST(r,t,TPPKM,ANNUAL,'N') = -2. -->This defines the substitution elasticity between TPCAR and TPRAIL with 2, and activates the volume-preserving variant.
According to the 2nd sentence I can also define: COM_ELAST(r,t,TPCAR,ANNUAL,'FX') = -1 and COM_ELAST(r,t,TPRAIL,ANNUAL,'FX') = -3
--> This defines component-specific substitution elasticities for TPCAR and TPRAIL. However, according to the third sentence, the value for TPCAR (-1) is 'ignored' because the value for TPPKM (-2) is larger and provides the minimum substitution elasticity
Contrary to defining component-specific cross-price elasticity with COM_ELAST(r,t,TPCAR,ANNUAL,'FX'), I understand from the mentioned publication that they defined component-specific own-price elasticities for TPCAR and TPRAIL (terminology of our example).
For such component-specific own-price elasticities, I would assume that this should be defined with COM_ELAST(r,t,TPCAR,ANNUAL,'LO, UP') and COM_ELAST(r,t,TPRAIL,ANNUAL,'LO, UP'),i.e. with LO/UP instead of FX.
--> Is this correct?
--> If yes, I am not sure how to interpret which of both aspects determines the modal shift. Could you please elaborate on how to interpret the interaction between the cross-price elasticity defined for the aggregated demand (TPPKM) and the own-price elasticities for the component-specific demands (TPCAR and TPRAIL)?
To make clear what I mean with an 'interpretation of the interaction of cross-price and own-price elasticities', let me try to give an example (which is probably entirely wrong): The own-price elasticities for TPCAR and TPRAIL lead to demand variation for each mode itself if the costs changed compared to the baseline scenario. Then, only if the own-price elasticity leads to mode-specific demand variations, the substitution elasticity would take effect and allow for the demand shifts between the modes in order to fulfill the volume-preserving condition while maintaining minimum systemic costs.
23-11-2022, 03:19 PM (This post was last modified: 23-11-2022, 05:28 PM by Antti-L.
Edit Reason: cleanup duplicate text
)
>To enable modal shift: COM_ELAST(r,t,TPPKM,ANNUAL,'N') = -2.
-->This defines the substitution elasticity between TPCAR and TPRAIL with 2, and activates the volume-preserving variant.
Yes, correct.
>According to the 2nd sentence I can also define: COM_ELAST(r,t,TPCAR,ANNUAL,'FX') = -1 and COM_ELAST(r,t,TPRAIL,ANNUAL,'FX') = -3
--> This defines component-specific substitution elasticities for TPCAR and TPRAIL.
Yes, correct.
>Contrary to defining component-specific cross-price elasticity with COM_ELAST(r,t,TPCAR,ANNUAL,'FX'), I understand from the mentioned publication that they defined component-specific own-price elasticities for TPCAR and TPRAIL (terminology of our example).
No, the component demands have no direct own-price elasticity, only the aggregate demand has. You can define the own-price elasticity for the aggregate demand by COM_ELAST(r,t,dem,ANNUAL,'FX'), example:
COM_ELAST(r,t,'TLPKM','ANNUAL','FX')=0.35; Own-price elasticity of aggregate demand
COM_ELAST(r,t,'TLPKM','ANNUAL','N')=1.2; Elasticity of substitution between components
>For such component-specific own-price elasticities, I would assume that this should be defined with COM_ELAST(r,t,TPCAR,ANNUAL,'LO, UP') and COM_ELAST(r,t,TPRAIL,ANNUAL,'LO, UP'),i.e. with LO/UP instead of FX .
--> Is this correct?
No. There are no proper component-specific own-price elasticities; only cross elasticities. This should be most obvious for the volume preserving variant, where any price-induced decrease in the volume of one component is reflected as an equal amount of increase in the other components, and so all component elasticities are cross-elasticities by nature. But the aggregate demand has the own-price elasticity, whereby the total demand volume may change, as a function of its price. You would of course have also an implied own-price elasticity for each component, but there is no input parameter for such in this formulation.
23-11-2022, 09:52 PM (This post was last modified: 23-11-2022, 10:29 PM by Sandro_Luh.)
Antti, thank you for sharing your thoughts.
(23-11-2022, 03:19 PM)Antti-L Wrote: >Contrary to defining component-specific cross-price elasticity with COM_ELAST(r,t,TPCAR,ANNUAL,'FX'), I understand from the mentioned publication that they defined component-specific own-price elasticities for TPCAR and TPRAIL (terminology of our example).
No, the component demands have no direct own-price elasticity, only the aggregate demand has. You can define the own-price elasticity for the aggregate demand by COM_ELAST(r,t,dem,ANNUAL,'FX'), example:
COM_ELAST(r,t,'TLPKM','ANNUAL','FX')=0.35; Own-price elasticity of aggregate demand
COM_ELAST(r,t,'TLPKM','ANNUAL','N')=1.2; Elasticity of substitution between components
>For such component-specific own-price elasticities, I would assume that this should be defined with COM_ELAST(r,t,TPCAR,ANNUAL,'LO, UP') and COM_ELAST(r,t,TPRAIL,ANNUAL,'LO, UP'),i.e. with LO/UP instead of FX .
--> Is this correct?
No. There are no proper component-specific own-price elasticities; only cross elasticities. This should be most obvious for the volume preserving variant, where any price-induced decrease in the volume of one component is reflected as an equal amount of increase in the other components, and so all component elasticities are cross-elasticities by nature. But the aggregate demand has the own-price elasticity, whereby the total demand volume may change, as a function of its price. You would of course have also an implied own-price elasticity for each component, but there is no input parameter for such in this formulation.
Based on the TIMES Micro documentation (page 9, chapter 4.1, see attached screenshot), I understood that the component-demands (c, while the aggregated demands are com) with the bound specified as LO/UP. However, is it then always the case that component demands have no direct own-price elasticity or are there exceptions?
So, you said that the component demands have no own-price elasticity, but the aggregated demand can have an own-price elasticity. Let's say I want to apply the volume-preserving variant for the aggregated demand (TPPKM). Then the aggregated demand needs to remain constant and, therefore, not be subject to any own-price elasticity. What's the best practice for implementing this in the model? Would I define the own-price elasticity of TPPKM as 0 (COM_ELAST(r,t,'TPPKM','ANNUAL','FX')=0) or not define the own-price elasticity for TPPKM at all?
EDIT: Just to be certain, I would like to re-clarify if I understand the implications of your explanations correctly when modeling modal shift in the transport sector:
In the transport sector, consumers are much more price-sensitive for public transport modes compared to cars. Therefore, reflecting mode-specific elasticities is an important aspect. In TIMES, mode-specific elasticities (e.g., for car demands) are only possible by defining component-specific cross-price elasticities (e.g., [i]COM_ELAST(r,t,[/i][i]TPCAR[/i][i],ANNUAL,'FX'))[/i]. However, those component-specific cross-price elasticities take only effect, if they are stronger than the defined cross-price elasticity of the aggregated demand. Can you confirm this until here?
Do you think the following workaround might be feasible to reflect individual elasticities for each transport mode demand? Define a cross-price elasticity for the aggregated demand as almost 0, and define in addition component-specific cross-price elasticities for each mode, which are larger than 0:
COM_ELAST(r,t,'TPPKM','ANNUAL','N')= -0.0001; Cross-price elasticity for the aggregated demand very small. However, not zero, because negative value is needed to activate volume preserving variant.
COM_ELAST(r,t,TPCAR,ANNUAL,'FX') = -1; Component-specific cross-price elasticity, which overrules the 0 for car demand.
COM_ELAST(r,t,TPRAIL,ANNUAL,'FX') = -3; Component-specific cross-price elasticity, which overrules the 0 for train demand.
That TIMES Micro document describes all the variants for TIMES demand functions. And Section 4.1. describes the input parameters available for using all of them.
The basic alternative (and the only formulation originally implemented) is the one with own-price elasticities only. For them, you should use COM_ELAST(r,y,c,ts,UP/LO).
The more complex demand functions, with cross-price elasticities have both: own-price elasticities for the aggregates and substitution elasticities for the components.
Ok, let's say one wants to apply the volume-preserving variant for the aggregated demand (TPPKM). Volume preserving refers the important property that substitution by itself does not affect the aggregate demand volume, like it would when using a standard CES demand function. This property may be important for many demands in energy system models, such as transport demands. However, one can well define an own-price elasticity for the aggregate demand in any of the variants. That would correspond to an income-expenditure elasticity of the aggregate demand. But of course, if you think that the income-expenditure elasticity is actually zero (such that the demand would stay unchanged no matter how much the price would increase), then you can just leave it unspecified. Using explicit zero values for the elasticities might, in fact, be problematic (it may be gracefully handled by the code, but I am not sure), and so it is better to just leave it unspecified in that case.
23-11-2022, 10:33 PM (This post was last modified: 23-11-2022, 10:53 PM by Sandro_Luh.)
Thank you for clarifying such aspects.
While you posted your answer, I was in parallel still adding a point to my previous post. Let me post it here again:
Just to be certain, I would like to re-clarify if I understand the implications of your explanations correctly when modeling modal shift in the transport sector:
In the transport sector, consumers are much more price-sensitive for public transport modes compared to cars. Therefore, reflecting mode-specific elasticities is an important aspect. In TIMES, mode-specific elasticities (e.g., for car demands) are only possible by defining component-specific cross-price elasticities (e.g., [i]COM_ELAST(r,t,[/i][i]TPCAR[/i][i],ANNUAL,'FX'))[/i]. However, those component-specific cross-price elasticities take only effect, if they are stronger than the defined cross-price elasticity of the aggregated demand. Can you confirm this until here?
Do you think the following workaround might be feasible to reflect individual elasticities for each transport mode demand? Define a cross-price elasticity for the aggregated demand as almost 0, and define in addition component-specific cross-price elasticities for each mode (more than only TPCAR and TPRAIL), which are larger than 0:
COM_ELAST(r,t,'TPPKM','ANNUAL','N')= -0.0001; Cross-price elasticity for the aggregated demand very small. However, not zero, because negative value is needed to activate volume preserving variant.
COM_ELAST(r,t,TPCAR,ANNUAL,'FX') = -1; Component-specific cross-price elasticity, which overrules the 0 for car demand.
COM_ELAST(r,t,TPRAIL,ANNUAL,'FX') = -3; Component-specific cross-price elasticity, which overrules the 0 for train demand.
COM_ELAST(r,t,TPBUS,ANNUAL,'FX') = -2; Component-specific cross-price elasticity, which overrules the 0 for bus demand.
COM_ELAST(r,t,TPTRAM,ANNUAL,'FX') = -2.5; Component-specific cross-price elasticity, which overrules the 0 for tram demand.
23-11-2022, 11:00 PM (This post was last modified: 23-11-2022, 11:32 PM by Antti-L.)
>Do you think the following workaround might be feasible to reflect individual elasticities for each transport mode demand?
Sure, but if you have only two components, I think the combined effect would be equivalent to using a single value for the cross-price elasticity. So, as far as I can see, such component-specific differentiated elasticities would actually be useful only if you have more than two components. With just two components, I cannot see how one component could be more price-elastic than the other, can you? Wouldn't the changes in volume be equal but opposite (assuming unchanged aggregate demand)? I admit I have not much thought about using such differentiation...
Moreover, using very small values for elasticities would tend to cause numerical problems, and so better to take the smaller in abs. value of {−1, −3}, which is −1, and use that as the default, instead of −0.0001.
[Edit:] Ok, I see you have now added two more components in your post above. So, suggest take the minimum in abs. value of {−1, −2, −2.5, −3 } = −1.
24-11-2022, 12:20 AM (This post was last modified: 24-11-2022, 12:22 AM by Antti-L.)
>In TIMES, mode-specific elasticities (e.g., for car demands) are only possible by defining component-specific cross-price elasticities (e.g., COM_ELAST(r,t,TPCAR,ANNUAL,'FX')). However, those component-specific cross-price elasticities take only effect, if they are stronger than the defined cross-price elasticity of the aggregated demand. Can you confirm this until here?
Yes, confirmed, but can you still explain why you say "only possible"? Nested CES structures, which are often employed for mode-specific elasticities, are also possible. What all is missing?