Space per worker assumption external assumption update

[akselx]

This PR is focused on:

1. updating space per worker assumptions to current (2023) levels
2. making future assumptions to space per worker levels in forecast years (focused on the period 2025-2035)

It leverages research on space per worker trends nationally and locally to create updated adjuster files. The adjuster files are already used by the model system to apply cross-sectional detail to the regional space per worker constants.

The PR updates the existing function sqft_per_job in variables.py in the following ways:

• It departs from the existing version by applying adjusters to just office buildings. The existing version applied adjusters to all buildings.
• To allow for flexibility in time specificity in passed adjusters, it checks for the existence of adjusters for a particular simulation year. If present it uses that. If not it looks for the generic, time-invariant adjuster column.
• To allow for adjusters to be optionally applied to non-office buildings - more similar to the legacy version - the function now checks for a yaml flag, and potentially adjusts with the time invariant or 2010 values, if multiple are available. This current bandaid fix means we include some cross-sectional adjuster detail, adding more subregional granularity, while not making strong assumptions about the future direction in space per workers for the non-office building stock. A future version could allow for building-type specific adjusters.

Other changes

• To test effects on office space development of reduced space per worker assumptions requires vacancy rates to drop below a certain threshold. Insofar as the development pipeline has considerable amounts of space, a runtime filtering option was added to drop pipeline projects based on criteria set in a separate yaml file. This was included in this PR.

---

• To see the specific tasks where the Asana app for GitHub is being used, see below:
  • https://app.asana.com/0/0/1206790754906785
  • https://app.asana.com/0/0/1205838651518353

[theocharides]

This is exciting stuff! I commented in the files but some overarching comments & questions below:

• Do you want the metrics changes in this PR, or are they in another branch that'll be reviewed/merged?
• For all of the configs and the code that aren't going to be used in PBA50+, I think removing them would make the main code a lot clearer, but the script/exogenous folder does seem like a good place to memorialize unused items.
• Very cool pipeline editing option in the face of uncertainty. Do we want to do pipeline editing during runtime? I keep coming back to the idea that having pipeline versions in the inputs that we can select in run_setup.yaml and doing all editing upfront makes things much more transparent and we can then just share those inputs easily. Also cuts down on code complexity. I know this is a larger conversation with @drewlevitt and his work.
• If there are updates to the run setup file, do you mind specifying it in the run setup files checked into the repo? Then I'll make sure to pull those changes through to subsequent runs.
• I'm wondering if optional flags in run setup make it harder at all to tell what's in a run or now. I'm thinking a flag for either using the exogenous sqft per job file or not would be useful when comparing runs to be able to quickly understand what file is being used. Same for the other files that setup the run setup for doing diffing.
• Then perhaps we carry that same logic through to the sqft per job code as well, where there are run setup flags for the sqft per job adjuster setting, the telecommute adjuster setting and the exogenous flag that are either used or not used by the very useful sqft per job logic.

[theocharides]

Hi @akselx - just taking a look before our 10am to see how it's going. I think the code that's not being used by the strategy hasn't been pulled to a sub-folder yet (additional elcm configs, model variables, etc.), or just let me know if you have different thoughts on that too.

[theocharides]

I think the same applies to the pipeline filtering code as well, if we want to move to making pipeline edits in the inputs rather than at run time as an overall direction of the code.

Happy to discuss these in a meeting though too for other opinions if you'd like!

[theocharides]

Did we figure out if the metrics code is okay to be here?

[theocharides]

For the sqft_per_job variable code block- what were your thoughts though on not having the code be dependent on the presence of years within the input, but rather just selecting a set of adjusters to use based on the file name in run_setup, which is related to what we want to do in that run (calibration adjuster, telecommute strategy adjuster, external force, etc.). Smaller question was about removing the copying of the variable at the beginning and just setting it with the logic.

Thinking of ways to simplify reading the code since its 125 or so lines right now.

[akselx]

Did we figure out if the metrics code is okay to be here?

From all appearances, what shows up as green and "new" is already in main.

[akselx]

For the sqft_per_job variable code block- what were your thoughts though on not having the code be dependent on the presence of years within the input, but rather just selecting a set of adjusters to use based on the file name in run_setup, which is related to what we want to do in that run (calibration adjuster, telecommute strategy adjuster, external force, etc.). Smaller question was about removing the copying of the variable at the beginning and just setting it with the logic.

Thinking of ways to simplify reading the code since its 125 or so lines right now.

I think you are saying it is preferable to just require the years, or not, as a matter of course, and just have the model fail if a year is not present in the adjuster file?

[theocharides]

A few notes on where we're at:

• We're keeping the additional accessibility variables- sounds good.
• We're keeping the pipeline filtering functionality- maybe not something we want to be doing at run time long term, but it's not being used currently in any case.
• We've removed the optional run setup argument for housing element- I'm realizing we chose yesterday to maintain optional run setup arguments for pipeline additions (if they can be commented out, deleted, etc. in a given run setup file). In that case, it seems like the same thing could apply to the sqft per job adjuster files as well, where we use default files if certain files aren't specified. I like the explicit options but if folks prefer this we can and should do it across the board!
• We're not using an alternative elcm specification, but looks like we'll keep that functionality in the code too.

For the adjusters logic question, I think yes if it helps to make the logic more direct and is covered by the input specification / expected input columns already. Same for the small item of removing the .copy() line and using the one variable name in the function. But they're not requirements to run or anything; it seems like we may want to merge instead of putting time into that!

[akselx]

A few notes on where we're at:

* We're keeping the additional accessibility variables- sounds good.

* We're keeping the pipeline filtering functionality- maybe not something we want to be doing at run time long term, but it's not being used currently in any case.

* We've removed the optional run setup argument for housing element- I'm realizing we chose yesterday to maintain optional run setup arguments for pipeline additions (if they can be commented out, deleted, etc. in a given run setup file). In that case, it seems like the same thing could apply to the sqft per job adjuster files as well, where we use default files if certain files aren't specified. I like the explicit options but if folks prefer this we can and should do it across the board!

* We're not using an alternative elcm specification, but looks like we'll keep that functionality in the code too.

For the adjusters logic question, I think yes if it helps to make the logic more direct and is covered by the input specification / expected input columns already. Same for the small item of removing the .copy() line and using the one variable name in the function. But they're not requirements to run or anything; it seems like we may want to merge instead of putting time into that!

• removed the .copy() line and just added a return value from each if block
• disambiguated adjuster files so there is now an explicit file name in the yaml for each of
• sqft_per_job_telecommute_file, sqft_per_job_adj_file and exog_sqft_per_job_adj_file. This makes it clearer when needing the standard adjusters which file to use.
• Removed the checking for a particular simulation year. We trust the data instead, and if there is an issue we fix on the data side. Makes for simpler, more readable code.
• Adjusted the standard adjuster block so it behaves like the telecommuting block which was being used as a proxy for the no project treatment. Now the standard adjusters no project can turn off EN7 and still achieve that behavior. This does lose the single-year, time invariant adjuster possibility, though seems we haven't been using that for a while in practice.
• Consistent with this, I copied the NP adjusters out of plan strategy and into the adjusters folder - which means it is not a repo file again. Treats them more like k-factors and less like policy factors.
• Perhaps the exogenous adjusters should really be the ones to not be in adjusters - but they are still not quite policy.