The test performs simulations for all upgrades defined in https://github.com/NatLabRockies/resstock/blob/develop/project_national/sdr_upgrades_amy2018.yml over a minimal buildstock created to provide coverage for all upgrades and options defined in the yaml. This ensures all the upgrades and options are tested in at least one building. However, the current size of the minimal buildstock is 42 buildings, and there are 34 upgrades. With baseline included that equals 1470 simulations which can take upto 4 hours in CI.
Here is an idea to make this better.
The 42 buildings are selected so that we have at least one building for all of the upgrades and options defined. This could be simplified such that we use a different set of buildings for each upgrade - so instead of 35 * 42 sims - we could do 42 sims for baseline + say on avg 5 buildings per upgrade = 42 + 34*5 = 212 simulations. In the same ballpark as the integration test that uses 250 building baseline run.
While the idea is rather simple, implementation and downstream impacts are quite challenging. BuildStockBatch doesn't allow passing multiple buildstock.csv to be used for each upgrade. All of the buildstockbatch postprocessing currently assumes same set of buildings are run in each upgrade - baring inapplicable buildings.
The least disruptive fix could be something like adding a series of ci-only column to the sdr_minimal_buildstock.csv -- "Include in upgrade1", "include_in_upgrade2" etc -- and inject "Include in upgrade1|True" top level applicability logic to all upgrades. Or something along those lines.
The test performs simulations for all upgrades defined in https://github.com/NatLabRockies/resstock/blob/develop/project_national/sdr_upgrades_amy2018.yml over a minimal buildstock created to provide coverage for all upgrades and options defined in the yaml. This ensures all the upgrades and options are tested in at least one building. However, the current size of the minimal buildstock is 42 buildings, and there are 34 upgrades. With baseline included that equals 1470 simulations which can take upto 4 hours in CI.
Here is an idea to make this better.
The 42 buildings are selected so that we have at least one building for all of the upgrades and options defined. This could be simplified such that we use a different set of buildings for each upgrade - so instead of 35 * 42 sims - we could do 42 sims for baseline + say on avg 5 buildings per upgrade = 42 + 34*5 = 212 simulations. In the same ballpark as the integration test that uses 250 building baseline run.
While the idea is rather simple, implementation and downstream impacts are quite challenging. BuildStockBatch doesn't allow passing multiple buildstock.csv to be used for each upgrade. All of the buildstockbatch postprocessing currently assumes same set of buildings are run in each upgrade - baring inapplicable buildings.
The least disruptive fix could be something like adding a series of ci-only column to the sdr_minimal_buildstock.csv -- "Include in upgrade1", "include_in_upgrade2" etc -- and inject "Include in upgrade1|True" top level applicability logic to all upgrades. Or something along those lines.