The power cycle failure model needs to be called from the MSPT model during annual simulation to allow the dispatch optimization algorithm and failure model to interact on a daily basis. The workflow will be:

1. Begin SSC simulation
2. Call dispatch optimization assuming no power cycle downtime. Get back the optimal time series dispatch profile for the plant.
3. Call the failure model with initial hazard rate parameters and the optimized schedule from the dispatch optimization routine. Get back an availability/failure schedule for the upcoming time horizon.
4. Run the simulation assuming no foreknowledge of impending failures.
5. If a failure occurs at some point, run the simulation until the time step just before the failure occurs. At that point, re-run the dispatch optimization algorithm for the remainder of the original time horizon with constraints in place to limit power production according to the failure or capacity reduction. We can assume for now that the constraints will be implemented in the AMPL code and not in the internal LPSolve code.
6. Continue the simulation and execute the optimized schedule identified in the previous step.
7. Repeat the process at the start of the next day.

This should primarily be owned by @jannamartinek but @zolanaj should probably help.

The calculations that characterize flux and optical efficiency of a heliostat field are a nontrivial portion of the clock time involved in running a simulation. Support of multithreading these calculations may significantly improve run time.

The optical degradation and soiling model O calculates heliostat reflectivity over time, with losses incurred both due to soiling (short term and reversible) and mirror degradation (long term and reversible only with mirror replacement). The model has been coded and runs, but the accuracy has not been verified nor have input parameters been ascertained from literature or anecdotal recommendations.

Issues with getting SSC to write the AMPL thread ID correctly.
will-test-case.zip

The optimization toolkit developed by Argonne needs to be callable by DAO-Tk. Calls will preferably be made via a C/C++ API and allow for progress update callbacks. The settings for the solver should be set to default values that make sense for this application, but should be customizable by the user.

There are several methods defined in PySDK that have already been transitioned. These include:

• D -- the solar field design and layout method
• M -- the heliostat maintenance (availability) model
• O -- the optical degradation model
• S -- the annual performance simulation method with clustering

Remaining are:

• E -- explicit cost calculations
• F -- the financial calculation method
• Z -- the rolled-up objective function that includes all sub-methods. A user should be able to call Z without any prior method calls and execute the full suite of model calls.

@jannamartinek can take the lead on the remaining items and work with me to get this completed.

A first start if we want to revisit the code

The optical degradation and soiling model should be updated to allow relaxation of the number of wash crews to be a continuous variable rather than fixed at discrete integer values. This can follow the template for the heliostat availability model relaxation.

The LK script calls and documentation should be developed to call all methods from the objective function as originally defined in the PySDK objective function module.

The current scheme for determining the update interval and time horizon for the dispatch optimization algorithm takes two parameters:

1. The optimization time horizon (default 48 hours)
2. The update interval (default 24 hours)

These parameters can be set by the user to allow re-optimization every 6 hours, for example. At the time of re-optimization, the dispatch problem is always formulated using the same time horizon. In the case of dispatch optimization using stochastic forecasting, it is desirable to re-run the optimization frequently (say, every 4 hours) as improved forecasts become available. However, it is not necessary to hold the optimization time horizon constant, as it is likely justifiable to terminate the optimization horizon at midnight of the following day.

The code should be updated to allow for 2 modes:
A. The user sets the update interval and time horizon, and both remain constant (current baseline)
B. The user sets the update interval and maximum time horizon, and the time horizon is reduced at increments equal to the update interval until the simulation time rolls over to the next day. For example:

day     1______________________2_______________________3_______________________4
hour    0    6     12    18    24    6     12    18    24    6     12    18    24
        ..... ..... ..... ..... ..... ..... ..... ..... ..... ..... ..... ..... 
run     x----------------------------------------------x
             x-----------------------------------------x
                   x-----------------------------------x
                         x-----------------------------x
                               x-----------------------------------------------x
                                     x-----------------------------------------x
                                           x-----------------------------------x
                                                 x-----------------------------x             
                                                         etc....