abyrd
commented
6 years ago First observation, on filtering. The log messages above come from the filtering performed around FastRaptorWorker L345. This pre-filtering does not work by changing the scenario-specific TransitNetwork, it creates arrays of subsets of patterns that are internal to the FastRaptorWorker. The TransitNetwork itself has two fields, hasFrequencies and hasSchedules, which the raptor search uses to decide whether to perform the schedule search and/or schedule randomization for frequency trips. Those fields are never updated, so if filtering removes all frequencies or schedules those fields give a false positive. This should not lead to incorrect results, but it causes a lot of unnecessary computation.
Second observation: even without this filtering the input data contains no frequencies. The TriMet GTFS doesn't even have a frequencies.txt. So somehow hasFrequencies is getting incorrectly set to "true". The fact that the MC draws are happening even with no modifications means that the fault cannot (solely) lie in the modification application code.
When debugging #290, I created a test project with only a single add-trip-pattern modification. It has a single timetable that has exact-times enabled. I can perform a single point analysis using this modification with no problem. But strangely the worker logs show:
So the scenario includes no frequency patterns at all, yet the worker is performing Monte Carlo draws, presumably based on the presence of this modification (which should not add any frequency based trips). When exact-times is disabled, we see these messages:
So the frequency trip exists now but the behavior is the same, Monte Carlo simulation happens. Interestingly even with the modification completely removed I see:
So it looks like the exact times check box works, creating non-frequency trips, but the worker still does MC draws even when there are no frequency trips in the network.