I read the post with the title "TSLV" but still have doubts.
For me, I would like to model the demand at DAYNITE level for agriculture, industry and building sector (like Starter DEMO), and for the transportation sector, I would like to model the fixed charging profile just as that in AdvDEMO. What's different is that there are multiple processes in my industrial sector that contain material flows. The energy services demand in the building sector is not the final demand commodity, but rather the elements that make up the demand commodity (the area of a particular type of building).
A schematic of the reduced RES is attached, where the orange and green parts are commodities for which I have constructed load curves and I would like to add the COM_FR parameter. For all electricity processes, I have AF constraints at DAYNITE level. Now, I am not sure which processes and commodities should define TSLV as DAYNITE in my model.
Currently, I define all electricity commodities (such as ELC, ELCC, ELCD, AGRELC, INDELC, BLDELC, TRAELC, INDIBUELC, INDIOIELC, BLDURBELC, BLDRULELC, BLDCOMELC, TRAFELC, TRAPELC), generation processes (EPLTCOA00, EPLTSOL00, etc.), distribution processes (DISELC, DISINDELC, DISBLDELC, DISTRAELC), storage processes (Not included in this figure) and transmission processes (ELCTOT00) are defined as DAYNITE level. All others are ANNUAL level.
However, the model is DUMMY with a large amount of electricity, even when the model already has a large amount of energy storage installed. I checked the GDX file and found that for all power commodities (as described above), their COM_FR is automatically generated to the same value as YRFR, is this normal?
Thank you for your help in checking and providing suggestions for my modeling.
I can quickly comment on the question related to the model generator:
>I checked the GDX file and found that for all power commodities (as described above), their COM_FR is automatically generated to the same value as YRFR, is this normal?
Yes, it is normal, if you have not defined COM_FR for these commodities. In that case the default COM_FR profile is equal to a flat load profile. But note that the COM_FR profiles of DAYNITE level intermediate commodities usually have hardly any impact on the model results. They are generated for reasons of completeness. The load profiles are primarily effective when defined for the demands or for commodities defined on the ANNUAL (or SEASON) level. That's why COM_FR is in fact usually defined only for such commodities. So, I would say you should not worry about the DAYNITE power commodities having COM_FR defaulting to G_YRFR.
07-09-2022, 09:52 PM (This post was last modified: 07-09-2022, 10:03 PM by Antti-L.)
Just another small comment:
It should be obvious that all electricity commodities, or commodities that are produced from electricity commodities, which are upstream of the "load profile" commodities, should be defined on the DAYNITE level, because otherwise the impact of the load profile cannot propagate from the demand to the supply side. So, looking at your RES, if you would like to define load curves by adding COM_FR parameters for the orange commodities, then basically all the commodities upstream of those orange commodities should be on the DAYNITE level, up to the electricity generation processes. And the same of course applies to most of the processes along those energy chains (unless some of them are "base load" processes), except for the processes producing the load profile commodities, which should be ANNUAL if the load profile should be directly reflected in their inputs.
(07-09-2022, 09:52 PM)Antti-L Wrote: Just another small comment:
It should be obvious that all electricity commodities, or commodities that are produced from electricity commodities, which are upstream of the "load profile" commodities, should be defined on the DAYNITE level, because otherwise the impact of the load profile cannot propagate from the demand to the supply side. So, looking at your RES, if you would like to define load curves by adding COM_FR parameters for the orange commodities, then basically all the commodities upstream of those orange commodities should be on the DAYNITE level, up to the electricity generation processes. And the same of course applies to most of the processes along those energy chains (unless some of them are "base load" processes), except for the processes producing the load profile commodities, which should be ANNUAL if the load profile should be directly reflected in their inputs.
Thank you very much for your reply. As you said, if the DAYNITE level is chosen for all the processes of energy chains, a huge amount of DAYNITE tracking technology will be added to the model, which may make the model more difficult to solve.
I was wondering if I apply COM_FR to both the same type of energy demand and its intermediate products (For example, for the cement process, the same COM_FR is applied to Clinker and Cement), and start using DAYNITE tracking at the subsector electricity commodity (INDIBUELC), is this similar to the modeling approach you provide?
12-09-2022, 06:38 PM (This post was last modified: 12-09-2022, 06:40 PM by zhangshu.)
(08-09-2022, 05:51 PM)Antti-L Wrote: Yes, that would be a consistent approach.
Sorry to bother you, but after I put in COM_FR according to this rule and set up DAYNITE tracking for the relevant processes and commodities, I still found that the value of VAR_FIn for ELC is not as expected, and its ratio is still the same as Timeslice's time ratio. It seems that the load curve of demand is not passed on to the power sector.
ELCTOT represents a power transmission technology with some efficiency losses. The ELCD (Distributed Generation) generation is correct, while the ELCC (Centralized Generation) appears to be generating less than expected in order to achieve a flat load curve.
Sorry, but I find it hard to comment on this, as I am not able to see what's in your model. In my models any COM_FR defined on the demand side are correctly propagating to the upstream supply side.
Therefore, for now, I don't have sufficient understanding of your modeling issue, and I don't fully understand why your ELCC generation should have a flat load curve, and if so, why the generation capacity in your model appears insufficient even for a flat curve.
However, if you could provide a small test model reproducing the issue (e.g. "load curve of demand is not passed on to the power sector."), it would be easy to explain it and suggest what should be done differently.
(12-09-2022, 07:35 PM)Antti-L Wrote: Sorry, but I find it hard to comment on this, as I am not able to see what's in your model. In my models any COM_FR defined on the demand side are correctly propagating to the upstream supply side.
Therefore, for now, I don't have sufficient understanding of your modeling issue, and I don't fully understand why your ELCC generation should have a flat load curve, and if so, why the generation capacity in your model appears insufficient even for a flat curve.
However, if you could provide a small test model reproducing the issue (e.g. "load curve of demand is not passed on to the power sector."), it would be easy to explain it and suggest what should be done differently.
ELCC should not be a flat curve. However, the result shown is that the sum of ELCC and ELCD ends up in a straight line.
I also feel strange. I further checked the building sector electricity consumption. For example, I found BLD_URB_ELC, BLD_RUL_ELC and BLD_COM_ELC all had load characters (as they connect to the processes whose output commodities have COM_FR attribute). However, the aggregate commodity BLDELC was a flat curve. I confirmed BLDELC, BLD_URB_ELC, BLD_RUL_ELC and BLD_COM_ELC and DISBLDELC are DAYNITE tracking. The same thing happens in the industry sector. All sebsector ELC commodities (such as IND_IBU_ELC) had load curve attributes but the INDELC didn't.
12-09-2022, 08:43 PM (This post was last modified: 12-09-2022, 08:47 PM by Antti-L.)
>All subsector ELC commodities (such as IND_IBU_ELC) had load curve attributes but the INDELC didn't.
Hmm... you said earlier that you would define COM_FR for Clinker and Cement. Are you now saying that you define it for the sebsector ELC commodities (such as IND_IBU_ELC)? That would of course make things somewhat different. Recall also, as I said earlier, that COM_FR defined on a DAYNITE level power commodity will usually have no effect, because the flows of such a commodity are usually already tracked on the DAYNITE level.
COM_FR tells the model generator how to split an aggregate flow (e.g. an ANNUAL flow) into flows in individual DAYNITE timeslices, and for that to work, there must be some aggregate flow(s) to be split into those DAYNITE level flows, according to the defined load curve. That's the basic rule to bear in mind. And that's also the reason why one should usually not define COM_FR for a DAYNITE level commodity, because then any "base-load" output (i.e. SEASON or ANNUAL level output) of that commodity would be automatically split according to the load curve, even though a base-load output should remain flat.
(12-09-2022, 08:43 PM)Antti-L Wrote: >All subsector ELC commodities (such as IND_IBU_ELC) had load curve attributes but the INDELC didn't.
Hmm... you said earlier that you would define COM_FR for Clinker and Cement. Are you now saying that you define it for the sebsector ELC commodities (such as IND_IBU_ELC)? That would of course make things somewhat different. Recall also, as I said earlier, that COM_FR defined on a DAYNITE level power commodity will usually have no effect, because the flows of such a commodity are usually already tracked on the DAYNITE level.
COM_FR tells the model generator how to split an aggregate flow (e.g. an ANNUAL flow) into flows in individual DAYNITE timeslices, and for that to work, there must be some aggregate flow(s) to be split into those DAYNITE level flows, according to the defined load curve. That's the basic rule to bear in mind. And that's also the reason why one should usually not define COM_FR for a DAYNITE level commodity, because then any "base-load" output of that commodity would be automatically split according to the load curve, even though a base-load output should remain flat.
Sorry, my expression is not very clear. I didn't define COM_FR for IND_IBU_ELC.
"Sebsector ELC commodities (such as IND_IBU_ELC) had load curve attributes" means in the results report, IND_IBU_ELC shows the characteristics of the load curve (The ratio of different Timeslice is not the same as their own time share, and can be matched with the data in the calibration table).
Ok, I see now, sorry for my misunderstanding. But then, if your DISINDELC process is a DAYNITE process as it should, you should of course see the combined load curve in INDELC. If you don't, I am equally confused as you.
(12-09-2022, 09:08 PM)Antti-L Wrote: Ok, I see now, sorry for my misunderstanding. But then, if your DISINDELC process is a DAYNITE process as it should, you should of course see the combined load curve in INDELC. If you don't, I am equally confused as you.
The result is still a straight line for INDELC, but the subsector ELC are able to reflect the fluctuations of the load. Quite strange.
(12-09-2022, 09:08 PM)Antti-L Wrote: Ok, I see now, sorry for my misunderstanding. But then, if your DISINDELC process is a DAYNITE process as it should, you should of course see the combined load curve in INDELC. If you don't, I am equally confused as you.
Finally, I found the reason. Electricity distribution processes need to apply AFA=1 attribute rather than CF=1. Now the model works well! Many thanks to you, Antti!