Troubleshooting

Model Fails to Run All the Way Through

The command line will show a "Model Failed" error, along with any error messages passed from other scripts, if an R or Python error is caught. Reasons for these errors may include:

• An R script encountered an error. This is the most common issue, likely caused by a missing input or intermediary file. The error message from R will pass through to the command line window.
• An invalid model component is called in the Batch file. If the batch file is modified, ensure that the model runner and Visum runner tokens used in the batch file are valid.
• Visum is not licensed or there is not a compatible license available. In this situation, a Visum window may open but the software does not allow saving version files. To resolve, make sure the selected license(s) is appropriate for the CALM network size and available to use.

The following are a list of common issues that have repeated over the years of operation:

• The model starts but fails almost instantly, in the first couple minutes. One of the first things the model does at start up is opens Visum to export out information the model run needs. There are several reasons why Visum might fail to open, please review this list of the model appears to start but then fails with a cryptic python error:
  • Do you have the version of Visum that the model is referencing? The office updates Visum frequently (about once a year). Sometimes that includes uninstalling older versions of Visum. It might be that the model code you are attempting to run is pointing to a version of Visum that does not exist on the machine you are trying to run on. Review the page on Updating to a New Version of Visum. Note that you don't need to update to a new version, the linked page just points to where in the model code you can see what version the model is attempting to open and then you can verify that version is installed on the machine you are trying to use. If the model is pointing to a version that is not on your machine, you have three options; 1) find a machine that has the right version, 2) get the right version installed on the machine you would like to run the model on, or 3) use the Updating Visum instructions to update the model to the Visum install you have on your machine. Note, that the third option does carry a significant risk that the results will be slightly different in the new version of Visum than the prior version of Visum. The project manager of the model in question should be consulted with prior to updating the Visum version pointers.
  • You have the correct version installed, but you have never opened that Version of Visum under your log-in on the machine you are trying to run the model on. The first time a new version of Visum is opened by a user there are some setup activities that need human interaction. Therefore, prior to attempting to run the model, the user needs to ensure that they have opened that Version of Visum at least once on the given machine prior to attempting to run.
  • All the licenses are gone. It's possible that the office was busy at the time you were attempting to run, if all the licenses are gone Visum will not open properly and the model will crash. Note that this can stop a run at the beginning, but can also stop the model run at any point in the model stream where Visum is accessed (which happens a lot). Therefore, it is best and advised practice to have an open window of Visum in the background prior to starting the run to ensure that; a) Visum has been opened at least once on this machine (takes care of the above bullet), b) there a Visum license available and "checked out" at the beginning of the runs, and c) the license remains held by the user until the run is complete. Note, if you keep a Visum window open during the run (which is advised); please ensure to close the window when the run is complete and you are done using Visum in that instance, to ensure that the license is freed up for others to use.
• The model fails with a cryptic "214..." Visum fail emebedded in a python error code. This will typically be something related to the bullet directly above. Perhaps you didn't have a blank Visum window open at the time you were trying to run and another officemate started using the last license (leaving none for your run). If you do have a blank "check-out" window open and Visum still crashes, it's possible there's an error in the Visum file. To track this down, a user can review tin the Input Checker log. However, if the model failed the input checker should have caught and killed the run and given the user a more human readable message to review the input checker log. But it is possible that there's an error that's not yet in the input checker (a human built list of checks that is expanded each time a new type of input error is discovered). If the input checker seems fine, the next step would be to note the exact point the model crashed (screen capture the error message) and attempt a re-run. If the model dies in exactly the same place, there's probably an input error someplace that will need to be tracked down. However, more often than not, it might die in a related but different place, or maybe make it fully through the run. If this occurs, the likely issue is a "blip" in Visum license connection over the internet (it's also been noted that this can happen when the machine is left alone and the OS starts to fall asleep). Attempting a re-run or two might solve this. If multiple re-run keep having fails in slightly different locations within the model, the best course of action would be to "check-out" a Visum license key and plug it directly into the machine you are attempting to run on. Also it's good to note that the office typically has several machines with Visum keys directly plugged in. Perhaps just check with the office on whether you can use one of those machines that have dedicated uses/licenses with Visum.
• The Model died and directed you to the input checker log. This is exactly what the input checker is for. Please review input check log files. There should be a message in the log indicating the issue. You will need to solve this input issue before the model will advance.
• There's a "ConnectionException" error as the model enters Java.. Windows has security pop-ups, "do you trust this application", user windows. These can pop-up for R, python, or Java command calls made by the model, and there does not seem to be away to predict when windows will flag these for the user. Each instance can be a little different. In general, if you see this type of window pop up and you know you are running a model with R, Python, and Java, you need to attempt to indicate to Windows that you trust the application. If you don't trust the application, windows will block it, and the model will likely fail with sometime of connection or other cryptic fail message. Note, if a security window comes up and you aren't running anything and have no idea why the window popped up, you might want to contact someone else in the office to get their opinion, or likely just go directly to ODOT computer support and ask them. But, if you are running a model, it's reasonable to expect that these windows might crop up. Sometimes "trusting" the application requires local admin privileges, which you may or may not have. If you can't "trust" the application, the next best thing is to "x-out" by trying to just close the security window with the "X" in the upper right corner. What you don't want to do is tell windows you don't trust the application. Once you do that it indicates to Windows to never let that application run on your machine in that way, which can stop the model from working on that machine, and requires additional steps to resolve [instructions coming].

Assignment is drastically different then a previous run

This has come up due to the fact that the ABM uses a custom dll for the vdf. We have run into issues where the version file is not correctly pointed to the custom dll needed to reproduce the ABM's assignment. Reasons this can happen:

• Opening an ABM version file for the first time on a new machine. When the ABM runs, it copies the dll to the location Visum is looking. If the ABM has never been run, the dll will not automatically be in the correct place. See the run bat file for information on where to get a copy of the dll and where to store it for Visum.
• Opening an ABM version file in a new version of Visum. Same as the first bullet - the location that Visum looks for the dll is version (install) specific. If you are opening in Visum 2024 and the ABM has only ever been run in Visum 2023, the dll won't be visable, and the dll will need to be copied over to the new version. Either by hand, or by rerunning the ABM in the new Visum version.
• The Visum versions file might have a project directory that is no longer pointed to the default location for dlls. Go to File -> Project Directories -> Edit project directories. Near the bottom will be a "type" called "User-defined VD functions DLLs". That "Path" should be pointed to "%APPDATA%\PTV Vision%MAINPROGVERSION%\UserVDF-DLLs". If that row has something different in "Path", then the Visum instance is likely not seeing the custom DLL that is used to assign traffic in the ABM.