SANDAG abm3 v15.0.0 contributions

[i-am-sijia]

This PR brings in updates from SANDAG ABM3's latest release v15.0.0.

ABM3 v15.0.0 is based off of a pre- orca removal version of ActivitySim, therefore its contributions are manually reviewed and cherry-picked so that only relevant changes are brought into the latest main ActivitySim. After reviewing, I found two noteworthy changes:

1. Fixing zone sampler bug in disagg accessibility. This was to fix "a crash where the data frame of candidate MAZs to sample from was empty."
2. Loading skims into shared memory [1][2]. "This was put in place to share skims in memory so that we don’t have to read them again each time we run a special market model (cross border, airport, visitor, etc.)"

This PR brings in # 1 and leaves out # 2.

(I accidentally pushed a commit directly to the activitysim/main, I've reverted that and reapplied it here...)

[jpn--]

This looks fine, I will merge it.

Do we need to also do the second thing (loading skims into shared memory)? That one looks less easy peasy to review and merge, but I don't want to leave SANDAG still needing to be on a fork if we can avoid it.

[i-am-sijia]

Do we need to also do the second thing (loading skims into shared memory)? That one looks less easy peasy to review and merge, but I don't want to leave SANDAG still needing to be on a fork if we can avoid it.

SANDAG suggested no because 1) they implemented it for non-sharrow only, 2) it's a SANDAG-only use case, at least for now, 3) when switching to v1.3.x, the skim loading time for them is expected to be 5-7 minutes. @bhargavasana@aber-sandag

I think this could become relevant and beneficial to other agencies, if they also use ActivitySim for other demand sectors and do not want to repeatedly load skims. Ideally a skim manager would be suitable to solve this for both non-sharrow and sharrow. For now, I can create a separate PR with SANDAG's solution.

[i-am-sijia]

This PR brings in updates from SANDAG ABM3's latest release v15.0.0.

ABM3 v15.0.0 is based off of a pre- orca removal version of ActivitySim, therefore its contributions are manually reviewed and cherry-picked so that only relevant changes are brought into the latest main ActivitySim. After reviewing, I found two noteworthy changes:

1. Fixing zone sampler bug in disagg accessibility. This was to fix "a crash where the data frame of candidate MAZs to sample from was empty."
2. Loading skims into shared memory [1][2]. "This was put in place to share skims in memory so that we don’t have to read them again each time we run a special market model (cross border, airport, visitor, etc.)"

This PR brings in # 1 and leaves out # 2.

(I accidentally pushed a commit directly to the activitysim/main, I've reverted that and reapplied it here...)

[jpn--]

This looks fine, I will merge it.

Do we need to also do the second thing (loading skims into shared memory)? That one looks less easy peasy to review and merge, but I don't want to leave SANDAG still needing to be on a fork if we can avoid it.

[i-am-sijia]

Do we need to also do the second thing (loading skims into shared memory)? That one looks less easy peasy to review and merge, but I don't want to leave SANDAG still needing to be on a fork if we can avoid it.

SANDAG suggested no because 1) they implemented it for non-sharrow only, 2) it's a SANDAG-only use case, at least for now, 3) when switching to v1.3.x, the skim loading time for them is expected to be 5-7 minutes. @bhargavasana@aber-sandag

I think this could become relevant and beneficial to other agencies, if they also use ActivitySim for other demand sectors and do not want to repeatedly load skims. Ideally a skim manager would be suitable to solve this for both non-sharrow and sharrow. For now, I can create a separate PR with SANDAG's solution.

[i-am-sijia]

This PR brings in updates from SANDAG ABM3's latest release v15.0.0.

ABM3 v15.0.0 is based off of a pre- orca removal version of ActivitySim, therefore its contributions are manually reviewed and cherry-picked so that only relevant changes are brought into the latest main ActivitySim. After reviewing, I found two noteworthy changes:

1. Fixing zone sampler bug in disagg accessibility. This was to fix "a crash where the data frame of candidate MAZs to sample from was empty."
2. Loading skims into shared memory [1][2]. "This was put in place to share skims in memory so that we don’t have to read them again each time we run a special market model (cross border, airport, visitor, etc.)"

This PR brings in # 1 and leaves out # 2.

(I accidentally pushed a commit directly to the activitysim/main, I've reverted that and reapplied it here...)

[jpn--]

This looks fine, I will merge it.

Do we need to also do the second thing (loading skims into shared memory)? That one looks less easy peasy to review and merge, but I don't want to leave SANDAG still needing to be on a fork if we can avoid it.

[i-am-sijia]

Do we need to also do the second thing (loading skims into shared memory)? That one looks less easy peasy to review and merge, but I don't want to leave SANDAG still needing to be on a fork if we can avoid it.

SANDAG suggested no because 1) they implemented it for non-sharrow only, 2) it's a SANDAG-only use case, at least for now, 3) when switching to v1.3.x, the skim loading time for them is expected to be 5-7 minutes. @bhargavasana@aber-sandag

I think this could become relevant and beneficial to other agencies, if they also use ActivitySim for other demand sectors and do not want to repeatedly load skims. Ideally a skim manager would be suitable to solve this for both non-sharrow and sharrow. For now, I can create a separate PR with SANDAG's solution.

[i-am-sijia]

This PR brings in updates from SANDAG ABM3's latest release v15.0.0.

ABM3 v15.0.0 is based off of a pre- orca removal version of ActivitySim, therefore its contributions are manually reviewed and cherry-picked so that only relevant changes are brought into the latest main ActivitySim. After reviewing, I found two noteworthy changes:

1. Fixing zone sampler bug in disagg accessibility. This was to fix "a crash where the data frame of candidate MAZs to sample from was empty."
2. Loading skims into shared memory [1][2]. "This was put in place to share skims in memory so that we don’t have to read them again each time we run a special market model (cross border, airport, visitor, etc.)"

This PR brings in # 1 and leaves out # 2.

(I accidentally pushed a commit directly to the activitysim/main, I've reverted that and reapplied it here...)

[jpn--]

This looks fine, I will merge it.

Do we need to also do the second thing (loading skims into shared memory)? That one looks less easy peasy to review and merge, but I don't want to leave SANDAG still needing to be on a fork if we can avoid it.

[i-am-sijia]

Do we need to also do the second thing (loading skims into shared memory)? That one looks less easy peasy to review and merge, but I don't want to leave SANDAG still needing to be on a fork if we can avoid it.

SANDAG suggested no because 1) they implemented it for non-sharrow only, 2) it's a SANDAG-only use case, at least for now, 3) when switching to v1.3.x, the skim loading time for them is expected to be 5-7 minutes. @bhargavasana@aber-sandag

I think this could become relevant and beneficial to other agencies, if they also use ActivitySim for other demand sectors and do not want to repeatedly load skims. Ideally a skim manager would be suitable to solve this for both non-sharrow and sharrow. For now, I can create a separate PR with SANDAG's solution.

[i-am-sijia]

This PR brings in updates from SANDAG ABM3's latest release v15.0.0.

ABM3 v15.0.0 is based off of a pre- orca removal version of ActivitySim, therefore its contributions are manually reviewed and cherry-picked so that only relevant changes are brought into the latest main ActivitySim. After reviewing, I found two noteworthy changes:

1. Fixing zone sampler bug in disagg accessibility. This was to fix "a crash where the data frame of candidate MAZs to sample from was empty."
2. Loading skims into shared memory [1][2]. "This was put in place to share skims in memory so that we don’t have to read them again each time we run a special market model (cross border, airport, visitor, etc.)"

This PR brings in # 1 and leaves out # 2.

(I accidentally pushed a commit directly to the activitysim/main, I've reverted that and reapplied it here...)

[jpn--]

This looks fine, I will merge it.

Do we need to also do the second thing (loading skims into shared memory)? That one looks less easy peasy to review and merge, but I don't want to leave SANDAG still needing to be on a fork if we can avoid it.

[i-am-sijia]

Do we need to also do the second thing (loading skims into shared memory)? That one looks less easy peasy to review and merge, but I don't want to leave SANDAG still needing to be on a fork if we can avoid it.

SANDAG suggested no because 1) they implemented it for non-sharrow only, 2) it's a SANDAG-only use case, at least for now, 3) when switching to v1.3.x, the skim loading time for them is expected to be 5-7 minutes. @bhargavasana@aber-sandag

I think this could become relevant and beneficial to other agencies, if they also use ActivitySim for other demand sectors and do not want to repeatedly load skims. Ideally a skim manager would be suitable to solve this for both non-sharrow and sharrow. For now, I can create a separate PR with SANDAG's solution.

[i-am-sijia]

This PR brings in updates from SANDAG ABM3's latest release v15.0.0.

ABM3 v15.0.0 is based off of a pre- orca removal version of ActivitySim, therefore its contributions are manually reviewed and cherry-picked so that only relevant changes are brought into the latest main ActivitySim. After reviewing, I found two noteworthy changes:

1. Fixing zone sampler bug in disagg accessibility. This was to fix "a crash where the data frame of candidate MAZs to sample from was empty."
2. Loading skims into shared memory [1][2]. "This was put in place to share skims in memory so that we don’t have to read them again each time we run a special market model (cross border, airport, visitor, etc.)"

This PR brings in # 1 and leaves out # 2.

(I accidentally pushed a commit directly to the activitysim/main, I've reverted that and reapplied it here...)

[jpn--]

This looks fine, I will merge it.

Do we need to also do the second thing (loading skims into shared memory)? That one looks less easy peasy to review and merge, but I don't want to leave SANDAG still needing to be on a fork if we can avoid it.

[i-am-sijia]

Do we need to also do the second thing (loading skims into shared memory)? That one looks less easy peasy to review and merge, but I don't want to leave SANDAG still needing to be on a fork if we can avoid it.

SANDAG suggested no because 1) they implemented it for non-sharrow only, 2) it's a SANDAG-only use case, at least for now, 3) when switching to v1.3.x, the skim loading time for them is expected to be 5-7 minutes. @bhargavasana@aber-sandag

I think this could become relevant and beneficial to other agencies, if they also use ActivitySim for other demand sectors and do not want to repeatedly load skims. Ideally a skim manager would be suitable to solve this for both non-sharrow and sharrow. For now, I can create a separate PR with SANDAG's solution.

[i-am-sijia]

This PR brings in updates from SANDAG ABM3's latest release v15.0.0.

ABM3 v15.0.0 is based off of a pre- orca removal version of ActivitySim, therefore its contributions are manually reviewed and cherry-picked so that only relevant changes are brought into the latest main ActivitySim. After reviewing, I found two noteworthy changes:

1. Fixing zone sampler bug in disagg accessibility. This was to fix "a crash where the data frame of candidate MAZs to sample from was empty."
2. Loading skims into shared memory [1][2]. "This was put in place to share skims in memory so that we don’t have to read them again each time we run a special market model (cross border, airport, visitor, etc.)"

This PR brings in # 1 and leaves out # 2.

(I accidentally pushed a commit directly to the activitysim/main, I've reverted that and reapplied it here...)

[jpn--]

This looks fine, I will merge it.

Do we need to also do the second thing (loading skims into shared memory)? That one looks less easy peasy to review and merge, but I don't want to leave SANDAG still needing to be on a fork if we can avoid it.

[i-am-sijia]

Do we need to also do the second thing (loading skims into shared memory)? That one looks less easy peasy to review and merge, but I don't want to leave SANDAG still needing to be on a fork if we can avoid it.

SANDAG suggested no because 1) they implemented it for non-sharrow only, 2) it's a SANDAG-only use case, at least for now, 3) when switching to v1.3.x, the skim loading time for them is expected to be 5-7 minutes. @bhargavasana@aber-sandag

I think this could become relevant and beneficial to other agencies, if they also use ActivitySim for other demand sectors and do not want to repeatedly load skims. Ideally a skim manager would be suitable to solve this for both non-sharrow and sharrow. For now, I can create a separate PR with SANDAG's solution.

[i-am-sijia]

This PR brings in updates from SANDAG ABM3's latest release v15.0.0.

ABM3 v15.0.0 is based off of a pre- orca removal version of ActivitySim, therefore its contributions are manually reviewed and cherry-picked so that only relevant changes are brought into the latest main ActivitySim. After reviewing, I found two noteworthy changes:

1. Fixing zone sampler bug in disagg accessibility. This was to fix "a crash where the data frame of candidate MAZs to sample from was empty."
2. Loading skims into shared memory [1][2]. "This was put in place to share skims in memory so that we don’t have to read them again each time we run a special market model (cross border, airport, visitor, etc.)"

This PR brings in # 1 and leaves out # 2.

(I accidentally pushed a commit directly to the activitysim/main, I've reverted that and reapplied it here...)

[jpn--]

This looks fine, I will merge it.

Do we need to also do the second thing (loading skims into shared memory)? That one looks less easy peasy to review and merge, but I don't want to leave SANDAG still needing to be on a fork if we can avoid it.

[i-am-sijia]

Do we need to also do the second thing (loading skims into shared memory)? That one looks less easy peasy to review and merge, but I don't want to leave SANDAG still needing to be on a fork if we can avoid it.

SANDAG suggested no because 1) they implemented it for non-sharrow only, 2) it's a SANDAG-only use case, at least for now, 3) when switching to v1.3.x, the skim loading time for them is expected to be 5-7 minutes. @bhargavasana@aber-sandag

I think this could become relevant and beneficial to other agencies, if they also use ActivitySim for other demand sectors and do not want to repeatedly load skims. Ideally a skim manager would be suitable to solve this for both non-sharrow and sharrow. For now, I can create a separate PR with SANDAG's solution.