Some zones sometimes reopen while using shadow pricing simulation

[jpn--]

Describe the bug
In investigating #815, I discovered that the shadow pricing simulation algorithm sometimes re-opens zones that were previously closed.

To Reproduce
Steps to reproduce the behavior:

• Use main branch @ff3e96b.
• Run full size prototype mtc extended model with 100% household.
• Trace hh id 1098914
• Compare shadow_price_utility_adjustment column from trace/school_location/i*/sample/interaction_sample/alternatives-*.csv

Expected behavior
Once the shadow price simulation algorithm closes a zone, it should stay closed. Re-opening a closed zone probably doesn't completely void the results here -- in all cases I observe, it then gets closed again on the next iteration, but it probably prolongs convergence as workers or students will certainly just re-oversubscribe that zone again.

[dhensle]

The simulation-based constraint algorithm selects people to re-simulate based on the probability of sprice = 1 - (desired_share / modeled_share), but the "shadow price" of the zone set to -999 is calculated as np.where((sprice <= 1 + percent_tolerance / 100), -999, 0). (See it in the code here.)

Notice how the percent tolerance shows up in turning the zone on-and-off, but not in the selection of people to re-simulate. I think this is the source of the discrepancy.... In other words, I can have a 5% tolerance, with a zone that has 100 enrollment. If 103 students select that zone, the sprice is > 1 and I can choose people from the zone to re-simulate, but it is within the percent tolerance and the shadow price is -999. If the 3% probability selection just so happens to choose more than 3 people to resimulate, then the zone will open back up in the next iteration.

If my logic is correct here, I see a couple ways forward:

1. Just leave it as is. I don't think this is necessarily a "bug" but rather a side effect of having a tolerance.
2. Update the sampling logic to say that if people are within the tolerance for the zone, they will just remain there.

cc: @aletzdy, @jfdman

[bettinardi]

I like option 2

[joecastiglione]

I agree that option 2 seems cleaner, and consistent with the purpose of having the tolerance setting in the first place. Joe

…

On Thu, Feb 29, 2024 at 7:06 AM Alex Bettinardi ***@***.***> wrote: I like option 2 — Reply to this email directly, view it on GitHub <#820 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABDVIH5UHEOEGAWC2PE5NBLYV5BXJAVCNFSM6AAAAABD2XBTBCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNZRGMZTSMJSGY> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>