Never allow zero Generator. fuel_intercept_gal_per_hr ?

[NLaws]

In the reo/validators.py we have the following logic:

m, b = Generator.default_fuel_burn_rate(gen["min_kw"] + gen["existing_kw"])
if gen["fuel_slope_gal_per_kwh"] == 0:
    gen["fuel_slope_gal_per_kwh"] = m
if gen["fuel_intercept_gal_per_hr"] == 0:
    gen["fuel_intercept_gal_per_hr"] = b

In the nested_inputs.py the default fuel_slope_gal_per_kwh is 0.076 and the default fuel_intercept_gal_per_hr is 0.0, which implies that when a user does not provide either input value we only modify the fuel_intercept_gal_per_hr (and that if the user provides 0.0 for the fuel_intercept_gal_per_hr that we make it non-zero). @Bill-Becker Is this the behavior that you expect? If not what should we be doing? (Perhaps both default values for fuel_slope_gal_per_kwh and fuel_intercept_gal_per_hr should be "funny" numbers and then we can update their values in the validator using the above logic by replacing if <value> == 0.0 with if <value> == "funny number"?)

[Bill-Becker]

@NLaws I honestly never really touched the Generator logic in the process of adding CHP. I think we should sync up the methodologies to the extent possible for efficiency/fuel burn, including the defaults and inputs processing, for V2. I would change the current input of fuel_slope_gal_per_kwh and fuel_intercept_gal_per_hr to electric_efficiency_full_load and electric_efficiency_half_load (as we do for CHP) because electric efficiency is a much more intuitive input. I would also promote changing the y-intercept fuel burn to be a function of size and make the default electric_efficiency_full_load = electric_efficiency_half_load constant so that the default y-intercept term is zero because it's slow to model the y-intercept.

[NLaws]

@Bill-Becker I have not observed solve time issues with the current y-intercept method for the diesel generator fuel burn curve:

@constraint(m, FuelBurnCon[t in p.TechsInClass["GENERATOR"], ts in p.TimeStep],
    m[:dvFuelUsage][t,ts]  == p.TimeStepScaling * (
        p.FuelBurnSlope[t] * p.ProductionFactor[t,ts] * m[:dvRatedProduction][t,ts] +
        p.FuelBurnYInt[t] * m[:binTechIsOnInTS][t,ts] )
)

Have you seen solve time issues for just the diesel generator or is it just an issue when the y-intercept is a decision variable (as for CHP)?

@constraint(m, CHPFuelBurnCon[t in p.CHPTechs, ts in p.TimeStep],
    m[:dvFuelUsage][t,ts]  == p.TimeStepScaling * (
        m[:dvFuelBurnYIntercept][t,ts] +
        p.ProductionFactor[t,ts] * p.FuelBurnSlope[t] * m[:dvRatedProduction][t,ts]
    )
)

@constraint(m, CHPFuelBurnYIntCon[t in p.CHPTechs, ts in p.TimeStep],
    p.FuelBurnYIntRate[t] * m[:dvSize][t] - m[:NewMaxSize][t] * (1-m[:binTechIsOnInTS][t,ts])  <= m[:dvFuelBurnYIntercept][t,ts]
)

[Bill-Becker]

Right, it's only for the CHP-style Y-int.

[NLaws]

addressed in v2 with https://github.com/NREL/REopt_Lite_API/pull/263/commits/9fd56496fcf959145da0e4e6aaeddf243c916fa0