RSGInc/SOABM

Clarification on Network Setting Capacity Factors

bettinardi opened this issue · 5 comments

Item 14 on page - https://github.com/RSGInc/SOABM/wiki/Networks-and-Zone-Data - describes that the user can edit the period capacity factors in network settings. The table at the bottom of the page implies the same: https://github.com/RSGInc/SOABM/wiki/Networks-and-Zone-Data#time-of-day-periods-and-link-capacities

However, the defined function on line 640 of - https://github.com/RSGInc/SOABM/blob/master/template/scripts/SOABM.py

  • setLinkCapacityTODFactors, which is called on line 1771 seems to show that these capacity factors are hard wired and will be overwritten even if the users changes these in Visum.

@bstabler - can I please get a clarification on this. And if the code is overwritting the user setting, can we please have the code updated to no longer set these factors.

I believe the fix is trusting that the user has to establish these factors in Visum in the input file and so we would be removing or commenting out lines - 645-646. Changing 647 to get the capacity factors from Visum, and then getting rid of 652-656.

You are correct. The fix is trusting that the user has to establish these factors in Visum in the input file and so we would be removing or commenting out lines - 645-646. Changing 647 to get the capacity factors from Visum, and then getting rid of 652-656. The user's guide describes the setup before the SANDAG VDFs.

I just added a link to the capacity lookup table under item 14 in the wiki. The new code that is needed is below.

  capFac = Visum.Net.GetAttValue("TOD_FACTOR_" + tp.upper())

This function does not exist - Visum.Net.GetAttValue
Implementing this as:
attName = "Network\TOD_FACTOR_" + tp.upper()
capFac = VisumPy.helpers.GetMulti(Visum.Net.Links, attName)

VisumPy.helpers.SetMulti(Visum.Net.Links, "vdf_int_cap", numpy.multiply(numpy.array(vdf_int_cap), numpy.array(capFac)))

Why are you pulling a network attribute off the links?
This value is stored in Network settings, not on the links

@binnympaul's solution will work - it uses a link indirect attribute back up to the Network level to get the attribute.

This issue has been addressed under Contingency work