You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The solver core code in question (shown below) was developed to overcome an issue with the controller. Specifically, the issue is that if the controller cannot converge with the receiver defocused then the default behavior is to turn off both the receiver and the power cycle. This issue occurs more frequently when the available space in the TES hot tank + the power cycle consumption (if on) is less than the receiver minimum defocus mass flow. This issue becomes worst when using clear-sky receiver flow control and/or sub-hourly time steps. Additionally, this issue can come up frequently in the CSP-ETES case depending on the design.
When this event occurs, the power cycle shuts down and must be restarted which results in lost system revenue. Depending on the number of occurrences, this issue can have a small or large impact on results.
In the theory the solution is simple, but I know that it might not be easy to implement. When the receiver cannot defocus enough to converge the system, we need to trip the receiver and allow the power cycle operations to continue. In my simple understand of the controller, we would need to “reset” the decision tree with the receiver off because defocusing didn’t provide a converge solution. The purpose of the code in question is to estimate if defocusing the receiver is a valid operating state a priori of the controller decision tree.
Lines 800-828 of csp_solver_core.cpp. I added lines 819-822 to handle the heater double defocus issue for now. Based on limited testing, lines 819-822 “fixes” the double defocusing of the heater but doesn’t impact the CSP or the CSP+ETES cases.
The text was updated successfully, but these errors were encountered:
The solver core code in question (shown below) was developed to overcome an issue with the controller. Specifically, the issue is that if the controller cannot converge with the receiver defocused then the default behavior is to turn off both the receiver and the power cycle. This issue occurs more frequently when the available space in the TES hot tank + the power cycle consumption (if on) is less than the receiver minimum defocus mass flow. This issue becomes worst when using clear-sky receiver flow control and/or sub-hourly time steps. Additionally, this issue can come up frequently in the CSP-ETES case depending on the design.
When this event occurs, the power cycle shuts down and must be restarted which results in lost system revenue. Depending on the number of occurrences, this issue can have a small or large impact on results.
In the theory the solution is simple, but I know that it might not be easy to implement. When the receiver cannot defocus enough to converge the system, we need to trip the receiver and allow the power cycle operations to continue. In my simple understand of the controller, we would need to “reset” the decision tree with the receiver off because defocusing didn’t provide a converge solution. The purpose of the code in question is to estimate if defocusing the receiver is a valid operating state a priori of the controller decision tree.
Lines 800-828 of csp_solver_core.cpp. I added lines 819-822 to handle the heater double defocus issue for now. Based on limited testing, lines 819-822 “fixes” the double defocusing of the heater but doesn’t impact the CSP or the CSP+ETES cases.
The text was updated successfully, but these errors were encountered: