Make NumApplyUpgradeOptions dynamic

[lixiliu]

Description

NumApplyUpgradeOptions is a constant parameter default to 25. It would be great to make the parameter dynamically determined based on actual upgrades in a yaml file, especially as upgrade runs are getting more complicated to specify (requiring many options) and more numerous generally and we don't always remember to modify this parameter for large upgrade runs, especially when it's buried deep inside the measure too.

resstock/measures/ApplyUpgrade/resources/constants.rb

Lines 3 to 5 in 8173412

	class Constants
	def self.NumApplyUpgradeOptions
	return 25

Progress

• Validation check in bsb: adding validation of the number of options in the ApplyUpgrade measure buildstockbatch#330
• Dynamically update measure.xml

[afontani]

@nmerket : Thoughts?

[nmerket]

I think it's a good idea, but my understanding was that we needed to have that constant because the measure.xml needs to be updated as well and there's not a way to make that automatic. Maybe @joseph-robertson remembers...

[joseph-robertson]

Yes @nmerket that is correct. You can see in the linked measure.xml that arguments go up to option_25_xxx. Perhaps we could update measure.xml files on the fly or something...

[nmerket]

How does that measure.xml get updated these days? In the olden days of PAT, we would just open the in the OpenStudio GUI application. Is there a command on the CLI that updates measures now?

[joseph-robertson]

By running openstudio tasks.rb update_measures. See here. It calls a command on the CLI: https://github.com/NREL/resstock/blob/develop/tasks.rb#L84-L87.

[shorowit]

If you just want to update the single measure's xml: openstudio measure -u measures/ApplyUpgrade

[nmerket]

Rather than trying to edit files that are committed in the repository at runtime we should take the approach in NREL/buildstockbatch#329 and make a validator on buildstockbatch that give a helpful error message about how to update the measure.

[ekpresent]

I think even just something that would catch the issue before running would be a big improvement over the status quo. "Upgrade x has y options, and you are currently configured for z max. See documentation for how to change this." or some more succinct version. I'd rather have that ( NREL/buildstockbatch#329) sooner than this (#1005) a few months later.

[joseph-robertson]

@nmerket @ekpresent So implement NREL/buildstockbatch#329 now and leave this issue for possible implementation later?

[nmerket]

I think so. I have a PR open for this that I need to polish up NREL/buildstockbatch#330, but I think we're just about there.

[afontani]

To close let's just add documentation around how to do this on HPC (Eagle). @nmerket to improve Wiki (https://github.com/NREL/buildstockbatch/wiki/Adding-Options-to-the-ApplyUpgrade-measure)

[nmerket]

I added some instructions to the wiki about how to run the upgrade measure command on Eagle via Singularity.