New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
correct CDAP #116
Comments
According to the documentation for applyModelForExtraHhMembers in mtctm2.abm.ctramp HouseholdCoordinatedDailyActivityPatternModel.java choices for extra household members should be made according to a table of fixed proportionate probabilities based on person type:
Why does it do this rather than choosing activities for the extra members by applying the individual utilities, ignoring the interaction utilities? It is easy for me to implement this either way... |
The short answer is because that is how the model was estimated. Here are the hard wired CDAP 6+ persons proportions from MTC TM1. The rows are person types (the 2nd row is person type 1) and the columns are M, N, H. We should move this into a input CSV table. public final double[][] CDAP_6_PLUS_PROPORTIONS = { |
We implemented CDAP in a slightly different way than described in the first comment. See https://github.com/UDST/activitysim/wiki/Project-Meeting-2016.09.23 |
SANDAG model has the same proportions. It seems in each sub array, the numbers are the probabilities of choosing M, N, and H for a 6 and plus household member? Does this mean the code handles up to 14-person household (5+ 9 brackets in the array)? What does {0.0, 0.0, 0.0} represent? |
I believe that all extra household members are treated the same, and the choice depends only on ptype. So this is a three column (M. N, H) array indexed by ptype. The first row is blank because the array is zero-based index and the first ptype is 1. And so it will handle households of any size. |
@toliwaga this makes sense to me now. Thanks. |
I am running the full dataset and cdap completed successfully in just under an hour.
|
this is great. We will be able to run this quite quickly then once we thread and/or distribute. |
I made a tweak that reduce runtime from 60 mins to 52 minutes. That is probably good enough for now. |
CDAP is supposed to only consider the interactions between up to 5 HH members and then apply some additional utility terms after that. We will review the MTC TM1 code and UECs and correct this. CDAP also currently loops by HHs but this is inefficient.
We will likely re-implement it as a series of batch vectorized calculations:
The key is to organize the problem into a series of batch table operations
The text was updated successfully, but these errors were encountered: