The macro did not transfer the two data values representing the discharge phases of each appended link. These were assessed by hand to determine the correct way to code the values from all turning movement links for a given inbound link into the appropriate fields on just one link.INTEGRATION V2.0 distinguishes between protected and permitted left turn phases by allowing the user to assign a negative value to the discharge phase number if that phase represents a protected left turn. In earlier versions of the model an algorithm would check if the discharge phase number of the left turn was the same as the discharge phase number as the opposing through movement. If so, it would model the traffic flow as a permitted left turn. Otherwise it would be treated as a protected left turn. The use of the negative value in the INTEGRATION V2.0 model allows more information to be stored in fewer fields. Hence, it was possible to recode all the phasing information stored in the two fields of each appended link to the two appropriate fields of one link. However, there were many different conditions that had to be checked, so this part of the data transfer from the appended links was carefully performed without the use of a macro. Once the data were transferred to the main inbound links the appended links were deleted before adding the new center nodes and new appended links, to fill the gap created by the removal of the original appended links. The first step in the process of adding the new center nodes and new appended links was to create a file named MODIFIER.XLS, which contains all the relevant data for each intersection to be modified. A section of this file is presented below in Table 23. MODIFIER.XLS was a working file in which data were gathered from the original link data file and node file,tower garden before being used to update those files.

The signal number, in- and out-bound links numbers, and link node numbers were obtained from MOD_SUPP.XLS; this is an Excel file that is essentially a copy of the original link data file provided by UC Berkeley with comments and flags. The macro UNEXPANDED was written and saved in the MOD_SUPP.XLS file to collect these data and enter them into the appropriate place in the working file MODIFIER.XLS mentioned above. The upstream node number of the first outbound link at each signal was selected as the number for the ‘new’ center node. This node number could be re-used since the upstream nodes of each outbound link were to be moved to the new center node, rendering the original outbound link upstream node numbers obsolete . Another macro named GETCOORDINATE was created and saved in MODIFIER.XLS to extract the X- and Y-coordinates from the node file NODE1.DAT for each node listed in MODIFIER.XLS and subsequently entered them into the appropriate place in MODIFIER.XLS. The coordinates of the new center node were calculated by taking the average of the coordinates of all outbound link upstream nodes at the intersection under consideration. This was the most efficient way to place the new node in the approximate center of the intersection configuration. The macro UNEXPANDED functioned well for “standard” intersections – those with four inbound links to the signal and four outbound links from the signal. Intersections that were T-junctions and/or where one-way links existed, were more complicated. Where no main inbound link existed for a particular leg of the intersection , the nodes and links could not be traced by the macro to identify the corresponding outbound link . Hence, the macro would respond as if there was no outbound link on that leg, where in fact one may exist. Such problems could be identified by plotting the coordinates of all nodes at an intersection and connecting them with links to view the configuration of the intersection. This was a very time consuming process and hence an alternative method was sought. To deal with the cases of T-junctions and one way links another macro named TSECCASE was written and stored in MODIFIER.XLS. The way this macro functions is difficult to explain without the aid of detailed diagrams, but we made an attempt to do this here. This macro obtains the downstream node number of all left and right turn appended links and compares them with the downstream node number of all “through” movement appended links.

Where a downstream node associated with a left or right turn link could not be matched with the downstream node of a through movement link, this node was flagged as the upstream node of an outbound link that was not previously identified by the UNEXPANDED macro.The first three steps were carried out with the help of the macro ADDNL stored in MODIFIER.XLS. The macro assigned a new link number to each new appended link, assigned the downstream node number of the main inbound link as the value of the new link’s upstream node, and the new center node number as the value of the new link’s downstream node. The node number of all outbound links was also changed to the new center node number to complete the network connectivity. To correct the opposing link numbers, the associations between main inbound links and appended links were stored so that the values in the opposing link fields could be updated from the numbers of main inbound links to their corresponding appended links. Before the fourth step was carried out, the data from APPROACH.DAT and EXPLODE.DAT were entered into two Excel data files, APPROACH.XLS and EXPLODE.XLS. The electronic versions of these files were not obtained from the UC Berkeley team. The EXPLODE.DAT/XLS file listed the characteristics of each intersection by the INTEGRATION node number of the intersection . The information stored in these records had to be matched to the link numbers and node numbers after the intersections were expanded. The problem is that the node numbers in this list did not exist after the intersections were expanded. However, careful study of a column of comments in the node file revealed that the comments contained the original node number around which each set of new nodes had been built. A macro named GETSIGNALNO was created to obtain the first of the new node numbers and search for that node in the file MODIFIER.XLS. Once the node was found, the number of the signal at which that node existed could be determined. The signal number was then entered back in the EXPLODE.XLS file alongside the corresponding INTEGRATION node number. The fourth step above was then carried out by the macro UPDATENL, which is also saved in EXPLODE.XLS. The EXPLODE.DAT/XLS file contains fields that store the number of a predefined approach type,stacking flower pot tower for each approach link. The APPROACH.DAT/XLS file contains data that defines each of these approach types including the number of lanes, basic saturation flow rate, free flow speed, and lane configuration .

During this recoding process for the link data file, a number of errors and inconsistencies were identified in the link data. The resolution of these inconsistencies was made difficult since the UC Berkeley team was unable to provide a detailed map of the network region or drawings of specific intersections. Most of the problems were resolved by phone calls to members of the UC Berkeley team or other individuals familiar with the corridor.The demand file contains the O-D demand matrix for the network. The O-D matrix provided by the UC Berkeley team is for the morning period 6:00am – 10:00am. Bacon et al. details the difficulty encountered during attempts to calibrate the full morning period and a midday period . Calibration of the morning peak period from 8:00am – 10:00am was attempted by both the UC Berkeley team and the model developers, but it was unsuccessful after attempts for eight months. The four half hour time slices between 6:00am and 8:00am were calibrated successfully, and the demand pattern for this period was mirrored for the remaining two hours from 8:00am – 10:00am; . The format of this file did not change between V1.5 and V2.0 of INTEGRATION, hence, no updates are necessary for that reason. However, the file will be edited to reflect the market penetration rates of the route guidance and en-route traveler information systems for the scenarios in which they will be modeled. One of the following section discusses the proposed modeling runs. The O-D file may also be edited to remove the 8:00am – 10:00am portion of the morning period, if it is found that model runs require an unrealistically long time to complete. The lane striping file is a feature added to INTEGRATION V2.0 that allows the user to specify the lane configuration and lane use on any given link. This is particularly useful at intersections . Additionally, each of the five vehicle types that can be defined in the INTEGRATION master control file can be allowed or prohibited access to any or all of the lanes. The following information is included in the lane striping file: link number, number of lanes, permitted turning movements for each lane, and vehicle type prohibition for each lane. A portion of the lane striping file created is shown below in Table 24.Since this file is a new feature of the INTEGRATION2.0 model from the version used by the team at UC Berkeley, it did not exist as part of the database obtained. It was important to create this file to specify lane configurations for the new appended links that had been added, as described in the above section for the link file. Detailed information about the lane configurations for each approach type is contained in the comment column of the APPROACH.DAT file in the Technical Appendix of Bacon et al. . Another macro, LANESTRP, was written to extract this information and insert it in the appropriate fields of the lane striping file.The integer one represents permission and zero represents prohibition for left, through, and right turning movements respectively. For example, the code 100 for a given lane would represent and exclusive left turn lane, whereas 110 would represent a lane with shared left and through movements.Vehicle type prohibition for each lane is defined by a five integer code in which the integer one represents prohibition of a certain vehicle type and the integer zero represents permission. Hence, the code 01000 would represent prohibition to vehicle type two for a given lane with permission for all other vehicle types. No prohibitions have been assigned to the lanes of any of the appended links at this stage. Some additional work is necessary to complete the lane striping file. Some data were missing from the EXPLODE.DAT file and they will have to be obtained from another source before completion of this input file.The project team will discuss additional potential model runs with the project sponsors to help determine which runs will be given priority for further work. Substantial effort is expected to be directed toward the identification of specific model runs in the near future, as model formulation is nearing completion. Model runs will be performed for the morning period for which the O-D demand file was created by the UC Berkeley team. As described in the Demand file section of the Modifications to the Database section, this morning period is from 6:00am – 10:00am; however, it was only calibrated for the first two hours. The last two hours were made a mirror image of the first two hours. For the current project, simulations may be carried out only for the period 6:00am – 8:00am, depending on the actual time the model takes to complete a run. Bacon et al. Stated that INTEGRATION runs for the first two time slices were able to be completed overnight; however, runs for all eight morning time slices would have taken approximately six days to complete. It is expected that simulation runs for this current study will take somewhat less time, due to the use of faster computer technology. However, the INTEGRATION model has been modified and in several aspects is more microscopic requiring additional processing–this will counteract the gains achieved by greater computer power to some extent.