### Run Basic REopt Optimization Source: https://nrel.github.io/REopt.jl/dev/reopt/examples Executes a basic REopt optimization using a provided JSON input file. Requires REopt.jl, JuMP.jl, and a compatible solver (e.g., HiGHS). Takes a JuMP model and a JSON file path as input, and returns optimization results. ```julia using REopt, JuMP, HiGHS m = Model(HiGHS.Optimizer) results = run_reopt(m, "pv_storage.json") ``` -------------------------------- ### Modify REopt Mathematical Model (Add PV Curtailment Cost) Source: https://nrel.github.io/REopt.jl/dev/reopt/examples Demonstrates advanced usage of REopt.jl by modifying the mathematical model before optimization. This example adds a cost for curtailed PV power by altering the objective function using JuMP.jl methods. It requires REopt.jl, JuMP.jl, HiGHS, and REoptInputs. ```julia using HiGHS using JuMP using REopt m = JuMP.Model(HiGHS.Optimizer) p = REoptInputs("pv_storage.json"); build_reopt!(m, p) #= replace the original objective, which is to Min the Costs, with the Costs + 100 * (total curtailed PV power) =# JuMP.@objective(m, Min, m[:Costs] + 100 * sum(m[:dvCurtail]["PV", ts] for ts in p.time_steps)); JuMP.optimize!(m) # normally this command is called in run_reopt results = reopt_results(m, p) ``` -------------------------------- ### Run MPC simulation in Julia with REopt Source: https://nrel.github.io/REopt.jl/dev/mpc/examples This code snippet shows how to initialize and run an MPC simulation using REopt in Julia. It requires the JuMP and Cbc packages for optimization. The function takes a model and a scenario file path as inputs. ```Julia using REopt, JuMP, Cbc model = Model(Cbc.Optimizer) results = run_mpc(model, "./test/scenarios/mpc.json") ``` -------------------------------- ### Running REopt with Multiple Models and BAU Scenario Source: https://nrel.github.io/REopt.jl/dev/developer/concept Demonstrates how to run the REopt model with multiple JuMP models and trigger the Business As Usual (BAU) scenario calculation. This example utilizes the Xpress optimizer. ```julia m1 = Model(optimizer_with_attributes(Xpress.Optimizer, "OUTPUTLOG" => 0)) m2 = Model(optimizer_with_attributes(Xpress.Optimizer, "OUTPUTLOG" => 0)) results = run_reopt([m1,m2], "./scenarios/pv_storage.json") ``` -------------------------------- ### Compare Optimized Case with Business-as-Usual (BAU) Scenario Source: https://nrel.github.io/REopt.jl/dev/reopt/examples Compares an optimized energy system scenario with a 'Business-as-usual' (BAU) case using REopt.jl. This involves providing two JuMP models to `run_reopt` and uses a single input dictionary. The results will include comparative metrics like net present value and emissions reductions. ```julia m1 = Model(HiGHS.Optimizer) m2 = Model(HiGHS.Optimizer) results = run_reopt([m1,m2], "pv_storage.json") ``` -------------------------------- ### Calculate Net Metering Benefit (Julia) Source: https://nrel.github.io/REopt.jl/dev/developer/inputs An example of calculating the Net Metering (NEM) benefit using the `techs_by_exportbin` map. It sums the production sent to the grid for technologies capable of net metering, weighted by export rates and time step duration. ```julia NEM_benefit = @expression(m, p.pwf_e * p.hours_per_time_step * sum( sum(p.s.electric_tariff.export_rates[:NEM][ts] * m[Symbol("dvProductionToGrid"*_n)][t, :NEM, ts] for t in p.techs_by_exportbin[:NEM]) for ts in p.time_steps) ) ``` -------------------------------- ### Constrain PV Size by Location Source: https://nrel.github.io/REopt.jl/dev/developer/adding_tech Example constraint applied over techs.pv that limits the size of PV technologies based on their location. Demonstrates how dvSize variables are constrained using pv_to_location mapping and maxsize_pv_locations limits. ```julia @constraint(m, [loc in p.pvlocations], sum(m[Symbol("dvSize"*_n)][t] * p.pv_to_location[t][loc] for t in p.techs.pv) <= p.maxsize_pv_locations[loc] ) ``` -------------------------------- ### Simulate outages for resilience analysis in Julia Source: https://nrel.github.io/REopt.jl/dev/reopt/methods Performs time series simulation of outages starting at every time step to calculate resilience metrics for energy systems. Supports battery, PV, wind, and diesel generator configurations. Returns probabilities of meeting critical load during outages, survival probabilities by duration, and monthly/hourly breakdowns. ```julia simulate_outages(;batt_kwh=0, batt_kw=0, pv_kw_ac_hourly=[], init_soc=[], critical_loads_kw=[], wind_kw_ac_hourly=[], batt_roundtrip_efficiency=0.829, diesel_kw=0, fuel_available=0, b=0, m=0, diesel_min_turndown=0.3 ) simulate_outages(d::Dict, p::REoptInputs; microgrid_only::Bool=false) ``` -------------------------------- ### REopt Testing: Scenario Initialization (Julia) Source: https://nrel.github.io/REopt.jl/dev/developer/adding_tech Demonstrates the initial step in testing a new technology integration by creating a `Scenario` object from a JSON input file. This verifies the basic input parsing for the new technology. ```Julia @testset "My new technology" begin s = Scenario("path/to/mynewtech.json") end ``` -------------------------------- ### Map Technologies to Export Bins (Julia) Source: https://nrel.github.io/REopt.jl/dev/developer/inputs Illustrates the structure of the `techs_by_exportbin` dictionary, which maps technologies to the export bins they can utilize (NEM, Wholesale, Excess). This mapping is determined by technology attributes like `can_net_meter`. ```julia techs_by_exportbin = Dict( :NEM => ["PV", "Wind"], :WHL => [], :EXC => [] ) ``` -------------------------------- ### REopt Testing: REoptInputs Initialization (Julia) Source: https://nrel.github.io/REopt.jl/dev/developer/adding_tech Tests the creation of the `REoptInputs` object after a `Scenario` has been successfully initialized. This step validates that the input data is correctly processed into the format required by the REopt model. ```Julia @testset "My new technology" begin s = Scenario("path/to/mynewtech.json") p = REoptInputs(s) end ``` -------------------------------- ### run_reopt Method Source: https://nrel.github.io/REopt.jl/dev/reopt/methods The `run_reopt` method is the primary way to solve REopt models. It supports various input combinations for defining the scenario, including file paths, dictionaries, and scenario objects. ```APIDOC ## run_reopt ### Description Solves the REopt model using a scenario defined by the provided inputs. ### Method `run_reopt(m::JuMP.AbstractModel, fp::String)` ### Parameters #### Path Parameters - `fp` (String) - Required - Path to a JSON file defining the scenario. ### Method `run_reopt(m::JuMP.AbstractModel, d::Dict)` ### Parameters #### Request Body - `d` (Dict) - Required - A dictionary defining the scenario. ### Method `run_reopt(m::JuMP.AbstractModel, s::AbstractScenario)` ### Parameters #### Request Body - `s` (AbstractScenario) - Required - An AbstractScenario object. ### Method `run_reopt(t::Tuple{JuMP.AbstractModel, AbstractScenario})` ### Parameters #### Request Body - `t` (Tuple{JuMP.AbstractModel, AbstractScenario}) - Required - A tuple containing a JuMP model and an AbstractScenario object, used for parallel BAU scenario runs. ### Method `run_reopt(ms::AbstractArray{T, 1}, fp::String) where T <: JuMP.AbstractModel` ### Parameters #### Path Parameters - `fp` (String) - Required - Path to a JSON file defining the scenario. - `ms` (AbstractArray{T, 1}) - Required - An array of JuMP models for parallel scenario and BAU scenario runs. ### Method `run_reopt(ms::AbstractArray{T, 1}, d::Dict) where T <: JuMP.AbstractModel` ### Parameters #### Request Body - `d` (Dict) - Required - A dictionary defining the scenario. - `ms` (AbstractArray{T, 1}) - Required - An array of JuMP models for parallel scenario and BAU scenario runs. ``` -------------------------------- ### REopt Testing: Model Building (Julia) Source: https://nrel.github.io/REopt.jl/dev/developer/adding_tech Tests the model building process by creating a JuMP `Model` and calling `build_reopt!` with the scenario input file. This verifies that the mathematical model can be constructed with the new technology's inputs. ```Julia @testset "My new technology" begin m = Model(Cbc.Optimizer) build_reopt!(m, "path/to/mynewtech.json") end ``` -------------------------------- ### Apply Constraint to All Technologies (Julia) Source: https://nrel.github.io/REopt.jl/dev/developer/inputs Demonstrates how to apply a constraint to all technologies modeled in REopt.jl using the `techs.all` index set. This is useful for setting upper bounds on decision variables like `dvSize`. ```julia @constraint(m, [t in p.techs.all], m[Symbol("dvSize"*_n)][t] <= p.max_sizes[t] ) ``` -------------------------------- ### build_reopt! Method Source: https://nrel.github.io/REopt.jl/dev/reopt/methods The `build_reopt!` method is used to construct the REopt model by adding variables and constraints. It can accept either a file path to a JSON scenario or a pre-defined `REoptInputs` object. ```APIDOC ## build_reopt! ### Description Adds variables and constraints to a JuMP model to prepare it for REopt optimization. ### Method `build_reopt!(m::JuMP.AbstractModel, fp::String)` ### Parameters #### Path Parameters - `fp` (String) - Required - Path to a JSON file used to construct `REoptInputs`. ### Method `build_reopt!(m::JuMP.AbstractModel, p::REoptInputs)` ### Parameters #### Request Body - `p` (REoptInputs) - Required - A pre-constructed `REoptInputs` object. ``` -------------------------------- ### REoptInputs Constructor from JSON File - REopt.jl Source: https://nrel.github.io/REopt.jl/dev/developer/inputs Constructs REoptInputs by loading scenario data from a specified JSON file path. This method first parses the JSON file into a Scenario object and then uses it to initialize REoptInputs. ```julia function REoptInputs(fp::String) s = Scenario(JSON.parsefile(fp)) REoptInputs(s) end ``` -------------------------------- ### Create Techs from Scenario Source: https://nrel.github.io/REopt.jl/dev/developer/adding_tech Constructor method to create a Techs struct for REoptInputs from a given Scenario. This initializes the technology index sets needed for the optimization model. ```julia Techs(s::Scenario) ``` -------------------------------- ### Add Electric Tariff Results to REopt Source: https://nrel.github.io/REopt.jl/dev/reopt/outputs Adds detailed results for the ElectricTariff component to the REopt analysis. This includes lifecycle and year-one costs for energy, demand, fixed charges, minimum charges, and export benefits, all calculated before and after tax. It provides a comprehensive view of grid-related costs and benefits. ```python REopt.add_electric_tariff_results ``` -------------------------------- ### Create Techs from REoptInputs and BAUScenario Source: https://nrel.github.io/REopt.jl/dev/developer/adding_tech Constructor method to create a Techs struct for BAUInputs from REoptInputs and a BAUScenario. Used for defining technology sets in business-as-usual scenarios. ```julia Techs(p::REoptInputs, s::BAUScenario) ``` -------------------------------- ### REoptInputs Structure Definition - REopt.jl Source: https://nrel.github.io/REopt.jl/dev/developer/inputs Defines the REoptInputs structure, which holds all necessary data for constructing the JuMP mathematical model in REopt.jl. It includes numerous fields for technologies, sizes, costs, production factors, and emissions. ```julia struct REoptInputs <: AbstractInputs s::ScenarioType techs::Techs min_sizes::Dict{String, <:Real} # (techs) max_sizes::Dict{String, <:Real} # (techs) existing_sizes::Dict{String, <:Real} # (techs) cap_cost_slope::Dict{String, Any} # (techs) om_cost_per_kw::Dict{String, <:Real} # (techs) thermal_cop::Dict{String, <:Real} # (techs.absorption_chiller) time_steps::UnitRange time_steps_with_grid::Array{Int, 1} time_steps_without_grid::Array{Int, 1} hours_per_time_step::Real months::UnitRange production_factor::DenseAxisArray{<:Real, 2} # (techs, time_steps) levelization_factor::Dict{String, <:Real,} value_of_lost_load_per_kwh::Array{<:Real, 1} pwf_e::Real pwf_om::Real pwf_fuel::Dict{String, <:Real} pwf_emissions_cost::Dict{String, Float64} # Cost of emissions present worth factors for grid and onsite fuelburn emissions [unitless] pwf_grid_emissions::Dict{String, Float64} # Emissions [lbs] present worth factors for grid emissions [unitless] pwf_offtaker::Real pwf_owner::Real third_party_factor::Real pvlocations::Array{Symbol, 1} maxsize_pv_locations::DenseAxisArray{<:Real, 1} # indexed on pvlocations pv_to_location::Dict{String, Dict{Symbol, Int64}} # (techs.pv, pvlocations) ratchets::UnitRange techs_by_exportbin::Dict{Symbol, AbstractArray} # keys can include [:NEM, :WHL, :CUR] export_bins_by_tech::Dict n_segs_by_tech::Dict{String, Int} seg_min_size::Dict{String, Dict{Int, <:Real}} seg_max_size::Dict{String, Dict{Int, <:Real}} seg_yint::Dict{String, Dict{Int, <:Real}} pbi_pwf::Dict{String, Any} # (pbi_techs) pbi_max_benefit::Dict{String, Any} # (pbi_techs) pbi_max_kw::Dict{String, Any} # (pbi_techs) pbi_benefit_per_kwh::Dict{String, Any} # (pbi_techs) boiler_efficiency::Dict{String, <:Real} fuel_cost_per_kwh::Dict{String, AbstractArray} # Fuel cost array for all time_steps ghp_options::UnitRange{Int64} # Range of the number of GHP options require_ghp_purchase::Int64 # 0/1 binary if GHP purchase is forced/required ghp_heating_thermal_load_served_kw::Array{Float64,2} # Array of heating load (thermal!) profiles served by GHP ghp_cooling_thermal_load_served_kw::Array{Float64,2} # Array of cooling load profiles served by GHP space_heating_thermal_load_reduction_with_ghp_kw::Array{Float64,2} # Array of heating load reduction (thermal!) profile from GHP retrofit cooling_thermal_load_reduction_with_ghp_kw::Array{Float64,2} # Array of cooling load reduction (thermal!) profile from GHP retrofit ghp_electric_consumption_kw::Array{Float64,2} # Array of electric load profiles consumed by GHP ghp_installed_cost::Array{Float64,1} # Array of installed cost for GHP options ghp_om_cost_year_one::Array{Float64,1} # Array of O&M cost for GHP options tech_renewable_energy_fraction::Dict{String, <:Real} # union(techs.elec, techs.fuel_burning) tech_emissions_factors_CO2::Dict{String, <:Real} # (techs) tech_emissions_factors_NOx::Dict{String, <:Real} # (techs) tech_emissions_factors_SO2::Dict{String, <:Real} # (techs) tech_emissions_factors_PM25::Dict{String, <:Real} # (techs) techs_operating_reserve_req_fraction::Dict{String, <:Real} # (techs.all) heating_cop::Dict{String, Array{<:Real, 1}} # (techs.ashp) cooling_cop::Dict{String, Array{<:Real, 1}} # (techs.ashp) heating_cf::Dict{String, Array{<:Real, 1}} # (techs.ashp) cooling_cf::Dict{String, Array{<:Real, 1}} # (techs.ashp) heating_loads_kw::Dict{String, <:Real} # (heating_loads) unavailability::Dict{String, Array{Float64,1}} # Dict by tech of unavailability profile end ``` -------------------------------- ### REopt Inputs: Production Factor Calculation (Julia) Source: https://nrel.github.io/REopt.jl/dev/developer/adding_tech Defines the structure for production factors used in electrical load balance constraints. It initializes an array indexed by technology and time step, then populates it using technology-specific functions like `get_production_factor` for PV systems. ```Julia sum(p.production_factor[t, ts] * p.levelization_factor[t] * m[Symbol("dvRatedProduction"*_n)][t,ts] for t in p.techs.elec) production_factor = DenseAxisArray{Float64}(undef, techs.all, 1:length(s.electric_load.loads_kw)) for pv in s.pvs production_factor[pv.name, :] = get_production_factor(pv, s.site.latitude, s.site.longitude) ... end ``` -------------------------------- ### REopt Testing: Full Workflow Execution (Julia) Source: https://nrel.github.io/REopt.jl/dev/developer/adding_tech Tests the complete REopt workflow, including model optimization and results generation. This involves running `run_reopt` and asserting specific values in the output results dictionary to confirm functionality. ```Julia @testset "My new technology" begin m = Model(Cbc.Optimizer) results = run_reopt(m, "path/to/mynewtech.json") @test results["mynewtech"]["some_result"] ≈ 78.9 atol=0.1 end ``` -------------------------------- ### FlexibleHVAC Outputs Source: https://nrel.github.io/REopt.jl/dev/reopt/outputs Details the output keys generated by the `REopt.add_flexible_hvac_results` function for Flexible HVAC systems. These keys include purchased energy, temperature profiles, and upgrade costs. ```APIDOC ## FlexibleHVAC Outputs ### Description This section details the output keys for `FlexibleHVAC`, generated by the `REopt.add_flexible_hvac_results` function. ### Keys * `purchased`: Energy purchased by the Flexible HVAC system. * `temperatures_degC_node_by_time`: Temperature profiles at different nodes over time [°C]. * `upgrade_cost`: The cost to upgrade the Flexible HVAC system. ``` -------------------------------- ### REoptInputs Constructor from AbstractScenario - REopt.jl Source: https://nrel.github.io/REopt.jl/dev/developer/inputs Constructs REoptInputs directly from an existing AbstractScenario object. This constructor is useful for manually modifying scenario inputs before they are translated into the data structures needed for the JuMP model. ```julia function REoptInputs(s::AbstractScenario) # Constructor for REoptInputs. Translates the `Scenario` into all the data necessary for building the JuMP model. end ``` -------------------------------- ### Calculate Backup Reliability with Dict Input in Julia Source: https://nrel.github.io/REopt.jl/dev/reopt/methods This overloaded function returns a dictionary of backup reliability results using a reliability inputs dictionary. It accounts for critical loads, CHP, PV, battery parameters, and generator details, requiring hourly data arrays of 8760 lengths. Limitations include maximum 96-hour outage modeling and the need for specified production factors for PV if included. ```Julia backup_reliability(r::Dict) ``` -------------------------------- ### REopt PV Technology Electrical Load Balance Constraint (Julia) Source: https://nrel.github.io/REopt.jl/dev/developer/adding_tech This Julia code defines the electrical load balance constraint for the PV technology within the REopt model. It utilizes the JuMP modeling language to express the balance between electricity production, storage, grid purchases, and demand. Dependencies include the REoptInputs structure (aliased as 'p') and the JuMP Model (aliased as 'm'). ```julia @constraint(m, [ts in p.time_steps_with_grid], sum(p.production_factor[t, ts] * p.levelization_factor[t] * m[Symbol("dvRatedProduction"*_n)][t,ts] for t in p.techs.elec) + sum( m[Symbol("dvDischargeFromStorage"*_n)][b,ts] for b in p.s.storage.types.elec ) + sum(m[Symbol("dvGridPurchase"*_n)][ts, tier] for tier in 1:p.s.electric_tariff.n_energy_tiers) == sum( sum(m[Symbol("dvProductionToStorage"*_n)][b, t, ts] for b in p.s.storage.types.elec) + m[Symbol("dvCurtail"*_n)][t, ts] for t in p.techs.elec) + sum(m[Symbol("dvGridToStorage"*_n)][b, ts] for b in p.s.storage.types.elec) + p.s.electric_load.loads_kw[ts] ) ``` -------------------------------- ### AbsorptionChiller Outputs Source: https://nrel.github.io/REopt.jl/dev/reopt/outputs Details the output keys generated by the `REopt.add_absorption_chiller_results` function for Absorption Chiller systems. These keys include sizing, thermal and electric consumption, and production. ```APIDOC ## AbsorptionChiller Outputs ### Description This section details the output keys for `AbsorptionChiller`, generated by the `REopt.add_absorption_chiller_results` function. ### Keys * `size_kw`: Optimal power capacity size of the absorption chiller system [kW] * `size_ton`: Optimal tonnage size of the absorption chiller system. * `thermal_to_storage_series_ton`: Thermal production sent to ColdThermalStorage [ton] * `thermal_to_load_series_ton`: Thermal production sent to meet cooling load [ton] * `thermal_consumption_series_mmbtu_per_hour`: Hourly thermal energy consumption [MMBtu/hr] * `annual_thermal_consumption_mmbtu`: Total annual thermal energy consumption [MMBtu] * `annual_thermal_production_tonhour`: Total annual thermal energy production [ton-hour] ``` -------------------------------- ### Outages Outputs Source: https://nrel.github.io/REopt.jl/dev/reopt/outputs Details the output keys generated by the `REopt.add_outage_results` function for outage modeling. These keys provide information on various costs, unserved load, and system performance during outages. ```APIDOC ## Outages Outputs ### Description This section details the output keys for `Outages`, which are generated when outages are modeled using `ElectricUtility.outage_start_time_steps` and `ElectricUtility.outage_durations`. ### Keys * `expected_outage_cost`: The expected outage cost over the random outages modeled. * `max_outage_cost_per_outage_duration`: The maximum outage cost in every outage duration modeled. * `unserved_load_series_kw`: The amount of unserved load in each outage and each time step. * `unserved_load_per_outage_kwh`: The total unserved load in each outage. * `storage_microgrid_upgrade_cost`: The cost to include the storage system in the microgrid. * `storage_discharge_series_kw`: Array of storage power discharged in every outage modeled. * `pv_microgrid_size_kw`: Optimal microgrid PV capacity. Note that the name `PV` can change based on user provided `PV.name`. * `pv_microgrid_upgrade_cost`: The cost to include the PV system in the microgrid. * `pv_to_storage_series_kw`: Array of PV power sent to the battery in every outage modeled. * `pv_curtailed_series_kw`: Array of PV curtailed in every outage modeled. * `pv_to_load_series_kw`: Array of PV power used to meet load in every outage modeled. * `wind_microgrid_size_kw`: Optimal microgrid Wind capacity. * `wind_microgrid_upgrade_cost`: The cost to include the Wind system in the microgrid. * `wind_to_storage_series_kw`: Array of Wind power sent to the battery in every outage modeled. * `wind_curtailed_series_kw`: Array of Wind curtailed in every outage modeled. * `wind_to_load_series_kw`: Array of Wind power used to meet load in every outage modeled. * `generator_microgrid_size_kw`: Optimal microgrid Generator capacity. Note that the name `Generator` can change based on user provided `Generator.name`. * `generator_microgrid_upgrade_cost`: The cost to include the Generator system in the microgrid. * `generator_to_storage_series_kw`: Array of Generator power sent to the battery in every outage modeled. * `generator_curtailed_series_kw`: Array of Generator curtailed in every outage modeled. * `generator_to_load_series_kw`: Array of Generator power used to meet load in every outage modeled. * `generator_fuel_used_per_outage_gal`: Array of fuel used in every outage modeled, summed over all Generators. * `chp_microgrid_size_kw`: Optimal microgrid CHP capacity. * `chp_microgrid_upgrade_cost`: The cost to include the CHP system in the microgrid. * `chp_to_storage_series_kw`: Array of CHP power sent to the battery in every outage modeled. * `chp_curtailed_series_kw`: Array of CHP curtailed in every outage modeled. * `chp_to_load_series_kw`: Array of CHP power used to meet load in every outage modeled. * `chp_fuel_used_per_outage_mmbtu`: Array of fuel used in every outage modeled, summed over all CHPs. * `microgrid_upgrade_capital_cost`: Total capital cost of including technologies in the microgrid. * `critical_loads_per_outage_series_kw`: Critical load series in every outage modeled. * `soc_series_fraction`: ElectricStorage state of charge series in every outage modeled. ### Warnings * The output keys for `Outages` are subject to change. * The `Outages` results can be very large when many outages are modeled and can take a long time to generate. ``` -------------------------------- ### Fix Curtailment to Zero for Specific Technologies (Julia) Source: https://nrel.github.io/REopt.jl/dev/developer/inputs Shows how to iterate through a subset of technologies (`techs.no_curtail`) and fix their curtailment decision variable (`dvCurtail`) to zero for all time steps. This is typically used for technologies that should not curtail production. ```julia for t in p.techs.no_curtail for ts in p.time_steps fix(m[Symbol("dvCurtail"*_n)][t, ts] , 0.0, force=true) end end ``` -------------------------------- ### Combine REopt Results Dictionaries Source: https://nrel.github.io/REopt.jl/dev/reopt/outputs Combines Business As Usual (BAU) and optimal scenario results dictionaries into a single dictionary. Adds new fields to the Financial output, such as Net Present Value (NPV) and various cost savings metrics. This method is crucial for comparing scenarios and assessing financial performance. ```python REopt.combine_results(bau::Dict, opt::Dict) ``` -------------------------------- ### Calculate Backup Reliability with REopt Inputs in Julia Source: https://nrel.github.io/REopt.jl/dev/reopt/methods This function computes a dictionary of backup reliability results using REopt results, inputs struct, and reliability parameters. It models outage scenarios up to 96 time steps, factoring in operational availabilities of generators, batteries, PV, and wind. Limitations include no support for subhourly time steps and dependency on REopt data structures. ```Julia backup_reliability(d::Dict, p::REoptInputs, r::Dict) ``` -------------------------------- ### REopt Results: Adding Technology-Specific Results (Julia) Source: https://nrel.github.io/REopt.jl/dev/developer/adding_tech Illustrates how to conditionally add results for a newly implemented technology, such as PV, to the main results dictionary. This check ensures results are only computed if the technology is present in the model. ```Julia if !isempty(p.techs.pv) add_pv_results(m, p, d; _n) end ``` -------------------------------- ### Add Electric Load Results to REopt Source: https://nrel.github.io/REopt.jl/dev/reopt/outputs Adds results for the ElectricLoad component to the REopt analysis. This function provides time-series data for site load and critical load, as well as annual calculated energy consumption (kWh). It also includes metrics for off-grid scenarios, such as load met by generation and operating reserves. ```python REopt.add_electric_load_results ``` -------------------------------- ### Define Techs Struct Source: https://nrel.github.io/REopt.jl/dev/developer/adding_tech The Techs struct contains index sets used to define model constraints and decision variables for various energy technologies. It includes fields for different technology categories like PV, generators, heating, cooling, and more. ```julia mutable struct Techs all::Vector{String} elec::Vector{String} pv::Vector{String} gen::Vector{String} pbi::Vector{String} no_curtail::Vector{String} no_turndown::Vector{String} segmented::Vector{String} heating::Vector{String} cooling::Vector{String} boiler::Vector{String} fuel_burning::Vector{String} thermal::Vector{String} chp::Vector{String} requiring_oper_res::Vector{String} providing_oper_res::Vector{String} electric_chiller::Vector{String} absorption_chiller::Vector{String} steam_turbine::Vector{String} can_supply_steam_turbine::Vector{String} electric_heater::Vector{String} can_serve_space_heating::Vector{String} can_serve_dhw::Vector{String} can_serve_process_heat::Vector{String} ghp::Vector{String} ashp::Vector{String} ashp_wh::Vector{String} end ``` -------------------------------- ### REopt.add_boiler_results Function Source: https://nrel.github.io/REopt.jl/dev/reopt/outputs This function adds Boiler results to the REopt model. It provides keys for boiler thermal capacity, fuel consumption series, annual thermal production, and lifecycle cost metrics. Series and annual outputs are average annual values over the analysis period. ```APIDOC ## REopt.add_boiler_results ### Description The REopt.add_boiler_results function incorporates Boiler system results into the REopt model, detailing thermal production capacities, fuel usage time-series, and associated costs for heating applications. ### Method Function ### Endpoint REopt.add_boiler_results ### Parameters No input parameters specified in documentation. ### Results #### Boiler Results Keys - **size_mmbtu_per_hour** (Float) - Required - Thermal production capacity size of the Boiler [MMBtu/hr] - **fuel_consumption_series_mmbtu_per_hour** (Array) - Required - Fuel consumption series [MMBtu/hr] - **annual_fuel_consumption_mmbtu** (Float) - Required - Fuel consumed in a year [MMBtu] - **thermal_production_series_mmbtu_per_hour** (Array) - Required - Thermal energy production series [MMBtu/hr] - **annual_thermal_production_mmbtu** (Float) - Required - Thermal energy produced in a year [MMBtu] - **thermal_to_storage_series_mmbtu_per_hour** (Array) - Required - Thermal power production to TES (HotThermalStorage) series [MMBtu/hr] - **thermal_to_steamturbine_series_mmbtu_per_hour** (Array) - Required - Thermal power production to SteamTurbine series [MMBtu/hr] - **thermal_to_load_series_mmbtu_per_hour** (Array) - Required - Thermal power production to serve the heating load series [MMBtu/hr] - **lifecycle_fuel_cost_after_tax** (Float) - Required - Life cycle fuel cost [$] - **year_one_fuel_cost_before_tax** (Float) - Required - Year one fuel cost, before tax [$] - **year_one_fuel_cost_after_tax** (Float) - Required - Year one fuel cost, after tax [$] - **lifecycle_per_unit_prod_om_costs** (Float) - Required - Life cycle production-based O&M cost [$] ### Response #### Success Response Returns a dictionary with the listed Boiler results keys populated with values. #### Response Example { "size_mmbtu_per_hour": 10.0, "annual_fuel_consumption_mmbtu": 2000.0 } ``` -------------------------------- ### REopt.add_chp_results Function Source: https://nrel.github.io/REopt.jl/dev/reopt/outputs This function adds CHP (Combined Heat and Power) results to the REopt model. It provides keys for CHP system capacities, fuel consumption, energy production series, cost calculations, and thermal load distributions. All series and annual outputs represent average annual values over the analysis period due to degradation considerations. ```APIDOC ## REopt.add_chp_results ### Description The REopt.add_chp_results function integrates CHP system results into the REopt optimization model, outputting details on power and thermal production, fuel usage, and economic metrics for the CHP system including supplemental firing. ### Method Function ### Endpoint REopt.add_chp_results ### Parameters No input parameters specified in documentation. ### Results #### CHP Results Keys - **size_kw** (Float) - Required - Power capacity size of the CHP system [kW] - **size_supplemental_firing_kw** (Float) - Required - Power capacity of CHP supplementary firing system [kW] - **annual_fuel_consumption_mmbtu** (Float) - Required - Fuel consumed in a year [MMBtu] - **annual_electric_production_kwh** (Float) - Required - Electric energy produced in a year [kWh] - **annual_thermal_production_mmbtu** (Float) - Required - Thermal energy produced in a year (not including curtailed thermal) [MMBtu] - **electric_production_series_kw** (Array) - Required - Electric power production time-series array [kW] - **electric_to_grid_series_kw** (Array) - Required - Electric power exported time-series array [kW] - **electric_to_storage_series_kw** (Array) - Required - Electric power to charge the battery storage time-series array [kW] - **electric_to_load_series_kw** (Array) - Required - Electric power to serve the electric load time-series array [kW] - **thermal_to_storage_series_mmbtu_per_hour** (Array) - Required - Thermal power to TES (HotThermalStorage) time-series array [MMBtu/hr] - **thermal_curtailed_series_mmbtu_per_hour** (Array) - Required - Thermal power wasted/unused/vented time-series array [MMBtu/hr] - **thermal_to_load_series_mmbtu_per_hour** (Array) - Required - Thermal power to serve the heating load time-series array [MMBtu/hr] - **thermal_to_steamturbine_series_mmbtu_per_hour** (Array) - Required - Thermal (steam) power to steam turbine time-series array [MMBtu/hr] - **year_one_fuel_cost_before_tax** (Float) - Required - Cost of fuel consumed by the CHP system in year one, before tax [$] - **year_one_fuel_cost_after_tax** (Float) - Required - Cost of fuel consumed by the CHP system in year one, after tax - **lifecycle_fuel_cost_after_tax** (Float) - Required - Present value of cost of fuel consumed by the CHP system, after tax [$] - **year_one_standby_cost_before_tax** (Float) - Required - CHP standby charges in year one, before tax [$] - **year_one_standby_cost_after_tax** (Float) - Required - CHP standby charges in year one, after tax - **lifecycle_standby_cost_after_tax** (Float) - Required - Present value of all CHP standby charges, after tax. - **thermal_production_series_mmbtu_per_hour** (Array) - Required - Thermal power production time-series array [MMBtu/hr] - **initial_capital_costs** (Float) - Required - Initial capital costs of the CHP system, before incentives [$] ### Response #### Success Response Returns a dictionary with the listed CHP results keys populated with values. #### Response Example { "size_kw": 1000.0, "annual_fuel_consumption_mmbtu": 5000.0 } ``` === COMPLETE CONTENT === This response contains all available snippets from this library. No additional content exists. Do not make further requests.