Posts: 1,972
Threads: 26
Likes Received: 61 in 52 posts
Likes Given: 18
Joined: Jun 2010
17-06-2010, 03:17 AM
(This post was last modified: 17-06-2010, 05:37 PM by Antti-L.)
In models that have a very large number of timeslices, it might be cumbersome to define a realistic load curve for solar power technologies, possibly also for wind power. A flat maximum availability factor can be easily defined by using NCAP_AF(ANNUAL), or similarly for each season, but it might be desirable to have the solar power production follow the hourly solar radiation in each season.
In such cases it can be useful to define the technology at the ANNUAL level, producing a DAYNITE level solar electricity commodity, e.g. SOLELC. You can then define a load curve for the SOLELC commodity in the usual way, using COM_FR. Even if you would have hundreds of timeslices, the load curve needs to be defined only once in a scenario file, and then you can easily model the output of any solar power technology to follow the load curve specified. And you only need to specify the average ANNUAL availability factor NCAP_AF(r,y,p,ANNUAL) for these technologies; just a single value would be sufficient per technology.
Apart from being rather convenient by reducing the amount of NCAP_AF parameters, this solution can also reduce the model size considerably, if you have numerous solar power technologies. If necessary, you could also use several different solar power commodities with different load curves.
Posts: 28
Threads: 9
Likes Received: 0 in 0 posts
Likes Given: 0
Joined: Oct 2010
While defining my load curves, I have some problems.
I can define different load curves for each technology, by once I have them ready it's not possible to run the model. It saidme: Unexpected Termiation of Run.
Do you know what can be the cause??
Thanks
Posts: 72
Threads: 19
Likes Received: 0 in 0 posts
Likes Given: 2
Joined: Dec 2010
Dear
Antti,
We have tried to implement this to our
TIMES model with no luck. We have defined the COM_FR for the 260 time slices in
the Wind Commodity and then defined the NCAP_AF_ANNUAL in each technology (
NCAP_AF_ANNUAL is higher for wind turbines located in areas with higher wind
speeds compared to wind turbines located in areas with lower wind speed
conditions). Currently the Wind commodity and the wind turbine technologies are
defined with a Day-Night Time Slice level characteristics.
When we look at the models run we see that
the COM_FR in the commodity is completely ignored! The electricity production
from the wind turbines are evenly distributed for the whole year even if we set
the COM_FR equal to zero in some periods.
Do you have any tips on how to solve this?
How can we make the COM_FR applicable?
Is this related to the question addressed
by Kannan 16th of June 2010 on modelling issues with solar PV?
Since we have many time slice levels and
many regions we think it would be very convenient to use this method for wind
power and run off river hydro.
All comments and suggestions are highly
appreciated.
Thanks!
Pernille
Posts: 1,972
Threads: 26
Likes Received: 61 in 52 posts
Likes Given: 18
Joined: Jun 2010
19-07-2011, 10:57 AM
(This post was last modified: 19-07-2011, 11:14 AM by Antti-L.)
Pernille:
I am not sure what you mean by "The electricity production from the wind turbines are evenly distributed for the whole year". Of course, if you look just at the outputs of these processes (and if you are not using the run setting RPT_FLOTS=COM), they are certainly evenly distributed, because the processes are defined at the ANNUAL level.
However, the COM_FR parameter is taken into account in the commodity balance of the output commodity. Because the commodity produced by the wind power technologies is defined at the DAYNITE level, the production will be distributed according to the COM_FR load curve. I just tested the approach again, and I can see the correct distribution enforced at the balance equations.
So, I am not sure what the problem is that you are seeing...
And by using the $SET RPT_FLOTS COM switch you can even see the process outputs distributed according to the curve when looking at the Var_Fout reporting attriute.
Posts: 14
Threads: 2
Likes Received: 0 in 0 posts
Likes Given: 0
Joined: Jul 2011
Dear Antti.
We have tried to do exactly as you describe above, but whatever we put into the COM_FR load curve, the wind power technology totally ignores it. We get exactly the same result if we use e.g. 0 or 1 in the COM_FR load curve.
The only way I have been able to get the results that I want is to use weekly NCAP_AF factors directly in the technology (process).
Are there any other settings beside $SET RPT_FLOTS that can affect our results?
Posts: 1,972
Threads: 26
Likes Received: 61 in 52 posts
Likes Given: 18
Joined: Jun 2010
20-07-2011, 07:40 AM
(This post was last modified: 20-07-2011, 08:03 AM by Antti-L.)
Hmm... very strange if it does not work for you, while I see it working very well.
No, there are no other settings that should matter, and note that the RPT_FLOTS setting does not affect the model solution at all, it is only a reporting setting, which only enables you to see the distribution according to the load curve already at the process level in the flow results.
Are you sure that you have defined your wind power technologies to operate at the ANNUAL level, and you are specifying the COM_FR for the output commodity (e.g. WINELC), which is defined to be at the DAYNITE level? (Note that to define a process at the ANNUAL level you should put "ANNUAL" into the Tslvl column of the process definition table (~FI_Process).)
Posts: 14
Threads: 2
Likes Received: 0 in 0 posts
Likes Given: 0
Joined: Jul 2011
Ok. Thanks for your input. We will try some more to see if we can make it work.
Posts: 1,972
Threads: 26
Likes Received: 61 in 52 posts
Likes Given: 18
Joined: Jun 2010
Very well, but it would be interesting to know what your problem is.
If you cannot make it working by yourself, I could of course post a simple demo model here, demonstrating how it works. Let me know if you still cannot get it working, and would like to see a demo model.
Posts: 14
Threads: 2
Likes Received: 0 in 0 posts
Likes Given: 0
Joined: Jul 2011
20-07-2011, 10:29 AM
(This post was last modified: 20-07-2011, 10:29 AM by Arne@IFE.)
Now I tried it from scratch, and it seems to work the way it should do, at least if I use the $ SET RPT_FLOTS COM switch.
We will generate some more results to be sure, but it looks promising 
Posts: 1,972
Threads: 26
Likes Received: 61 in 52 posts
Likes Given: 18
Joined: Jun 2010
Good to hear! Then there is the issue of connecting the electricity from wind power (e.g. WINELC) to the common grid electricity (e.g. ELCG). I am not sure how you are doing that now, but note that the simplest way would be to use COM_AGG(r,y,WINELC,ELCG)=1 for that purpose. And then you would probably want to include the WINELC commodity in the peaking constraint together with the other electricity generation commodities, so that the wind power capacities will contribute to the peak, according to the NCAP_PKCNT coefficients that you have estimated from the hourly production statistics. But as an advanced user, I am sure you know how to handle these remaining small details.
Posts: 14
Threads: 2
Likes Received: 0 in 0 posts
Likes Given: 0
Joined: Jul 2011
Dear Antti
We have some challenges regarding load curves for our different wind turbine technologies. We have followed your proposals as listed above, and the process outputs are distributed according to the load curve. However, the sum of the Var_Fout variables from our 9 different wind power technologies, is different (higher) than the Var_Fin variable going into the common wind power electricity converter (in order to convert from WINELC to ELCG). I guess this is correct since the wind power converter takes into account the load curve.
Our concern comes when we analyse the results. If we study the activity level (energy production in GWh) of each individual wind power technology, the activity is too high compared to the wind power electricity converter. I guess the correct value (when the load curve is taken into account) is the one from the converter. However, this value is the sum of up to 9 individual technologies, and based on this, it is “impossible” to see directly the exact production from each individual wind power technology.
Do you think that it is possible for us to keep our current structure of the model and get the “correct” production from each individual technology? I know that there are some ways around this problem, e.g. have the same amount of converters as technologies, or putting the wind profile directly into the technology, but we want to keep our current structure.
I can send you a diagram of our structure if the above text was a bit unclear.
Posts: 1,972
Threads: 26
Likes Received: 61 in 52 posts
Likes Given: 18
Joined: Jun 2010
12-10-2011, 11:25 AM
(This post was last modified: 12-10-2011, 04:31 PM by Antti-L.)
Dear Arne, Yes, please provide some more details. I don't understand how the sum of the outputs can be different from the inputs, if the efficiency and PRC_ACTFLO of the wind power technologies are both 1. The output of each wind technology should, of course, be the Input * Efficiency * PRC_ACTFLO. In other words, it seems that I may be failing to understand the real source of your problem? [ Edit]: I think I read your post too quickly. If I now understand correctly, you have one process downstream of the wind power technologies, converting WINELC to ELCG, and the input to this process is smaller than the sum of the outputs of the wind power technologies? If so, I still don't understand why such an imbalance should happen, unless you have a commodity efficiency (COM_IE) defined for WINELC? If not, the commodity balance equations for WINELC should be in all normal cases strict equalities, and thus the sum of the outputs should be equal to the input. The only other explanation that I can think of is an overproduction situation, where some of the wind power is actually getting wasted in your model (at a time of very low demand). However, if indeed some of the wind power production appears to be getting wasted in your model, then the simplest solution to prevent that would be to enforce the equality of the balance equation, by setting either the LIM type of WINELC to FX, or setting a zero bound for the net production: COM_BNDNET(WINELC,UP)=0.
If you are nonetheless getting such a difference even when the commodity balance is forced to equality, that would indicate a possible bug in TIMES. Using a load curve should certainly not cause any imbalance in the commodity balance equation. So, let me know if the problem persists.
Posts: 14
Threads: 2
Likes Received: 0 in 0 posts
Likes Given: 0
Joined: Jul 2011
Dear Antti
Thanks for your response. By using COM_BNDNET(WINELC,UP)=0, the sum of the Var_Fout variables from our 9 different wind power technologies, is equal to the Var_Fin variable going into the common wind power electricity converter.
Posts: 18
Threads: 5
Likes Received: 0 in 0 posts
Likes Given: 0
Joined: Jan 2014
Hi Antti,
I'm still working with the NCAP_AF (as I do not have multiple technologies with the same profile). However, when I wanted to implement a system with a large amount of TS, I ran into some problems:
The number of rows (where I define the load profile for the demand) in Excel 97 is limited to 256. I transferred all the data in the file to a Excel 2010 file, which allows a much larger amount of columns, but now VEDA-FE indicates that the file is missing.
Is VEDA only capable of working with Excel 97 files? If yes, is there another way to enter data for a large amount (up to 8760) of TS? If no, do you have any idea about what is preventing VEDA from reading my file?
|