Molten Salt Power Tower with no daytime generation

The molten salt power tower system in the attached .sam file is configured to avoid generating power during the day using the Dispatch Control inputs on the System Control page. The purpose of this design is to store solar energy during the day and dispatch it at night. The graph below shows time series results for July 14.

This is for the default Molten Salt Power Tower / PPA Single Owner configuration with a nameplate capacity of 104 MWe and storage capacity of 10 full load hours.

The only inputs we changed from their default values are the dispatch periods defined on the System Control page that determine how the storage system operates:

• Period 1 is the nighttime period from 6 pm to 5 am throughout the year with Turbine Output Fraction = 1 to allow the system to generate electricity up to its design output level.
• Period 2 is the daytime period from 6 am to to 5 pm with Turbine Output Fraction = 0 to prevent the system from generating electricty during the day.

This dispatch configuration involves the following operating modes:

• Reciever is "on," meaning it is sending hot heat transfer fluid (HTF) to thermal energy storage (TES) and power cycle as needed. In this mode, the Field incident thermal power and Receiver thermal power to HTF outputs reflect the system's operating mode. For example from 5 am to Noon in the graph below.
• Receiver is on and heliostats in the field are defocused: Field incident thermal power shows the power available to the field without any defocusing. Receiver thermal power to HTF and Receiver incident thermal power do show the effect of defocused heliostats. For example, at Noon.
• Receiver is starting up: Field incident thermal power shows the power available to the field. Receiver thermal power to HTF is zero, and Receiver startup thermal energy consumed shows the power used for startup. For example, 5 am and 2 pm - 6 pm (see issue described below).
• Receiver is "off:" Field incident thermal power, Receiver thermal power to HTF, and Receiver startup thermal energy are all zero. This is true even for time steps when there is solar energy available, for example at 1 pm when the TES is full and the power cycle is off.

One issue with the algorithm for this system control configuration that we are working to fix is that during sunny days when the power cycle is off (because the turbine output fraction on the System Control page is zero for that time step), and the TES is full by early afternoon, the receiver should turn off for the rest of the afternoon. However, the control algorithm doesn’t always prevent the receiver from starting up during this period. So, within a single time step, the receiver starts and then immediately stops because there is no place for the hot HTF to go. This is clearly not how an actual plant would operate, but the impact on the system's total annual electrical generation is relatively small. Some electricity is consumed for to HTF pumping and heliostat tracking loads during the unrealistic startup events, which reduces the annual generation value by about 1 or 2%. It also causes the field incident thermal power to be higher than it should be, which does not affect the electrical power generation, but does make it tricky to do energy accounting calculations.

For detailed illustration of this issue, see the 2 - 6 pm period in the graph below, after the TES is fully charged and the receiver turns off. At 1 pm the receiver is off so Field incident thermal power, Receiver incident thermal power, and Receiver startup energy are all zero. At 2 pm the model sees that there is sufficient DNI to start the receiver, so it begins the startup process and then immediately stops it as described above. This happens in each time step until the end of the day. During these time steps, the Receiver incident thermal power is zero, and the Field incident thermal power and Receiver startup power represent the power in the portion of the time step that the receiver attempted to start.



Best regards,
Paul.