Skip to content

Conversation

@joseph-robertson
Copy link
Collaborator

@joseph-robertson joseph-robertson commented Jan 6, 2026

Pull Request Description

This PR fixes several issues:

  • We previously weren't checking unit multipliers for batteries and vehicles
  • We were assuming the Resilience output type should change based on unit multiplier
  • Some kind of floating point issue was causing weird resilience hour values for batteries
  • We were adding extra battery losses (and without incorporating unit multipliers) to critical load
  • Vehicles were missing multiplying eff_discharge_power by unit_multiplier

Checklist

Not all may apply:

  • Schematron validator (EPvalidator.sch) has been updated
  • Sample files have been added/updated (openstudio tasks.rb update_hpxmls)
  • Tests have been added/updated (e.g., HPXMLtoOpenStudio/tests/test*.rb and/or workflow/tests/test*.rb)
  • Documentation has been updated
  • Changelog has been updated
  • openstudio tasks.rb update_measures has been run
  • No unexpected changes to simulation results of sample files

Comment on lines -55 to -57
elsif hpxml_bldg.vehicles.size > 0
# Same as battery issue above
return
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe this should have been removed in #2113.

@joseph-robertson joseph-robertson changed the title Fix for batteries when using unit multipliers Fix for batteries and vehicles when using unit multipliers Jan 6, 2026
@joseph-robertson
Copy link
Collaborator Author

It's possible there is something else going on with using unit multipliers with batteries. The discrepancies can be pretty non trivial. @jmaguire1 is going to ask @rchintala13. It's possible we should be adjusting the number cells in series and not just the number of strings in parallel.

@joseph-robertson joseph-robertson marked this pull request as ready for review January 7, 2026 22:39
Copy link
Contributor

@shorowit shorowit left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Some initial comments/thoughts.

vars = ['Other Equipment Electricity Energy']
keys = resilience.variables.select { |v| v[2] == vars[0] }.map { |v| v[1] }
batt_loss = get_report_variable_data_timeseries(keys, vars, UnitConversions.convert(1.0, 'J', 'kWh'), 0, resilience_frequency)
batt_loss = batt_loss.map { |x| x * unit_multiplier }
Copy link
Contributor

@shorowit shorowit Jan 8, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, I don't see the unit multiplier used anywhere else in the reporting measure. It's possible that this situation is unique, but I wonder if we can switch from the output variable we're currently using to the equivalent output meter that already incorporates the unit multiplier?

More specifically, I noticed that we use an output meter here for the battery losses when calculating the end use, but then use an output variable here for the battery losses when calculating the resilience metric. Maybe the latter just needs to be like the former?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See bugfix explanation in #2140 (comment).

Comment on lines 2039 to 2042
return i / Float(ts_per_hr) if batt_soc_kwh <= 0
return i / Float(ts_per_hr) if batt_soc_kwh.abs <= Constants::Small
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't understand this change. If it's a large negative number, it no longer returns? Why is it not batt_soc_kwh <= Constants::Small if it's just a floating point issue?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I also don't see any diffs for CI results, why is that?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oops, I don't know why I put the .abs on there.

Can batt_soc_kwh even be negative?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh, right, it surely can't. So the code was really just checking for zero SOC, but being extra safe by looking for <= 0.

@shorowit shorowit moved this from Triage to In progress in OpenStudio-HPXML Jan 16, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

Status: In progress

Development

Successfully merging this pull request may close these issues.

3 participants