Add electrification profiles to change table

[jenhagg]

Purpose

Define/implement new schema for electrification profiles and scaling by grid/zone.

What the code is doing

Define one new function add_electrification which can specify profiles and scaling for supported types: currently these are building and transportation. If specifying scaling factors by zone, the zone name is checked against the current grid object. There isn't yet validation for the profile name/version, but I'll add that if the general approach looks good.

Depending on expected usage patterns, the schema could also be "inverted" by mapping profiles to zones and scaling factors, but I think either way has trade offs in how easy it is to specify the change table and how much code is required to aggregate the profiles during the preparation phase.

Testing

New unit tests.

Usage Example/Visuals

The tests are the best usage example. The full schema will look like:

{
    "building": {
        "grid": [scale_factors],
        "zone": { zone_name: [scale_factors], ... }
    },
    "transportation": {...}
}

Where the scale_factors dict has the structure:

{profile_name_and_version_1: s_1, profile_name_and_version_2: s_2, ...} 

And 0 <= s_i <= 1

Time estimate

20 min

[rouille]

Not sure I understand why you constrain the scaling factors to be less than 1

[danielolsen]

Not sure I understand why you constrain the scaling factors to be less than 1

We can't change more than 100% of e.g. fossil fuel heating to electrified heating, and the profiles that we're getting from the collaborators represent 100% conversion of fossil end uses to 100% of one particular technology. See #574 for more details.

[BainanXia]

Not sure I understand why you constrain the scaling factors to be less than 1

The scaling factor here is essentially adoption rate.

[danielolsen]

I like the examples shown in the tests. Being able to scale across the whole grid is a nice addition!

[rouille]

I like the examples shown in the tests. Being able to scale across the whole grid is a nice addition!

Should we implement it for other methods?

[danielolsen]

Should we implement it for other methods?

Eventually, yeah. There are lots of potential improvements to the ChangeTable logic/interface.

[danielolsen]

Looking at this, I realize that I specified this feature incompletely. I think we need one more layer of nesting in the change table schema, because we have multiple end uses within each of buildings and transportation. So we would go from [buildings/transportation][zone/grid][technology] = adoption to [buildings/transportation][zone/grid][end_use][technology] = adoption. Currently we have:

info = {
    "New York City": {"advanced_heat_pump_v2": 0.7},
    "Western North Carolina": {
        "standard_heat_pump_v1": 0.5,
        "advanced_heat_pump_v2": 0.5,
    },
}

But I think we need something more like:

info = {
    "New York City": {
        "res_heating": {"advanced_heat_pump_v2": 0.7},
        "com_hot_water": {"advanced_heat_pump_v2": 0.7},
        "res_cooking": {"mid_efficiency": 0.5, "high_efficiency": 0.3},
    },
    "Western North Carolina": {
        "res_heating": {
            "standard_heat_pump_v1": 0.5,
            "advanced_heat_pump_v2": 0.5,
        },
    },
}

Adoption rates for various technologies still need to sum to less than one for a given (class, zone, end use). Sorry for the bad spec.

[rouille]

Nice