Provide more flexibility for defining mandatory schedule specifications.

[danielsclint]

#273. This change require defining tour scheduling specs specifically in the mandatory_tour_scheduling.yaml. The code still hard-codes the 'univ' value, and additional flexibility should be added in the future. This is step one of probably a couple of steps to unwind the hard-coded values in this section of the code.

SPEC:
work: tour_scheduling_work.csv
school: tour_scheduling_school.csv
univ: tour_scheduling_university.csv

Review Criteria Responses

1. Does it contain all the required elements, including a runnable example, documentation, and tests?
   The example scripts have been updated so the examples and tests complete. It's unclear how the documentation should be updated for this change. Few of the internal workings of model settings are well-documented, and it seems like a large discussion (or work effort) is needed to standardize this across the models.

2. Does it implement good methods (i.e. is it consistent with good practices in travel modeling)?
   Yes, this change improves the flexibility of the ActivitySim framework allowing it be implemented in more locations.

3. Are the runtimes reasonable and does it provide documentation justifying this claim?
   This change will have no material change on the model run time. This code change replaces hard-coded values with a set of user-defined parameters.

4. Does it include non-Python code, such as C/C++? If so, does it compile on any OS and are compilation instructions included?
   No. This is a Python-only change.

5. Is it licensed with the ActivitySim license that allows the code to be freely distributed and modified and includes attribution so that the ‘provenance’ of the code can be tracked? Does it include an official release of ownership from the funding agency if applicable?
   This work was done under contract to ARC, and, presumably, ARC is providing the changes without any additional licensing beyond the existing ActivitySim licensing.

6. Does it appropriately interact with the data pipeline (i.e. it doesn't create new ways of managing data)?
   This change does not impact the data pipeline.

7. Does it include regression tests to enable checking that consistent results will be returned when updates are made to the framework?
   No regression testing has been done. The code change removes a hard-coded value in the Python code with a set of user-defined variables. If the user specifies the same values as the previously hard-coded values, they should get the same results. The unit tests seem to confirm this assertion.

8. Does it include sufficient test coverage and test data for existing and proposed features?
   The test configuration files were modified to use the newest features.

9. Any other comments or suggestions for improving the developer experience?
   The documentation is still being built out, so it is difficult to understand where and how to add new documentation into the existing framework. Some documentation should be consistent across all models (as is the case with this change), so a standard would need to be set by the larger team or asserted by me.

[coveralls]

Coverage decreased (-0.02%) to 86.123% when pulling c9f890e on danielsclint:ft_schedule_flex into 7b57c94 on ActivitySim:master.

[danielsclint]

@bstabler, I updated the original PR comment with the some additional documentation and answered the "Review Criteria" questions. This PR works, but as I note in the comment, it probably should be followed-up with a few more code enhancements to make the assertion of the 'univ' trips more flexible.

[bstabler]

This looks good and we accept the PR. I changed the target to the develop branch so we can merge features here before merging (releasing) to master.

[danielsclint]

#273. This change require defining tour scheduling specs specifically in the mandatory_tour_scheduling.yaml. The code still hard-codes the 'univ' value, and additional flexibility should be added in the future. This is step one of probably a couple of steps to unwind the hard-coded values in this section of the code.

SPEC:
work: tour_scheduling_work.csv
school: tour_scheduling_school.csv
univ: tour_scheduling_university.csv

Review Criteria Responses

1. Does it contain all the required elements, including a runnable example, documentation, and tests?
   The example scripts have been updated so the examples and tests complete. It's unclear how the documentation should be updated for this change. Few of the internal workings of model settings are well-documented, and it seems like a large discussion (or work effort) is needed to standardize this across the models.

2. Does it implement good methods (i.e. is it consistent with good practices in travel modeling)?
   Yes, this change improves the flexibility of the ActivitySim framework allowing it be implemented in more locations.

3. Are the runtimes reasonable and does it provide documentation justifying this claim?
   This change will have no material change on the model run time. This code change replaces hard-coded values with a set of user-defined parameters.

4. Does it include non-Python code, such as C/C++? If so, does it compile on any OS and are compilation instructions included?
   No. This is a Python-only change.

5. Is it licensed with the ActivitySim license that allows the code to be freely distributed and modified and includes attribution so that the ‘provenance’ of the code can be tracked? Does it include an official release of ownership from the funding agency if applicable?
   This work was done under contract to ARC, and, presumably, ARC is providing the changes without any additional licensing beyond the existing ActivitySim licensing.

6. Does it appropriately interact with the data pipeline (i.e. it doesn't create new ways of managing data)?
   This change does not impact the data pipeline.

7. Does it include regression tests to enable checking that consistent results will be returned when updates are made to the framework?
   No regression testing has been done. The code change removes a hard-coded value in the Python code with a set of user-defined variables. If the user specifies the same values as the previously hard-coded values, they should get the same results. The unit tests seem to confirm this assertion.

8. Does it include sufficient test coverage and test data for existing and proposed features?
   The test configuration files were modified to use the newest features.

9. Any other comments or suggestions for improving the developer experience?
   The documentation is still being built out, so it is difficult to understand where and how to add new documentation into the existing framework. Some documentation should be consistent across all models (as is the case with this change), so a standard would need to be set by the larger team or asserted by me.

[coveralls]

Coverage decreased (-0.02%) to 86.123% when pulling c9f890e on danielsclint:ft_schedule_flex into 7b57c94 on ActivitySim:master.

[danielsclint]

@bstabler, I updated the original PR comment with the some additional documentation and answered the "Review Criteria" questions. This PR works, but as I note in the comment, it probably should be followed-up with a few more code enhancements to make the assertion of the 'univ' trips more flexible.

[bstabler]

This looks good and we accept the PR. I changed the target to the develop branch so we can merge features here before merging (releasing) to master.

[danielsclint]

#273. This change require defining tour scheduling specs specifically in the mandatory_tour_scheduling.yaml. The code still hard-codes the 'univ' value, and additional flexibility should be added in the future. This is step one of probably a couple of steps to unwind the hard-coded values in this section of the code.

SPEC:
work: tour_scheduling_work.csv
school: tour_scheduling_school.csv
univ: tour_scheduling_university.csv

Review Criteria Responses

1. Does it contain all the required elements, including a runnable example, documentation, and tests?
   The example scripts have been updated so the examples and tests complete. It's unclear how the documentation should be updated for this change. Few of the internal workings of model settings are well-documented, and it seems like a large discussion (or work effort) is needed to standardize this across the models.

2. Does it implement good methods (i.e. is it consistent with good practices in travel modeling)?
   Yes, this change improves the flexibility of the ActivitySim framework allowing it be implemented in more locations.

3. Are the runtimes reasonable and does it provide documentation justifying this claim?
   This change will have no material change on the model run time. This code change replaces hard-coded values with a set of user-defined parameters.

4. Does it include non-Python code, such as C/C++? If so, does it compile on any OS and are compilation instructions included?
   No. This is a Python-only change.

5. Is it licensed with the ActivitySim license that allows the code to be freely distributed and modified and includes attribution so that the ‘provenance’ of the code can be tracked? Does it include an official release of ownership from the funding agency if applicable?
   This work was done under contract to ARC, and, presumably, ARC is providing the changes without any additional licensing beyond the existing ActivitySim licensing.

6. Does it appropriately interact with the data pipeline (i.e. it doesn't create new ways of managing data)?
   This change does not impact the data pipeline.

7. Does it include regression tests to enable checking that consistent results will be returned when updates are made to the framework?
   No regression testing has been done. The code change removes a hard-coded value in the Python code with a set of user-defined variables. If the user specifies the same values as the previously hard-coded values, they should get the same results. The unit tests seem to confirm this assertion.

8. Does it include sufficient test coverage and test data for existing and proposed features?
   The test configuration files were modified to use the newest features.

9. Any other comments or suggestions for improving the developer experience?
   The documentation is still being built out, so it is difficult to understand where and how to add new documentation into the existing framework. Some documentation should be consistent across all models (as is the case with this change), so a standard would need to be set by the larger team or asserted by me.

[coveralls]

Coverage decreased (-0.02%) to 86.123% when pulling c9f890e on danielsclint:ft_schedule_flex into 7b57c94 on ActivitySim:master.

[danielsclint]

@bstabler, I updated the original PR comment with the some additional documentation and answered the "Review Criteria" questions. This PR works, but as I note in the comment, it probably should be followed-up with a few more code enhancements to make the assertion of the 'univ' trips more flexible.

[bstabler]

This looks good and we accept the PR. I changed the target to the develop branch so we can merge features here before merging (releasing) to master.

[danielsclint]

#273. This change require defining tour scheduling specs specifically in the mandatory_tour_scheduling.yaml. The code still hard-codes the 'univ' value, and additional flexibility should be added in the future. This is step one of probably a couple of steps to unwind the hard-coded values in this section of the code.

SPEC:
work: tour_scheduling_work.csv
school: tour_scheduling_school.csv
univ: tour_scheduling_university.csv

Review Criteria Responses

1. Does it contain all the required elements, including a runnable example, documentation, and tests?
   The example scripts have been updated so the examples and tests complete. It's unclear how the documentation should be updated for this change. Few of the internal workings of model settings are well-documented, and it seems like a large discussion (or work effort) is needed to standardize this across the models.

2. Does it implement good methods (i.e. is it consistent with good practices in travel modeling)?
   Yes, this change improves the flexibility of the ActivitySim framework allowing it be implemented in more locations.

3. Are the runtimes reasonable and does it provide documentation justifying this claim?
   This change will have no material change on the model run time. This code change replaces hard-coded values with a set of user-defined parameters.

4. Does it include non-Python code, such as C/C++? If so, does it compile on any OS and are compilation instructions included?
   No. This is a Python-only change.

5. Is it licensed with the ActivitySim license that allows the code to be freely distributed and modified and includes attribution so that the ‘provenance’ of the code can be tracked? Does it include an official release of ownership from the funding agency if applicable?
   This work was done under contract to ARC, and, presumably, ARC is providing the changes without any additional licensing beyond the existing ActivitySim licensing.

6. Does it appropriately interact with the data pipeline (i.e. it doesn't create new ways of managing data)?
   This change does not impact the data pipeline.

7. Does it include regression tests to enable checking that consistent results will be returned when updates are made to the framework?
   No regression testing has been done. The code change removes a hard-coded value in the Python code with a set of user-defined variables. If the user specifies the same values as the previously hard-coded values, they should get the same results. The unit tests seem to confirm this assertion.

8. Does it include sufficient test coverage and test data for existing and proposed features?
   The test configuration files were modified to use the newest features.

9. Any other comments or suggestions for improving the developer experience?
   The documentation is still being built out, so it is difficult to understand where and how to add new documentation into the existing framework. Some documentation should be consistent across all models (as is the case with this change), so a standard would need to be set by the larger team or asserted by me.

[coveralls]

Coverage decreased (-0.02%) to 86.123% when pulling c9f890e on danielsclint:ft_schedule_flex into 7b57c94 on ActivitySim:master.

[danielsclint]

@bstabler, I updated the original PR comment with the some additional documentation and answered the "Review Criteria" questions. This PR works, but as I note in the comment, it probably should be followed-up with a few more code enhancements to make the assertion of the 'univ' trips more flexible.

[bstabler]

This looks good and we accept the PR. I changed the target to the develop branch so we can merge features here before merging (releasing) to master.

[danielsclint]

#273. This change require defining tour scheduling specs specifically in the mandatory_tour_scheduling.yaml. The code still hard-codes the 'univ' value, and additional flexibility should be added in the future. This is step one of probably a couple of steps to unwind the hard-coded values in this section of the code.

SPEC:
work: tour_scheduling_work.csv
school: tour_scheduling_school.csv
univ: tour_scheduling_university.csv

Review Criteria Responses

1. Does it contain all the required elements, including a runnable example, documentation, and tests?
   The example scripts have been updated so the examples and tests complete. It's unclear how the documentation should be updated for this change. Few of the internal workings of model settings are well-documented, and it seems like a large discussion (or work effort) is needed to standardize this across the models.

2. Does it implement good methods (i.e. is it consistent with good practices in travel modeling)?
   Yes, this change improves the flexibility of the ActivitySim framework allowing it be implemented in more locations.

3. Are the runtimes reasonable and does it provide documentation justifying this claim?
   This change will have no material change on the model run time. This code change replaces hard-coded values with a set of user-defined parameters.

4. Does it include non-Python code, such as C/C++? If so, does it compile on any OS and are compilation instructions included?
   No. This is a Python-only change.

5. Is it licensed with the ActivitySim license that allows the code to be freely distributed and modified and includes attribution so that the ‘provenance’ of the code can be tracked? Does it include an official release of ownership from the funding agency if applicable?
   This work was done under contract to ARC, and, presumably, ARC is providing the changes without any additional licensing beyond the existing ActivitySim licensing.

6. Does it appropriately interact with the data pipeline (i.e. it doesn't create new ways of managing data)?
   This change does not impact the data pipeline.

7. Does it include regression tests to enable checking that consistent results will be returned when updates are made to the framework?
   No regression testing has been done. The code change removes a hard-coded value in the Python code with a set of user-defined variables. If the user specifies the same values as the previously hard-coded values, they should get the same results. The unit tests seem to confirm this assertion.

8. Does it include sufficient test coverage and test data for existing and proposed features?
   The test configuration files were modified to use the newest features.

9. Any other comments or suggestions for improving the developer experience?
   The documentation is still being built out, so it is difficult to understand where and how to add new documentation into the existing framework. Some documentation should be consistent across all models (as is the case with this change), so a standard would need to be set by the larger team or asserted by me.

[coveralls]

Coverage decreased (-0.02%) to 86.123% when pulling c9f890e on danielsclint:ft_schedule_flex into 7b57c94 on ActivitySim:master.

[danielsclint]

@bstabler, I updated the original PR comment with the some additional documentation and answered the "Review Criteria" questions. This PR works, but as I note in the comment, it probably should be followed-up with a few more code enhancements to make the assertion of the 'univ' trips more flexible.

[bstabler]

This looks good and we accept the PR. I changed the target to the develop branch so we can merge features here before merging (releasing) to master.

[danielsclint]

#273. This change require defining tour scheduling specs specifically in the mandatory_tour_scheduling.yaml. The code still hard-codes the 'univ' value, and additional flexibility should be added in the future. This is step one of probably a couple of steps to unwind the hard-coded values in this section of the code.

SPEC:
work: tour_scheduling_work.csv
school: tour_scheduling_school.csv
univ: tour_scheduling_university.csv

Review Criteria Responses

1. Does it contain all the required elements, including a runnable example, documentation, and tests?
   The example scripts have been updated so the examples and tests complete. It's unclear how the documentation should be updated for this change. Few of the internal workings of model settings are well-documented, and it seems like a large discussion (or work effort) is needed to standardize this across the models.

2. Does it implement good methods (i.e. is it consistent with good practices in travel modeling)?
   Yes, this change improves the flexibility of the ActivitySim framework allowing it be implemented in more locations.

3. Are the runtimes reasonable and does it provide documentation justifying this claim?
   This change will have no material change on the model run time. This code change replaces hard-coded values with a set of user-defined parameters.

4. Does it include non-Python code, such as C/C++? If so, does it compile on any OS and are compilation instructions included?
   No. This is a Python-only change.

5. Is it licensed with the ActivitySim license that allows the code to be freely distributed and modified and includes attribution so that the ‘provenance’ of the code can be tracked? Does it include an official release of ownership from the funding agency if applicable?
   This work was done under contract to ARC, and, presumably, ARC is providing the changes without any additional licensing beyond the existing ActivitySim licensing.

6. Does it appropriately interact with the data pipeline (i.e. it doesn't create new ways of managing data)?
   This change does not impact the data pipeline.

7. Does it include regression tests to enable checking that consistent results will be returned when updates are made to the framework?
   No regression testing has been done. The code change removes a hard-coded value in the Python code with a set of user-defined variables. If the user specifies the same values as the previously hard-coded values, they should get the same results. The unit tests seem to confirm this assertion.

8. Does it include sufficient test coverage and test data for existing and proposed features?
   The test configuration files were modified to use the newest features.

9. Any other comments or suggestions for improving the developer experience?
   The documentation is still being built out, so it is difficult to understand where and how to add new documentation into the existing framework. Some documentation should be consistent across all models (as is the case with this change), so a standard would need to be set by the larger team or asserted by me.

[coveralls]

Coverage decreased (-0.02%) to 86.123% when pulling c9f890e on danielsclint:ft_schedule_flex into 7b57c94 on ActivitySim:master.

[danielsclint]

@bstabler, I updated the original PR comment with the some additional documentation and answered the "Review Criteria" questions. This PR works, but as I note in the comment, it probably should be followed-up with a few more code enhancements to make the assertion of the 'univ' trips more flexible.

[bstabler]

This looks good and we accept the PR. I changed the target to the develop branch so we can merge features here before merging (releasing) to master.

[danielsclint]

#273. This change require defining tour scheduling specs specifically in the mandatory_tour_scheduling.yaml. The code still hard-codes the 'univ' value, and additional flexibility should be added in the future. This is step one of probably a couple of steps to unwind the hard-coded values in this section of the code.

SPEC:
work: tour_scheduling_work.csv
school: tour_scheduling_school.csv
univ: tour_scheduling_university.csv

Review Criteria Responses

1. Does it contain all the required elements, including a runnable example, documentation, and tests?
   The example scripts have been updated so the examples and tests complete. It's unclear how the documentation should be updated for this change. Few of the internal workings of model settings are well-documented, and it seems like a large discussion (or work effort) is needed to standardize this across the models.

2. Does it implement good methods (i.e. is it consistent with good practices in travel modeling)?
   Yes, this change improves the flexibility of the ActivitySim framework allowing it be implemented in more locations.

3. Are the runtimes reasonable and does it provide documentation justifying this claim?
   This change will have no material change on the model run time. This code change replaces hard-coded values with a set of user-defined parameters.

4. Does it include non-Python code, such as C/C++? If so, does it compile on any OS and are compilation instructions included?
   No. This is a Python-only change.

5. Is it licensed with the ActivitySim license that allows the code to be freely distributed and modified and includes attribution so that the ‘provenance’ of the code can be tracked? Does it include an official release of ownership from the funding agency if applicable?
   This work was done under contract to ARC, and, presumably, ARC is providing the changes without any additional licensing beyond the existing ActivitySim licensing.

6. Does it appropriately interact with the data pipeline (i.e. it doesn't create new ways of managing data)?
   This change does not impact the data pipeline.

7. Does it include regression tests to enable checking that consistent results will be returned when updates are made to the framework?
   No regression testing has been done. The code change removes a hard-coded value in the Python code with a set of user-defined variables. If the user specifies the same values as the previously hard-coded values, they should get the same results. The unit tests seem to confirm this assertion.

8. Does it include sufficient test coverage and test data for existing and proposed features?
   The test configuration files were modified to use the newest features.

9. Any other comments or suggestions for improving the developer experience?
   The documentation is still being built out, so it is difficult to understand where and how to add new documentation into the existing framework. Some documentation should be consistent across all models (as is the case with this change), so a standard would need to be set by the larger team or asserted by me.

[coveralls]

Coverage decreased (-0.02%) to 86.123% when pulling c9f890e on danielsclint:ft_schedule_flex into 7b57c94 on ActivitySim:master.

[danielsclint]

@bstabler, I updated the original PR comment with the some additional documentation and answered the "Review Criteria" questions. This PR works, but as I note in the comment, it probably should be followed-up with a few more code enhancements to make the assertion of the 'univ' trips more flexible.

[bstabler]

This looks good and we accept the PR. I changed the target to the develop branch so we can merge features here before merging (releasing) to master.

[danielsclint]

#273. This change require defining tour scheduling specs specifically in the mandatory_tour_scheduling.yaml. The code still hard-codes the 'univ' value, and additional flexibility should be added in the future. This is step one of probably a couple of steps to unwind the hard-coded values in this section of the code.

SPEC:
work: tour_scheduling_work.csv
school: tour_scheduling_school.csv
univ: tour_scheduling_university.csv

Review Criteria Responses

1. Does it contain all the required elements, including a runnable example, documentation, and tests?
   The example scripts have been updated so the examples and tests complete. It's unclear how the documentation should be updated for this change. Few of the internal workings of model settings are well-documented, and it seems like a large discussion (or work effort) is needed to standardize this across the models.

2. Does it implement good methods (i.e. is it consistent with good practices in travel modeling)?
   Yes, this change improves the flexibility of the ActivitySim framework allowing it be implemented in more locations.

3. Are the runtimes reasonable and does it provide documentation justifying this claim?
   This change will have no material change on the model run time. This code change replaces hard-coded values with a set of user-defined parameters.

4. Does it include non-Python code, such as C/C++? If so, does it compile on any OS and are compilation instructions included?
   No. This is a Python-only change.

5. Is it licensed with the ActivitySim license that allows the code to be freely distributed and modified and includes attribution so that the ‘provenance’ of the code can be tracked? Does it include an official release of ownership from the funding agency if applicable?
   This work was done under contract to ARC, and, presumably, ARC is providing the changes without any additional licensing beyond the existing ActivitySim licensing.

6. Does it appropriately interact with the data pipeline (i.e. it doesn't create new ways of managing data)?
   This change does not impact the data pipeline.

7. Does it include regression tests to enable checking that consistent results will be returned when updates are made to the framework?
   No regression testing has been done. The code change removes a hard-coded value in the Python code with a set of user-defined variables. If the user specifies the same values as the previously hard-coded values, they should get the same results. The unit tests seem to confirm this assertion.

8. Does it include sufficient test coverage and test data for existing and proposed features?
   The test configuration files were modified to use the newest features.

9. Any other comments or suggestions for improving the developer experience?
   The documentation is still being built out, so it is difficult to understand where and how to add new documentation into the existing framework. Some documentation should be consistent across all models (as is the case with this change), so a standard would need to be set by the larger team or asserted by me.

[coveralls]

Coverage decreased (-0.02%) to 86.123% when pulling c9f890e on danielsclint:ft_schedule_flex into 7b57c94 on ActivitySim:master.

[danielsclint]

@bstabler, I updated the original PR comment with the some additional documentation and answered the "Review Criteria" questions. This PR works, but as I note in the comment, it probably should be followed-up with a few more code enhancements to make the assertion of the 'univ' trips more flexible.

[bstabler]

This looks good and we accept the PR. I changed the target to the develop branch so we can merge features here before merging (releasing) to master.