Closed jblake59 closed 6 years ago
Proposal 1 Leave "Opt-H2KFoundation" as-is (handles B, W, C or S) and add a second foundation option named "Opt-H2KFoundationSlabOrCrawl" that handles only Slab-On-Grade or Crawlspace foundations. This approach allows existing choice files to run without change but allows new choice files to create two sets of upgrades -- one for "basements" (i.e., foundations that are designated as either B or W) and another for Slab/Crawl foundations (S or C -- code currently deals with both Slabs and Crawlspaces together because XML structure is the same!).
Note: The following potential issue may arise from this approach:
Proposal 2 Modify "Opt-H2KFoundation" so it handles all foundation types (i.e., B, W, C or S). This is a fairly significant change to the Ruby script that involves:
Note that this still restricts us to one foundation upgrade specification and it would not be obvious (and sometimes impossible) to choose one configuration that effects all foundations as desired!
Proposal 1 implemented.
The current foundation upgrade option allows for:
Note that the tag 1 code in "Opt-H2KFoundation" is a concatenation of the configuration type (e.g., BCIN_1) and one of the following suffixes:
Example: BCIN_1_B This is documented in tag "Opt-H2KFoundation" of the HOT2000.options file and in HTAP/doc/HTAP-input-and-output.md.
It does NOT:
This issue is primarily concerned with resolving the first restriction.