Posts: 2,175
Threads: 26
Likes Received: 113 in 99 posts
Likes Given: 37
Joined: Jun 2010
30-01-2026, 02:54 PM
(This post was last modified: 30-01-2026, 03:02 PM by Antti-L.)
Sorry, but both INDELC and INDELD were ANNUAL in the model. And therefore no way to preserve the impact of load profiles. I double and triple-checked it, and so I am confused why you say it was DAYNITE.
> it was indeed the fact that i had put DAYNITE for the demands AND for the processes (electric boilers) AND the INDELD commodity. For some reason this makes G_YRFR to overwrite the COM_FR, because when I, as You suggest, put ANNUAL at the processes (electric boilers) and the demands everything works as intended.
The fact that you have DAYNITE for the demands AND for the processes does NOT cause any overwriting of COM_FR with G_YRFR. But yes, it does only preserve the aggregate demand profile, and not for each demand technology, because technology-wise it is only possible to preserve it for ANNUAL technologies.
Posts: 22
Threads: 1
Likes Received: 1 in 1 posts
Likes Given: 4
Joined: Dec 2017
Sorry - that was wrongly overwritten by a script. Now the correct file is there. That is the only difference, though.
Posts: 22
Threads: 1
Likes Received: 1 in 1 posts
Likes Given: 4
Joined: Dec 2017
31-01-2026, 02:59 AM
(This post was last modified: 31-01-2026, 03:16 AM by SDockweiler.)
Okay, I spoke too soon. I still haven't figured out what is causing the model to not use the defined COM_FR.
I have tried a wide variety of TSLVLs definitions (ANNUAL vs DAYNITE) for both processes and commodities. From the import process to the final demand there are six processes/commodities that can either be ANNUAL or DAYNITE. And the only one combination allowing the electric boiler to operate on a time slice level is to make them all DAYNITE, except for the demand. This maybe obvious for some, but I am new to time slices and may have misunderstood your earlier suggestions regarding COM_FR being sent to the ANNUAL defined processes with a DAYNITE input. The problem is, that when the boiler is DAYNITE they do not operate according to the COM_FR, but the G_YRFR. This I have tested using multiple COM_FR developments all yielding the same results.
So, were do I go wrong in these DAYNITE vs ANNUAL definitions and COM_FR vs G_YRFR? I have updated the earlier shared link (pm to you, Antti), with a much simpler model, showcasing the issue.
Best,
Steffen
Posts: 2,175
Threads: 26
Likes Received: 113 in 99 posts
Likes Given: 37
Joined: Jun 2010
31-01-2026, 03:55 AM
(This post was last modified: 31-01-2026, 04:04 AM by Antti-L.)
Ok, I will take a look, but can you point me to which process(es) / demand(s) I should look at, and what to explain? (Sorry if that should be obvious; I did not yet download and see what's in the new simpler model.)
Ah, I just downloaded both folders, but neither contained the TIMES input files, only VEDA files. To be sure I can reproduce, I would need the TIMES input files (*.DD, *.RUN) and preferably the listing file as well (*.LST), like you did provide earlier.
Posts: 2,175
Threads: 26
Likes Received: 113 in 99 posts
Likes Given: 37
Joined: Jun 2010
31-01-2026, 04:29 AM
(This post was last modified: 31-01-2026, 05:10 AM by Antti-L.)
And, because your issues are not at all clear to me, please, could you also clarify the following:
> "the only one combination allowing the electric boiler to operate on a time slice level is to make them all DAYNITE, except for the demand. "
> "The problem is, that when the boiler is DAYNITE they do not operate according to the COM_FR, but the G_YRFR."
Please explain what you mean by "allowing the electric boiler to operate on a time slice level"? Of course the electric boiler activity is only ANNUAL if it is defined ANNUAL, that is the whole point of the PRC_TSL definition. If you want it to be on the DAYNITE level, it must be defined so. So, please explain what is the confusion there?
And secondly, please explain what you mean by "operate [...] according to the G_YRFR". If the process is defined DAYNITE, it can, by default, optimize the operation freely, just like power plants can optimize their operation according to the (implicit) "merit order" implied by the load profile and equlibrium prices by timeslice. I don't think an optimized operation should be referred to as operation "according to the G_YRFR", but of course such (i.e. a flat profile) can indeed be the optimal operating schedule. Do you mean that the model should not be allowed to optimize the operation load profile?
So, the bottom line is that I don't know what your issues are in the first place. What do you expect to see in the results? For example, for electric boilers: Do you expect them all to be operating according to the fixed COM_FR profile you have defined for the corresponding demand(s)? Or, would you expect that all electric boilers can optimize their operation profile, such that only the aggregate demand of the heat they produce will follow the demand profile?
Posts: 2,175
Threads: 26
Likes Received: 113 in 99 posts
Likes Given: 37
Joined: Jun 2010
31-01-2026, 06:13 AM
(This post was last modified: 31-01-2026, 06:30 AM by Antti-L.)
Ok, I had a quick look at the files anyway.
I see there is now only a single demand: INDFODLIE_DMD, which is tracked on the ANNUAL level. This means, as I indicated earlier, that your demand processes should also be at the ANNUAL level, so that the demand profile can propagate through them to the input flows (if the processes would be DAYNITE, any operation profile would satisfy the demand, with the profile shifted to match the demand profile, because the demand is tracked only on the ANNUAL level).
However, I see you are mixing DAYNITE and ANNUAL level demand processes, which means that only the ANNUAL level processes are guaranteed to operate according to the demand profile, while the DAYNITE processes can take any profile, as their profile is always automatically shifted to match the demand profile (because of the ANNUAL level demand). So, you are losing the demand profile completely for the DAYNITE processes because of the ANNUAL level demand.
Hence, I am not able to make much sense out of this simple model. What is the idea behind using an ANNUAL level demand and then DAYNITE processes satisfying that demand with an arbitrary operation profile?
Posts: 22
Threads: 1
Likes Received: 1 in 1 posts
Likes Given: 4
Joined: Dec 2017
Thanks for taking a look!
Of course, I think I have not explained very well yet: What I would like to model, is flexible operations of industrial electric boilers. Thus they can provide the energy service demand at times with low electricity prices and other technologies can provide the demands when the electricity price is high (Electric boilers at DAYNITE so they can operate when the costs are low and not when the costs are high). But at the same time I assume that not all industries act fully flexible and can switch between technologies, and I want to mimic this by only putting part of the energy service demand in the "flexible" time slices and the rest in a "non-flexible" time slice with just an yearly consumption weighted average electricity price. Furthermore, I assume that more and more industries become "flexible" over time, so I want to increase the share of energy service demands that can be in the "flexible" time slices (by increasing the COM_FR over time for these TS and decreasing for the "non-flexible" one accordingly (total share = 1).
Tracking the specific electric boiler techs DAYNITE and the demand INDFODLIE_DMD DAYNITE forced the boilers to not operate flexible, and then they do not come in the technology mix.
Tracking the specific electric boiler techs ANNUAL and the demand INDFODLIE_DMD ANNUAL forced the boilers to not operate flexible, and then they do not come in the technology mix.
Tracking the specific electric boiler techs DAYNITE and the demand INDFODLIE_DMD ANNUAL yielded my wanted results, that electric boilers run when electricity is cheap. But changing the COM_FR to a different value didn't change the results as expected (higher share of COM_FR in the "flexible" TS should yield higher electricity use and demand production from electric boilers). I have included three scenarios in the simple model which run three different COM_FR to test this.
Is it a problem that some demand techs are ANNUAL and some are DAYNITE when they compete? Is it a problem that COM_FR change over time and is different than G_YRFR?
I will add the DD, RUN and .lst files for the three runs.
Thanks again, Antti!
Posts: 2,175
Threads: 26
Likes Received: 113 in 99 posts
Likes Given: 37
Joined: Jun 2010
01-02-2026, 12:32 AM
(This post was last modified: 01-02-2026, 01:05 AM by Antti-L.)
You wrote earlier:
> INDELC being strictly ANNUAL and INDELD being DAYNITE. The SubAnnual scenario file activates the share of INDELD being zero in the VT-base case to be 1 and INDELC to be zero.
Yes I see that, in the sys_timeslice_10split_* scenario file, but I note that there is still also INDELC demand remaining for many processes. There seems to be in total 42 processes consuming INDELC (in both regions) while only 10 processes have an INDELD input.
Anyway, your explanation about “ What I would like to model, is flexible operations of industrial electric boilers” indicates that in essence, you are basically assuming that each industrial consumer has access to any of the technologies, simulating perhaps large industrial sites where all technologies can be serving all the consumers on that site. And because of that, you would have flexibility of operation across the technologies such that the load profile of each technology can be optimized, while only the aggregate demand follows the demand profile. Consequently, the ANNUAL demand approach is not suitable in your case, while that approach can be quite suitable for e.g. in-house heating systems, which should typically all see the same demand profile, because due to space requirements and costs, each house typically has only a single heating system installed (which may however be of hybrid type and thus can also have operational flexibility), instead of a whole portfolio of technologies. Therefore, in such a case one should not allow for example “base-load” operation for some heating systems and “peak-load” operation for others, because each technology essentially represents a heating system option for a single house and should therefore satisfy the demand profile.
Hence, the approach suitable for you case is DAYNITE level demand served by DAYNITE level processes. It looks like you did not consider that option in your tests? Instead, I see that in the Excel files you have defined the demand on the ANNUAL level and the 10 technologies with INDELD inputs on the DAYNITE level, while the remaining technologies on the ANNUAL level. As I already tried to explain, this mixed approach cannot work as such, and as I explained above, the ANNUAL demand approach in general does not suit your purposes. Moreover, in the Work folder files you have now provided, I see the demand being defined on the DAYNITE level while all the demand technologies are now on the ANNUAL level. That would indeed work for the case where each technology should see the same demand profile (like it would work if also the demand were ANNUAL), but not for your case.
Recall also that there are also the options of defining load profiles for individual process flows (using FLO_FR), and timeslice-specific operational constraints (NCAP_AF/AFS/AFC, and dispatching parameters) whenever such are desired.
Please see below a picture showing the INDELC and INDELD consumption when using the DAYNITE–DAYNITE approach suitable for your model, in the 05_50 case. As you can see, the INDELD consumption is substantially expanding over time with increasing number of operational timeslices.
I hope that could be of some help?
Posts: 2,175
Threads: 26
Likes Received: 113 in 99 posts
Likes Given: 37
Joined: Jun 2010
01-02-2026, 12:51 AM
(This post was last modified: 01-02-2026, 12:57 AM by Antti-L.)
> Is it a problem that some demand techs are ANNUAL and some are DAYNITE when they compete?
No, it is not any notable problem in the power and heat system, where you don't have a demand profile defined with COM_FR. An ANNUAL level technology will in that case simple be a "base-load" technology (with a flat output profile). But when you have a COM_FR defined, an ANNUAL level technology follows that profile instead of G_YRFR (which is the flat profile). Therefore, if you would have ANNUAL and DAYNITE demand technologies competing, the ANNUAL technologies would follow the demand profile, but if the demand would also be ANNUAL, the DAYNITE technologies could have an arbitrary operational profile, such that would not even result in a consistent aggregate profile. If the demand would be on the DAYNITE level, then the aggregate profile would still be consistent, but the operational flexibility would remain limited, due to the ANNUAL processes following the pre-defined demand profile.
> Is it a problem that COM_FR change over time and is different than G_YRFR?
No, can you explain why you think that could be a problem? If COM_FR would always be equal to G_YRFR, one would only be able to define flat demands!
Posts: 2,175
Threads: 26
Likes Received: 113 in 99 posts
Likes Given: 37
Joined: Jun 2010
01-02-2026, 08:18 PM
(This post was last modified: 01-02-2026, 08:55 PM by Antti-L.)
Ahh... I forgot that you also gave these statements:
> And the only one combination allowing the electric boiler to operate on a time slice level is to make them all DAYNITE, except for the demand. [...] The problem is, that when the boiler is DAYNITE they do not operate according to the COM_FR, but the G_YRFR.
Ok, so here you say that the boilers should operate according to the COM_FR after all. That makes me very much confused, because elsewhere you said that you would like to model " flexible operations of industrial electric boilers". So, what I showed as the results (see the table below again) was based on thinking that you would indeed wish flexible operation across the technologies serving the demand, and not each according to COM_FR:
I can definitely see the boilers operating on the DAYNITE timeslice level here, with their operation being flexible (and not according to COM_FR). But apparently I may have again misunderstood what you are expecting to see.
Posts: 22
Threads: 1
Likes Received: 1 in 1 posts
Likes Given: 4
Joined: Dec 2017
Okay, so when I try the DAYNITE-DAYNITE for ALL processes it seems to work like expected. Before I tried the DAYNITE-DAYNITE approach with just the electric boilers being DAYNITE and rest of techs being ANNUAL. Before there were no changes in flexible operations when changing COM_FR. Now when changing COM_FR there is a change in operations exactly as I was expecting: More COM_FR being allocated to the flexible times slices yields more electricity use (INDELD).
Thank you very much for clearing this issue for me. I am not sure i completely understand why it didn't work with the mixed approach, but I get that "the DAYNITE technologies could have an arbitrary operational profile, such that would not even result in a consistent aggregate profile", as you stated earlier. I will play around with the simple model to get a better understanding of times slices, COM_FR and G_YRFR.
Cheers,
Steffen
Posts: 2,175
Threads: 26
Likes Received: 113 in 99 posts
Likes Given: 37
Joined: Jun 2010
Thanks for making it clearer what you were after.
> I am not sure i completely understand why it didn't work with the mixed approach
I assume you refer to the mixed approach with the DAYNITE level demand? It is basically very straightforward: The ANNUAL processes follow the demand profile, just like the total demand does. And therefore, also the remaining demand (to be satisfied with the DAYNITE processes) will inevitably have that same profile, and as a result, the electric boilers (when just them are modeled on the DAYNITE level) will of course also follow the same demand profile (on aggregate terms), and so you won't have any flexibility in their aggregate operation. But otherwise, this mixed approach does results in a consistent aggregate profile, and could thus be well used in cases where one would have a subset of technologies to be modelled with flexible operation within that subset.
The second mixed approach case, with the ANNUAL level demand, is the one where one would have arbitrary operation profiles without any guarantee of consistency in the aggregate profile over the technologies. The source of the problem with it is likewise simple to see, and I would not recommend this approach, unless the modeler knows what she is doing and deals with the inconsistency in some other ways.
|