Update ProFAST finance models to use utilization instead of capacity (1 of 3)

[elenya-grant]

This issue is intended to capture a follow-on PR to PR #463

Currently, the ProFAST finances models represent the annual commodity production by setting the 'capacity' parameter based on the actual commodity production and the long term utilization as 1. For models that account for variable commodity production over the lifetime (like the electrolyzer model), this is not accurately represented in the finance results. This can only be represented in the finance results by setting the long term utilization to the capacity factor of the tech and setting the capacity as the actual tech's rated production capacity.

Timeline for this: 3-10 days after PR #463 is merged.

Note: May result in changed test values depending on whether the electrolyzer model outputs the life average capacity factor vs the capacity factor per year of the plant life (see PR #491)

Benefits of this development:

• Allow for lifetime performance to be reflected in financials
• Reduction in amount of hard-coded tech-specific and/or commodity-specific logic in H2IntegrateModel
• Lays the groundwork to potentially fully remove hard-coded tech-specific and/or commodity-specific logic in H2IntegrateModel. This would also allow for more consistent logic when commodity streams are not defined and not rely on the use of summer components.
• Removal of tech-specific hard-coded logic in the finance models (all technologies in the finance subgroup would pass the replacement schedule to the finance model)
• Allows more flexibility in what commodities and/or commodity streams may be connected to the finance models

Background

Currently, the only enforced naming convention in H2I is the use of "commodity_in" and "commodity_out" for models. The commodity_out stream is connected to a summer model, which sums the timeseries profile over the length of the simulation. The outputs of these summers are only accurate if a simulation is one year and has an hourly timestep. The output of the summer is connected to the finance models as total_commodity_produced, which sets the following values ProFAST:

capacity = inputs[f"total_{self.options['commodity_type']}_produced"][0] / 365.0
profast_params["capacity"] = capacity
profast_params["long term utilization"] = 1 

The capacity parameter cannot be set as an array to account for varying production over the lifetime of the plant. The long term utilization parameter (equivalent to capacity factor) can account for varying production over the lifetime of the plant. To allow for accurate accounting of annual variation of commodity production that some technology models are capable of estimating, we would have to move towards a framework where the ProFAST parameters are set as:

# create years of operation list
years_of_operation = create_years_of_operation(
            self.params.plant_life,
            self.params.analysis_start_year,
            self.params.installation_time,
        )
# below would assume hourly timestep
capacity = inputs[f"rated_{self.options['commodity_type']}_production"][0] * 24 # has to be in commodity/day
utilization = inputs[f"self.options['commodity_type']_capacity_factor"] # this is an array equal to the plant life
profast_params["capacity"] = capacity
profast_params["long term utilization"] = dict(zip(years_of_operation, utilization))

Sub tasks:

The steps to do this are:

• [/] update the storage models to have standardized outputs (PR Standardized Performance Outputs: Generic Storage & Control #493)
• [/] update combiner model to have standardized outputs (PR Standard Combiner Outputs (follow-on to 463) #501)
• update splitter model to have standardized outputs (unsure if necessary, I don't think we have a way of handling a finance stream output from a splitter but I may be wrong)
• update feedstock model to have standardized outputs
• remove "ElectricitySumComp" and replace with "GenericSummerPerformanceModel" (perhaps)
• remove use of summer components (perhaps)
• move tech-specific hard-coded logic in connect_technologies() when connecting technology streams to the finance model to create_finance_model() and format as defining the commodity stream if its not specified
• update finance model to use utilization and rated commodity production from the commodity stream, will require updates to finance models and H2IntegrateModel. This depends on most of the previous steps to be complete.

Optional steps but perhaps may be necessary:

• create a finance model baseclass, update tech-specific finance models as needed
• make a generic transport model (and/or update the pipe model) that has to be defined in the tech config, this would allow for more commodities to be introduced for transport
• more often enforce use of commodity_stream in finance subgroups
• add a generic subtractor to account for possible differences with use of storage components as commodity streams.

[jaredthomas68]

I would prefer that we continue using capacity set to actual production where appropriate, or in other words make it possible to use either use utilization as capacity factor or capacity as actual production because when a technology output does not change over its lifetime then the combination of utilization as capacity factor and capacity as rated production is re-calculating the actual production and may introduce some error, with finance models not using the same actual production as the performance models.

I also would like to suggest (likely already planned, but not mentioned explicitly above) that if we use utilization, that we enable setting it as an array to allow for varying utilization over the plant lifetime rather than using an average utilization/capacity factor because the finance model is heavily influenced by the year of production (think time value of money). I would discourage using an average capacity factor in any cases where production changes over the life of the plant.

[elenya-grant]

In response to the comments by @jaredthomas68:

1. Thanks for adding your thoughts! I appreciate it!

I think your concern about allowing varying utilization over the plant lifetime is a major part of the underlying motivation of this work (which is going to be done over many PRs and over many issues).

I think PR #491 shows my intention with using utilization and capacity to reflect lifetime performance, which is set based on the capacity_factor array (with a length equal to the plant life) that is output from models. Aka - all performance models will output capacity_factor as an array equal to the plant life and performance models that do account for lifetime performance/degradation will have a capacity_factor that varies each year (such as the electrolyzer) whereas all other models will have the capacity_factor be an array equal to the plant life where all values are the same.

I think that "when a technology output does not change over its lifetime then the combination of utilization as capacity factor and capacity as rated production" will give the same LCO if:

• utilization is set as the capacity factor and the capacity is set as the rated production (proposed change) OR
• utilization is set as 1 and the capacity is set as the actual production (currently done)

I don't think that we will have issues around the actual production calculation as long as we go with one method or the other. I think this concern will be "proved" in the PR that introduces this change if the LCO values don't change (with the exception of LCO values using commodities produced from technologies that do account for varying lifetime performance like the electrolyzer). Does that make sense?

[elenya-grant]

Note: after playing around with this, I think that some of the related steps/changes to do this are:

• remove or refactor use of summer components in H2IntegrateModel (ElectricitySumComp and GenericCombinerPerformanceModel).
• Add input option of commodity_stream to the finance models (ProFastBase and NumpyFinancialNPV) so that the finance model can properly set inputs for the relevant rated capacity of the technology specified as the commodity stream.
• If commodity_stream is not specified, then update the logic in create_finance_model() to "estimate" the commodity stream using the logic in connect_technologies() that connects technology outputs to the finance subgroup.
• Connect technology replacement schedules to the finance models (similar to how CapEx, OpEx, and VarOpEx is connected). This may cause issues for tech-specific finance models (like the steel finance model in Example 1). Should maybe only do this for finance models that are in the h2integrate/finance/ folder.

Some cases to consider for these updates to the finance model are:
- commodity stream is combiner, transporters have to carry all info to the combiner. This would be annoying for tech-specific transporters. This means that we need updates to the combiner, splitter and transporters AND/OR repurpose and refactor the use of the summer components. Perhaps theres another subsystem we can add to the finance model group that is somewhat similar to the summer component. If we update the combiner, splitter, and transporters to transport all the information (capacity factor, rated production, commodity in, etc) then this will add a lot of lines of code to connect_technologies() in H2IntegrateModel. An easier approach may be to somehow utilize a subsystem with promoted inputs/outputs instead of doing connections (specifically thinking about the combiner).
- commodity stream is a single tech, don't need to use summer.
- commodity stream is a feedstock (use 'consumed' vs 'available'). Requires updating the feedstock component model(s).
- tech-specific finance model that doesn't need all the inputs of normal finance models (such as replacement schedule)
- the battery capacity factor and rated capacity will not result in the same "battery production" as using "battery.electricity_out" because "battery.electricity_out" is equal to: electricity_in - electricity_for_charging + electricity_discharged - excess_electricity whereas the battery capacity factor and rated capacity are based only on electricity_discharged. This would only be a concern where the battery is specified as the commodity stream. I have some ideas for potential work-arounds.