🐛 Bug: 0 MAZ -MAZ demand

[Ennazus]

Describe the bug

The EMME MAZ assignment is showing 0 demand for MAZ-MAZ auto trips for all time periods. Are any MAZ-MAZ trips assigned? Is it just a summarization problem in EMME?

More investigation needed.

Progress:

- [ ] Sufficient information provided
- [ ] Cause identified/found
- [ ] Test developed/identified 
- [ ] Approach determined 
- [ ] Test passes

## To Reproduce

Steps to reproduce the behavior:
Run any model run, look at the EMME project logbook

### Failing tests

- [ ] No applicable test failed, need to create.
- [ ] other...specify

### Triggering line of code

### Thoughts on resolution

### Full stack trace

### Environment

Operating system:
Context (conda, jupyter, etc):
Environment (e.g. output from `conda list`):

[i-am-sijia]

CT-RAMP writes out MAZ auto demand OMX files, as below.

highway_maz_ctramp_output_file = "ctramp_output/auto_{period}_MAZ_AUTO_{number}_{period}.omx"

These OMX are copied from ./ctramp_output to ./demand_matrice/highway/maz_demand during each global iteration for MAZ auto assignment. Suffix _{iter} are appended to the file names.

demand_file = "demand_matrices/highway/maz_demand/auto_{period}_MAZ_AUTO_{number}_{period}_{iter}.omx"
[[highway.maz_to_maz.demand_county_groups]]
    number = 1
    counties = ["San Francisco", "San Mateo", "Santa Clara"]
[[highway.maz_to_maz.demand_county_groups]]
    number = 2
    counties = ["Alameda", "Contra Costa"]
[[highway.maz_to_maz.demand_county_groups]]
    number = 3
    counties = ["Solano", "Napa", "Sonoma", "Marin"]

auto_AM_MAZ_AUTO_1_AM_2.omx means global iteration 2's AM MAZ auto demand for county group 1.

Looking at the ctramp outputs, these matrices are all zero, I will look into why.

Also, tm2py now creates trip tables directly from ctramp trip list (done in PR #126). MAZ auto demand might already be included in the TAZ auto demand?

tm2py/tm2py/components/demand/prepare_demand.py

Lines 226 to 227 in 68c1836

	def prepare_household_demand(self):
	"""Prepares highway and transit household demand matrices from trip lists produced by CT-RAMP."""

[i-am-sijia]

Looking at the ctramp outputs, these matrices are all zero, I will look into why.

It seems to be because -appendSkims is set to false in the ctramp command that writes out trip tables:

java -Xmx320g -cp "%CLASSPATH%" -Dproject.folder=%PROJECT_DIRECTORY% com.pb.mtctm2.abm.application.MTCTM2TripTables mtctm2 -iteration %iteration% -sampleRate %sampleRate% -appendSkims FALSE

If it's set to true, ctramp should write out MAZ auto demand for trips shorter than 0.5 miles.

[Ennazus]

Cool thanks @i-am-sijia . I'll make myself a task to test this, you can consider it done from your end.

[i-am-sijia]

@Ennazus I think we still need to look into this:

Also, tm2py now creates trip tables directly from ctramp trip list (done in PR #126). MAZ auto demand might already be included in the TAZ auto demand?

So that we do not end up assigning MAZ demand (trips within 0.5 miles) twice.

[Ennazus]

Thanks @i-am-sijia. Is what you're saying that the MAZ-MAZ demand from the trip list- gets aggregated to TAZ-TAZ, so we end up assigning it to TAZ-TAZ?

[i-am-sijia]

Yes, I think that's what happening by looking at the code. I think we need to either:

• Option 1: Keep -appendSkims as false. And write out MAZ trip tables from the trip list in a tm2py function, OR
• Option 2: Set -appendSkims as true. And filter out MAZ trips from the trip list in the tm2py method that generates TAZ trip tables.

@DavidOry @AshishKuls might have additional insights.

[i-am-sijia]

Hi @Ennazus, we are gonna go ahead and implement the first option. I think it will take 16 hours for @lachlan-git to implement and 2 hours for me to review. If it sounds ok to you, please respond with a 👍

[i-am-sijia]

Hi @Ennazus, I wanted to give you a quick update on this task. As we proceed with separating the MAZ demand from the TAZ demand, we've noticed the following and we're including them in the fixes:

1. The function that prepares ctramp trip list into TAZ OD matrices uses hardcoded integer codes for travel modes, which is not very legible. We are adding Enums to improve code legibility. We are also adding comments to that function to improve code readability.
2. The TAZ OD matrices are written out as OMX files and then read into EMME for assignment, which could be inefficient, we are exploring storing them directly in EMME.
3. The MAZ assignment uses shortest path assignment with distance caps and is not resource intensive. We will get rid of the county-group segmentation that was inherited from TM2.1.
4. To correctly link MAZ demand to the MAZ emme nodes, we will make MAZ assignment use the ID crosswalk that Yue produces in PR Add MAZ data model #216.