Make global constants available to interaction-based model expressions

[Copilot]

Constants defined in constants.yaml were unavailable in location choice, destination choice, and tour scheduling specs. Those models evaluate utilities via interaction_simulate.eval_interaction_utilities(), which used only the caller-supplied locals_d, unlike simulate.eval_utilities() / assign.local_utilities() which already merge in the global constants.

Changes

• activitysim/core/interaction_simulate.py: seed the evaluation locals with state.get_global_constants() before applying the caller's locals_d, so model-supplied locals (model CONSTANTS, skims, df) still win on name collisions. Because this is the single entry point used by interaction_sample, interaction_simulate, and interaction_sample_simulate, it covers all the affected models, in both the sharrow and non-sharrow paths.

# avoid altering caller's passed-in locals_d parameter (they may be looping)# global constants are always available, but can be overridden by locals_dlocals_d= {**state.get_global_constants(), **(locals_dor {})}

• activitysim/core/test/test_interaction_simulate.py: tests that a constant from constants.yaml resolves in an interaction spec expression, and that locals_d takes precedence over a same-named global constant.

With this, a spec expression such as distance_km * KM_TO_MILE resolves in destination/location choice and tour scheduling specs using a single system-wide constant.

Note

Constants now shadow chooser columns of the same name in interaction specs (resolvers precede DataFrame columns in fast_eval). This matches existing behavior in simulate.eval_utilities, but is worth a look during review.

• FixesGlobal constants not available in all models #1015

[jpn--]

@copilot your PR is failing the checks. Run the pre-commit checks on your code, do not attempt to fix black formatting errors without actually calling black to fix them.

[dhensle]

Made the following additions to the work copilot did:

• Removed redundant call of get_global_constants in trip destination and simulate.py
• Added line in preprocessor test and simple simulate test to use a global constant
• Added explicit global constants in sharrow flow and added test to ensure they get added

@jpn-- this is ready for your final review.

[Copilot]

Constants defined in constants.yaml were unavailable in location choice, destination choice, and tour scheduling specs. Those models evaluate utilities via interaction_simulate.eval_interaction_utilities(), which used only the caller-supplied locals_d, unlike simulate.eval_utilities() / assign.local_utilities() which already merge in the global constants.

Changes

• activitysim/core/interaction_simulate.py: seed the evaluation locals with state.get_global_constants() before applying the caller's locals_d, so model-supplied locals (model CONSTANTS, skims, df) still win on name collisions. Because this is the single entry point used by interaction_sample, interaction_simulate, and interaction_sample_simulate, it covers all the affected models, in both the sharrow and non-sharrow paths.

# avoid altering caller's passed-in locals_d parameter (they may be looping)# global constants are always available, but can be overridden by locals_dlocals_d= {**state.get_global_constants(), **(locals_dor {})}

• activitysim/core/test/test_interaction_simulate.py: tests that a constant from constants.yaml resolves in an interaction spec expression, and that locals_d takes precedence over a same-named global constant.

With this, a spec expression such as distance_km * KM_TO_MILE resolves in destination/location choice and tour scheduling specs using a single system-wide constant.

Note

Constants now shadow chooser columns of the same name in interaction specs (resolvers precede DataFrame columns in fast_eval). This matches existing behavior in simulate.eval_utilities, but is worth a look during review.

• FixesGlobal constants not available in all models #1015

[jpn--]

@copilot your PR is failing the checks. Run the pre-commit checks on your code, do not attempt to fix black formatting errors without actually calling black to fix them.

[dhensle]

Made the following additions to the work copilot did:

• Removed redundant call of get_global_constants in trip destination and simulate.py
• Added line in preprocessor test and simple simulate test to use a global constant
• Added explicit global constants in sharrow flow and added test to ensure they get added

@jpn-- this is ready for your final review.

[Copilot]

Constants defined in constants.yaml were unavailable in location choice, destination choice, and tour scheduling specs. Those models evaluate utilities via interaction_simulate.eval_interaction_utilities(), which used only the caller-supplied locals_d, unlike simulate.eval_utilities() / assign.local_utilities() which already merge in the global constants.

Changes

• activitysim/core/interaction_simulate.py: seed the evaluation locals with state.get_global_constants() before applying the caller's locals_d, so model-supplied locals (model CONSTANTS, skims, df) still win on name collisions. Because this is the single entry point used by interaction_sample, interaction_simulate, and interaction_sample_simulate, it covers all the affected models, in both the sharrow and non-sharrow paths.

# avoid altering caller's passed-in locals_d parameter (they may be looping)# global constants are always available, but can be overridden by locals_dlocals_d= {**state.get_global_constants(), **(locals_dor {})}

• activitysim/core/test/test_interaction_simulate.py: tests that a constant from constants.yaml resolves in an interaction spec expression, and that locals_d takes precedence over a same-named global constant.

With this, a spec expression such as distance_km * KM_TO_MILE resolves in destination/location choice and tour scheduling specs using a single system-wide constant.

Note

Constants now shadow chooser columns of the same name in interaction specs (resolvers precede DataFrame columns in fast_eval). This matches existing behavior in simulate.eval_utilities, but is worth a look during review.

• FixesGlobal constants not available in all models #1015

[jpn--]

@copilot your PR is failing the checks. Run the pre-commit checks on your code, do not attempt to fix black formatting errors without actually calling black to fix them.

[dhensle]

Made the following additions to the work copilot did:

• Removed redundant call of get_global_constants in trip destination and simulate.py
• Added line in preprocessor test and simple simulate test to use a global constant
• Added explicit global constants in sharrow flow and added test to ensure they get added

@jpn-- this is ready for your final review.

[Copilot]

Constants defined in constants.yaml were unavailable in location choice, destination choice, and tour scheduling specs. Those models evaluate utilities via interaction_simulate.eval_interaction_utilities(), which used only the caller-supplied locals_d, unlike simulate.eval_utilities() / assign.local_utilities() which already merge in the global constants.

Changes

• activitysim/core/interaction_simulate.py: seed the evaluation locals with state.get_global_constants() before applying the caller's locals_d, so model-supplied locals (model CONSTANTS, skims, df) still win on name collisions. Because this is the single entry point used by interaction_sample, interaction_simulate, and interaction_sample_simulate, it covers all the affected models, in both the sharrow and non-sharrow paths.

# avoid altering caller's passed-in locals_d parameter (they may be looping)# global constants are always available, but can be overridden by locals_dlocals_d= {**state.get_global_constants(), **(locals_dor {})}

• activitysim/core/test/test_interaction_simulate.py: tests that a constant from constants.yaml resolves in an interaction spec expression, and that locals_d takes precedence over a same-named global constant.

With this, a spec expression such as distance_km * KM_TO_MILE resolves in destination/location choice and tour scheduling specs using a single system-wide constant.

Note

Constants now shadow chooser columns of the same name in interaction specs (resolvers precede DataFrame columns in fast_eval). This matches existing behavior in simulate.eval_utilities, but is worth a look during review.

• FixesGlobal constants not available in all models #1015

[jpn--]

@copilot your PR is failing the checks. Run the pre-commit checks on your code, do not attempt to fix black formatting errors without actually calling black to fix them.

[dhensle]

Made the following additions to the work copilot did:

• Removed redundant call of get_global_constants in trip destination and simulate.py
• Added line in preprocessor test and simple simulate test to use a global constant
• Added explicit global constants in sharrow flow and added test to ensure they get added

@jpn-- this is ready for your final review.

[Copilot]

Constants defined in constants.yaml were unavailable in location choice, destination choice, and tour scheduling specs. Those models evaluate utilities via interaction_simulate.eval_interaction_utilities(), which used only the caller-supplied locals_d, unlike simulate.eval_utilities() / assign.local_utilities() which already merge in the global constants.

Changes

• activitysim/core/interaction_simulate.py: seed the evaluation locals with state.get_global_constants() before applying the caller's locals_d, so model-supplied locals (model CONSTANTS, skims, df) still win on name collisions. Because this is the single entry point used by interaction_sample, interaction_simulate, and interaction_sample_simulate, it covers all the affected models, in both the sharrow and non-sharrow paths.

# avoid altering caller's passed-in locals_d parameter (they may be looping)# global constants are always available, but can be overridden by locals_dlocals_d= {**state.get_global_constants(), **(locals_dor {})}

• activitysim/core/test/test_interaction_simulate.py: tests that a constant from constants.yaml resolves in an interaction spec expression, and that locals_d takes precedence over a same-named global constant.

With this, a spec expression such as distance_km * KM_TO_MILE resolves in destination/location choice and tour scheduling specs using a single system-wide constant.

Note

Constants now shadow chooser columns of the same name in interaction specs (resolvers precede DataFrame columns in fast_eval). This matches existing behavior in simulate.eval_utilities, but is worth a look during review.

• FixesGlobal constants not available in all models #1015

[jpn--]

@copilot your PR is failing the checks. Run the pre-commit checks on your code, do not attempt to fix black formatting errors without actually calling black to fix them.

[dhensle]

Made the following additions to the work copilot did:

• Removed redundant call of get_global_constants in trip destination and simulate.py
• Added line in preprocessor test and simple simulate test to use a global constant
• Added explicit global constants in sharrow flow and added test to ensure they get added

@jpn-- this is ready for your final review.

[Copilot]

Constants defined in constants.yaml were unavailable in location choice, destination choice, and tour scheduling specs. Those models evaluate utilities via interaction_simulate.eval_interaction_utilities(), which used only the caller-supplied locals_d, unlike simulate.eval_utilities() / assign.local_utilities() which already merge in the global constants.

Changes

• activitysim/core/interaction_simulate.py: seed the evaluation locals with state.get_global_constants() before applying the caller's locals_d, so model-supplied locals (model CONSTANTS, skims, df) still win on name collisions. Because this is the single entry point used by interaction_sample, interaction_simulate, and interaction_sample_simulate, it covers all the affected models, in both the sharrow and non-sharrow paths.

# avoid altering caller's passed-in locals_d parameter (they may be looping)# global constants are always available, but can be overridden by locals_dlocals_d= {**state.get_global_constants(), **(locals_dor {})}

• activitysim/core/test/test_interaction_simulate.py: tests that a constant from constants.yaml resolves in an interaction spec expression, and that locals_d takes precedence over a same-named global constant.

With this, a spec expression such as distance_km * KM_TO_MILE resolves in destination/location choice and tour scheduling specs using a single system-wide constant.

Note

Constants now shadow chooser columns of the same name in interaction specs (resolvers precede DataFrame columns in fast_eval). This matches existing behavior in simulate.eval_utilities, but is worth a look during review.

• FixesGlobal constants not available in all models #1015

[jpn--]

@copilot your PR is failing the checks. Run the pre-commit checks on your code, do not attempt to fix black formatting errors without actually calling black to fix them.

[dhensle]

Made the following additions to the work copilot did:

• Removed redundant call of get_global_constants in trip destination and simulate.py
• Added line in preprocessor test and simple simulate test to use a global constant
• Added explicit global constants in sharrow flow and added test to ensure they get added

@jpn-- this is ready for your final review.

[Copilot]

Constants defined in constants.yaml were unavailable in location choice, destination choice, and tour scheduling specs. Those models evaluate utilities via interaction_simulate.eval_interaction_utilities(), which used only the caller-supplied locals_d, unlike simulate.eval_utilities() / assign.local_utilities() which already merge in the global constants.

Changes

• activitysim/core/interaction_simulate.py: seed the evaluation locals with state.get_global_constants() before applying the caller's locals_d, so model-supplied locals (model CONSTANTS, skims, df) still win on name collisions. Because this is the single entry point used by interaction_sample, interaction_simulate, and interaction_sample_simulate, it covers all the affected models, in both the sharrow and non-sharrow paths.

# avoid altering caller's passed-in locals_d parameter (they may be looping)# global constants are always available, but can be overridden by locals_dlocals_d= {**state.get_global_constants(), **(locals_dor {})}

• activitysim/core/test/test_interaction_simulate.py: tests that a constant from constants.yaml resolves in an interaction spec expression, and that locals_d takes precedence over a same-named global constant.

With this, a spec expression such as distance_km * KM_TO_MILE resolves in destination/location choice and tour scheduling specs using a single system-wide constant.

Note

Constants now shadow chooser columns of the same name in interaction specs (resolvers precede DataFrame columns in fast_eval). This matches existing behavior in simulate.eval_utilities, but is worth a look during review.

• FixesGlobal constants not available in all models #1015

[jpn--]

@copilot your PR is failing the checks. Run the pre-commit checks on your code, do not attempt to fix black formatting errors without actually calling black to fix them.

[dhensle]

Made the following additions to the work copilot did:

• Removed redundant call of get_global_constants in trip destination and simulate.py
• Added line in preprocessor test and simple simulate test to use a global constant
• Added explicit global constants in sharrow flow and added test to ensure they get added

@jpn-- this is ready for your final review.

[Copilot]

Constants defined in constants.yaml were unavailable in location choice, destination choice, and tour scheduling specs. Those models evaluate utilities via interaction_simulate.eval_interaction_utilities(), which used only the caller-supplied locals_d, unlike simulate.eval_utilities() / assign.local_utilities() which already merge in the global constants.

Changes

• activitysim/core/interaction_simulate.py: seed the evaluation locals with state.get_global_constants() before applying the caller's locals_d, so model-supplied locals (model CONSTANTS, skims, df) still win on name collisions. Because this is the single entry point used by interaction_sample, interaction_simulate, and interaction_sample_simulate, it covers all the affected models, in both the sharrow and non-sharrow paths.

# avoid altering caller's passed-in locals_d parameter (they may be looping)# global constants are always available, but can be overridden by locals_dlocals_d= {**state.get_global_constants(), **(locals_dor {})}

• activitysim/core/test/test_interaction_simulate.py: tests that a constant from constants.yaml resolves in an interaction spec expression, and that locals_d takes precedence over a same-named global constant.

With this, a spec expression such as distance_km * KM_TO_MILE resolves in destination/location choice and tour scheduling specs using a single system-wide constant.

Note

Constants now shadow chooser columns of the same name in interaction specs (resolvers precede DataFrame columns in fast_eval). This matches existing behavior in simulate.eval_utilities, but is worth a look during review.

• FixesGlobal constants not available in all models #1015

[jpn--]

@copilot your PR is failing the checks. Run the pre-commit checks on your code, do not attempt to fix black formatting errors without actually calling black to fix them.

[dhensle]

Made the following additions to the work copilot did:

• Removed redundant call of get_global_constants in trip destination and simulate.py
• Added line in preprocessor test and simple simulate test to use a global constant
• Added explicit global constants in sharrow flow and added test to ensure they get added

@jpn-- this is ready for your final review.