Update Geometry Foundation Type to be Based on RECS

[afontani]

Pull Request Description

This pull request updates the Geometry Foundation Type.tsv from the "Building Foundation Design Handbook" published in 1988 to RECS 2009. The new TSV has dependencies on IECC Climate and Moisture regions and Vintage ACS.

Companion PRs:

• resstock-estimation #63
• resstock-estimation #73

Previous Data Source Documentation

TSV previously based on ORNL's "Building Foundation Design Handbook" published in 1988.

New Data Source

The new data source for Geometry Building Type.tsv is RECS 2009. Since the spatial restructure (PR #416), this housing characteristic is a bit out of date because the locations were redefined. As a result, this pull request also fixes the spatial issue created by PR #416.

Dependencies:

• ASHRAE IECC Climate Zone 2004
• Geometry Building Type RECS
• Vintage ACS

Assumptions

• All mobile homes have Pier and Beam foundations.
• Multi-family cannot have Pier and Beam and Heated Basements.
• Single-Family Attached buildings cannot have Pier and Beam foundations.
• Foundation types are the same for each building type except for mobile homes and the applicable options.
• If no foundation type specified, then sample has Pier and Beam foundation.
• RECS has a quirk where MF 5+ units always have foundation type fields set to N/A, whereas MF2-4 unit fields are allowed to have foundation types. Because we need to assume a foundation type for ground-floor MF units, we use the lumped SFD+SFA+MF2-4 distributions for MF5+.
• A non-trivial percentage of MF units have neither basement, nor slab, nor crawl, which we map to pier and beam (aka open crawlspace). This seems unrealistic, but could represent MF units that are above parking garages or retail space, so we assume it is reasonable to model them as pier and beam open crawlspaces.

Updates to Geometry Garage.tsv

Geometry Garage.tsv is updated in the pull request. Now that pier and beam foundations can now be sampled as a foundation type, the BuildExistingModel measure does not allow for pier and beam foundations with garages. As a result, a Geometry Foundation Type dependency was added to the Geometry Garage.tsv.

A Geometry Foundation Type dependency is added to the project_testing/Geometry Garage.tsv.

Assumptions:

• Pier and beam foundations cannot have an attached garage
• Due to low sample counts and the need to split out pier and beam foundations, the samples with Crawl, Heated basement, Slab, and Unheated basement foundation types are lumped together.

Checklist

Not all may apply:

• Unit tests have been added or updated
• All rake tasks have been run, and pass
• Documentation has been modified appropriately
• Any new options are added to project_testing
• project_testing runs without any failures
• No unexpected regression test changes
• All tests are passing (green) on circleci
• The changelog has been updated appropriately
• This branch is up-to-date with master

For more information on how to perform these checklist items, see the documentation's Advanced Tutorial.

[ejhw]

See assumptions I added above. Would be nice to add these to the tsv files as well.

• RECS has a quirk where MF 5+ units always have foundation type fields set to N/A, whereas MF2-4 unit fields are allowed to have foundation types. Because we need to assume a foundation type for ground-floor MF units, we use the lumped SFD+SFA+MF2-4 distributions for MF5+.
• A non-trivial percentage of MF units have neither basement, nor slab, nor crawl, which we map to pier and beam (aka open crawlspace). This seems unrealistic, but could represent MF units that are above parking garages or retail space, so we assume it is reasonable to model them as pier and beam open crawlspaces.

[ejhw]

👍

[afontani]

@ejhw: Not a problem. Addressed 3415bd2.

[shorowit]

"A non-trivial percentage of MF units have neither basement, nor slab, nor crawl, which we map to pier and beam (aka open crawlspace). This seems unrealistic, but could represent MF units that are above parking garages or retail space, so we assume it is reasonable to model them as pier and beam open crawlspaces."

MF units, or MF buildings? If the former, wouldn't this be more likely to represent MF units above other MF units?

With respect to units over parking garages, it might be a good idea to create a new foundation type option for this. You could map it to pier and beam for now, but with the eventual switchover to HPXML, there is an "other non-freezing space" that could be used to represent units over parking garages. As indicated it is modeled as floating with outdoor temperature but with a minimum of 40 deg-F.

[ejhw]

Thanks @shorowit , that's a good question. I had been interpreting the fields for the building containing the household's dwelling unit, but I think you are right that it is for the unit itself.

From the codebook:

Name	Description
CELLAR	Basement in housing unit
CRAWL	Housing unit over a crawl space
CONCRETE	Housing unit over a concrete slab

We don't know the location of the unit in the building, which makes it tough to use these fields for MF. Also slabs wouldn't necessarily be on the ground floor.

Once we move to single-unit MF modeling it might become easier to use these fields, but at least for now we still need distributions for foundation types for MF2-4 and MF5+ buildings

Options:

1. Use SFD+SFA distributions for SFD, SFA, MF2-4, and MF5+, and disallow pier&beam for MF2-4 and MF5+
   

2. Use SFD+SFA distributions for SFD, SFA. Use MF2-4 distributions for MF2-4 and MF5+ and disallow pier&beam for MF2-4 and MF5+. MF2-4 doesn't really have enough samples (only 722) to support us using it alone though when we have 3 dependencies.
   

So I vote option 1 until we move to single-unit MF modeling and implement unit-specific tsvs.

Re: parking garages, unfortunately I think we won't have data to differentiate these from units over other units. Perhaps the future RECS MF survey will help with that.

cc @aspeake for awareness

[ejhw]

@afontani I implemented option 1 since the logic was fresh in my mind: https://github.com/NREL/resstock-estimation/pull/63

[ejhw]

@shorowit do you want a chance to review what I implemented (https://github.com/NREL/resstock-estimation/pull/63)? Are you good with Option 1 above? Thanks again for raising the question.

[shorowit]

@ejhw No, I don't need to review it. I'll defer to your judgment on how you decided to address my comment.