-
Notifications
You must be signed in to change notification settings - Fork 5
Known Issues in ADSM
Github manages all issues related to the ADSM project. Issues contain tickets related to many aspects of the project, such as technical specifications, decisions, tasks, future feature requests and other items requiring shared documentation for all team members. The items identified on this page are only those that:
- Have been identified as bugs, meaning failure of expected action or unexpected action and can be reliably repeated and documented.
- Are likely to be encountered by regular users
- Are considered critical
The Development Team works to set priorities on all work with input from our users, within the constraints of limited funding. On some occasions, these issues cannot be resolved as they involve browser functionality that is out of the ADSM Development Team’s control and that will be noted in the known bug documentation. We also realize that our training material is limited at this time, and are working to get more training options in place.
If you have a bug or concern, you are welcome to add an issue. The Development team needs to know what version you are working in, and the steps needed to reproduce the problem you are having. Please include those details in the issue. We will work on issues according to the level of our funding at a particular time.
RED BOX ERROR
A red box error occurs to allow the simulation to stop without causing additional problems, such as a runaway memory issue on your PC. There are several known reasons for the red box errors to happen, and likely other reasons that we have not documented. The first step with a red box error is to switch over to the CMD (black screen) window and check for error messages. It may be possible to determine the problem from the error text. Several red box errors are documented in known bugs.
A yellow screen with the message “DatabaseError at /app/Startup/ Database disk image is malformed” appears. The ADSM Development Team was not able to identify the steps needed to create this error.
The User described attempting to switch between scenarios when this error appeared. A yellow screen with the message “Database disk image is malformed” appears. The ADSM Development Team was not able to identify the steps needed to create this error.
Close the yellow screen/program. Navigate to the assigned ADSM Workspace. Open the “Settings” folder. Delete the file named “activeSession.db”. Reopen ADMS, and application will open into a default scenario.
Population file format was not recognized.
When loading a population file, the error message “Error: This is not a valid Population file: Unrecognized csv header format! Please refer to the wiki for help. This example happened when the user had followed the field order as shown on the Population screen for a previously uploaded Population file (Production type, Latitude, Longitude, Initial state, days in initial state, Days left in initial state, Initial Size, Unit id).
Follow the field order as listed on the wiki page, which is (UnitID, ProductionType, UnitSize, Lat, Lon, Status, Daysinstate, Daysleftinstate).
Parameters are assumed to be completed. Validate Scenario action button is clicked, and the following message returned:
Critical Simulation Error: Correct the following error and try again: [blank - no error showing]
Note that there is no critical error showing. Recall that the errors under Warning: are informational and will not stop the simulation from running. However, errors under the Critical Simulation error must be resolved. It was discovered that a field was not marked as required. When this field is blank, it will cause the error.
Ensure that the field “Days to Immunity”, under the vaccination section of the Control Protocol is filled. If you wish to have the minimal window to start immunity, a zero is an acceptable value in this field.
When a production type is added (using the Production Type panel) but is not assigned to a unit in the Population tab, an error will occur. This will appear first in the command window, showing the message:
b'\n** (adsm_simulation:9332): ERROR **: "test" is not a production type\n'
However, validation can occur and allow the simulation to proceed. If the simulation proceeds, additional messaged will appear in the command window:
BrokenPipeError: [WinError 232] The pipe is being closed Aborting Simulation Thread
Additional messages are shown as well. The simulation will appear to be in preparation to run, but no iterations will complete. The error messages will repeat until you break the connection by closing the application (with the X). If the error message continues to cycle, it may eventually give a message similar to #960 C engine out of memory. A red error message will appear, noting that you should close the application.
Close both windows of the application using the (X). Reopen the application. Go to the Production Type tab, using “Edit”, assign at least one unit to the new production type.
When adding a new spread (e.g. direct spread), after hitting “Apply”, the screen refreshes and the just-added spread parameter does not show in the list. At this time, the reason for this problem is unknown but has a work-around.
Ensure that all required fields (indicated in yellow) are filled. Use the “Save Changes” in the upper right corner to ensure the database is updated. Repeat the “+ New Direct Spread” to add the spread again. This second attempt has been producing the expected results of saving the spread to the list.
A yellow screen error “FileNotFoundError…” will occur if there is an attempt to import either relational functions or probability density function if there is no file to import.
Always move the function files that are intended to be imported into the correct place in the file structure. This file structure will be specific to your scenarios. Using the Sample Scenario as an example, within the ADSM Workspace/Sample Scenario, there is a folder named Imports. Copy and paste the function files (normally stored in ADSM Workspace/Exports/Exported Functions) into the Imports folder. If you have just created a new scenario, a Save will be required to make the Imports folder appear.
Immediate solution is ensure that you are not using the same file name (case matters) when doing a duplicate (Save As) on a file. Currently, the application doesn't check the file system for a file with the same name. ADSM was designed to be compatible with a a cloud server, therefore the application is purposefully independent. Checking the file system for duplicate names on a larger file server would take an unknown amount of time, and could create an unexpected delay. At this time, the Development team has chosen not to implement this check.
This problem appears when running ADSM from a portable drive (USB Flash drive) when both the application and the output (ADSM Workspace) are located on the portable drive.
The application will start and works normally while inputting parameters in a scenario. The scenario will validate. When you attempt to run the simulation, it will begin as expected. However, the portable drive connection is not fast enough to keep up with the speed that operations are being executed in the simulation. The error message “sqlite3.OperationalError: database is locked” will show in the command window.
Moving either the application (folder with ADSM) or the output (ADSM Workspace) to another drive will allow the database to keep up with the pace of read/write for the simulation. Either of these folders could be moved temporarily to the desktop while running your scenarios using copy and paste in File Explorer. Once the simulation is complete, the folder could be moved back to the portable drive. Both components (application and outputs) can easily be moved around between drives or PC’s. In the case of outputs, move the whole folder named with the scenario name back onto the portable drive using copy and paste in File Explorer. In the Project Panel, be sure that the current workspace has the file path where you are expecting outputs to be saved. It is very easy to modify this file path using the “change” link provided.
This issue happens when you have run the simulation and created Supplement Output Files, and left one of the output files open in another application, such as Excel. When you attempt to run the simulation again, the application is in an inconsistent state. An error message is shown in the CMD window that is similar to:
“Error ** : apparent-events-table-writer: Device or resource busy error when attempting to open file [lists files path]”
In the example, the daily_events_x.csv table was open. It could be possible to have daily_exposures_x.csv or daily_states.csv open instead of daily_events_x.csv. Upon returning to the Input side, the “Delete and apply changes” seems to happen, but it does not reset all the results. The scenario appears to have results present, which is shown by leaving the action button in “Return to Input” and showing that green bar with simulation results. If you attempt to run, it will return you to the Result screen which shows the hourglass as if the application is starting to run. It will stay in this state indefinitely, unless you terminate it by closing with the X.
This solution takes several steps, and you may have clicked around a few times trying to figure out what happened. The CMD error is the clue, so be sure you have checked it.
First, ensure that the output file is no longer open in the other application. Next, navigate to the Supplemental Output File folder within your scenario in the ADSM Workspace. Delete the whole Supplemental Output File folder. Close the application. The CMD window may stay active, with the message “Attempting to close server”. If this happens, close the CMD window with the X.
Upon restart, the scenario should be reset and available as usual. Result should not be present, so you are free to change parameters and run again.
This problem appears when numbers with decimals have been used in the Population file, in herd size (unit size).
The application will start and works normally while inputting parameters in a scenario. The exception is on the Disease Spread tab. At the bottom, there is a section for disease spread assignments. This allows users to indicate the source production type and the destination production type for movements. When decimal numbers are in the herd size, no production types will be visible, and therefore an assignment cannot happen. The validation tab color will stay yellow. If user attempts to validate scenario, an error indicating production type has not been assigned, and will not participate in the spread will be shown.
Confirm that the value for the herd size is a whole number. Replace the population with a new file if needed.
This problem appears when a population has been replaced on a PC normally set to a language other than English. This issue is similar to #1021, except that the exact problem cannot be pinpointed.
The application will start and works normally while inputting parameters in a scenario. The exception is on the Disease Spread tab. At the bottom, there is a section for disease spread assignments. This allows you to indicate the source production type and the destination production type for movements. When this issue is occurring, no production types will be visible, and therefore an assignment cannot happen. The validation tab color will stay yellow. If you attempt to validate scenario, an error indicating production type has not been assigned, and will not participate in the spread will be shown.
This issue has had limited testing by the ADSM Development Team. We have had success when starting a new scenario without using the replace population. This may cause additional work but is a solution. Recall that both types of functions can be exported from a non-working scenario and imported into a new scenario to avoid creating functions a second time.
The Access Denied yellow screen appears when the application is not able to connect to the SQLite database.
The application disappears and is replaced by a yellow and white screen. The beginning of the error message says: AccessDenied at /setup/Scenario/1/
(pid=4936)
Request Method: GET
Request URL: http://127.0.0.1:53340/setup/Scenario/1/
Django Version: 1.8.2
Exception Type: AccessDenied
There are two reasons that access may be denied.
-
If the user’s ADSM Workspace has been saved into a directory where the user does not have access permission. For example, if the ADSM Workspace was placed in the program files by a Network Administrator, but the individual user does not have access to read/write to the program files. The ADSM Workspace can now be placed on a portable drive if needed.
-
The database (.db) file has a connection to a SQL editor, such as MS Access or SQLite Studio that is outside of ADSM. This would happen if the user was using one of these SQL editors to access the database.
For Option 1, be sure that the ADSM Workspace is saved in a location that the user has access to. The ADSM Workspace can now be placed on a portable drive if needed.
For Option 2, close the conflicting connection if known. If not known, close all applications and restart. This should drop the connection.
Replace population is not functional when results are present.
When attempting to use the “Replace Population” when results are present, user is stuck in a continuous loop. When “Replace Population” is selected, the confirmation message to delete the existing population is presented. However, if delete is selected, no delete action happens. User is returned to screen.
Since there is a simple workaround (deleting results), a complex technical solution will not be implemented. To replace the population, select a different tab, such as Scenario Description. The Apply button is red, with the text “Delete Results and apply changes”. Press this button to delete results. After results are deleted, return to the Population tab is use the “Replace Population” button. Since there are no results, the process will complete as expected.
When a scenario fills up the available space while running a simulation on a user's PC, the application will finished writing the last iteration possible. It will then return to a results view and draw the map from the available iterations.
The command window will show an error message that includes the text "database or disk is full" I also got a separate Windows error message saying my disk was full.
This error is related specifically to the user's PC. To resolved this error, users should clean off files that are no longer needed, both with in ADSM Workspace and also in other directories. Another option would be to run ADSM on a PC with more available disk space.
This problem appears when creating a new relational function that requires using "overwrite" to add more values.
The name of the function appears multiple times, one time per each save. When user attempts to assign the function, these multiples are shown on the list.
This is a minor problem, and will only be addressed if we have funding. User can select any of the functions on the list, and it will be assigned to the parameter. After page refresh such as "Apply', the problem is resolved.
This problem appears in the command window.
When a user hits the abort button, the application will finish any running iterations and write the results to the database. The Command window will give a series of messages as it cancels each thread running an iteration. Recall that ADSM will use as many processors as are available on your machine, so this could be more than one message. The message ends with
“BrokenPipeError: [WinError 232] The pipe is being closed”
This is not a bug. These messages are informational, as the user did request the scenario to stop. The application will finish writing completed iterations and return to Results Home.
Application was prompting for a save at an inappropriate state.
When the scenario has been run, and results are present, the Save prompt was appearing.
Change was made to place application in a “review” mode. The Save prompt in the top right corner will not be visible when a user edits. Any changes would require the user to press the red Delete Results and Apply Changes, to return to an editing mode. The Save prompt will then appear as needed when changes are made.
This issue appears when the scope of the scenario is larger than the computer memory allocated to it
The application will start and works normally while inputting and saving parameters in a scenario. The scenario will validate. When you attempt to run the simulation, it will begin as expected. At some point, when the memory has been overwhelmed, the simulation will stop. Result Home will come up with partial scenario results. A red box will be shown in the upper right corner notifying you of the issue.
A runaway outbreak has happened. The control measures applied are not controlling the outbreak. Check your disease spread parameters to ensure they are within a reasonable range. For example Fixed/Mean baseline contact rate (in outgoing contacts/unit/day) may be high. Another example would be spread using a source and destination that is unrealistic. A large cow/calf farm might send out 10 shipments a day, but they are likely going to one specific destination, like a stocker farm and would not likely have contact with a large Swine nursery farm.
Partial results may be available if you needed to examine a subset of results from what the simulation was attempting to model. It may be necessary to close the application (with the X) and restart.
This problem appears in the command window.
The scenario validates and starts to run, but posts “Caught a 500 error!” in the command window. This error has only been observed one time by a user, and could not be replicated by the ADSM Development Team. Therefore, this solution is a theory and was not tested.
The ADSM Development team suspects that the database file became corrupted as scenarios were transferred.
If the scenario file was working on another computer, try to make another copy to transfer. Or, users can also rebuild the scenario from scratch.
In future ADSM releases, the ADSM Development Team has enabled the application to show more detailed debug messages. These messages may give more insight into possible problems. Debug messages are startling, and usually appear as a yellow screen. Users can corrupt their database files if the files are opened with a SQL editor and modifications are made to the database structure, such as deleting a table. This is why it is recommended to use SQL editors only for reading data and not for writing data.
When the scope of infection was such that all the map was included in a zone, the visualization produced a totally blue image and dropped the legend.
Fixed. However, here are some notes about the Summary Population Results Map
- This map is a summary of all iterations. Just as we cannot distinguish individual farm details, we cannot distinguish individual zone details in a simple visualization. Therefore, zones are a generalized reference of how disease spreads that is suitable for viewing within the application. If detailed farm location and status analysis are needed, use the Supplemental Output files and a GIS system for a day-by-day, farm level assessment of spread. Zones are drawn to be 1/50 the width of the total map.
This problem appears in the Result pages, where a variable should be showing up in a graph.
When you have a value that returns as Null (empty), usually because you didn't parameterize for that output, you can get a placeholder in the results view. This is not a problem, just an unexpected results
Graphs should appear for all variables that you parameterized.
When a user attempts to load a population file with the Excel format, an error message is shown. Recall, accepted formats for population files are .csv and .xml. In Windows 7 ONLY, the error message is trimmed so the user has difficulty accessing the action button. However, the action button will work if clicked, and the message will close. The error message window is not controlled by the ADSM Development Team so we cannot fix this issue. In Windows 10, the full error message is displayed as expected.
The discrete uniform distribution does not graph exactly as expected. The last point appears to drop, and drop off the graph.
#913 Failed to load URL http://127.0.0.1:8000/ with error (-102)
Update: This error is due to a non-English language setup. If possible, create a VM with an English language setup and attempt to install. The following troubleshooting techniques are still valid for English language users.
Error 102 is a message generated by the Chrome Browser that is embedded with the ADSM application. This error happens when the browser cannot connect to the server running in the black terminal window that opens with the ADSM application.
Usually this happens because of a firewall that is blocking local connections, an aggressive virus scanner that is preventing the server from starting, or another program running on your system using the same ports as the ADSM application.
Some good troubleshooting steps are:
After installation, restart your computer and try running the application again
Try disabling your firewall and running the application
Try disabling your virus scanner and running the application
Try running the application with administrative privileges (right click on the shortcut or executable and select "Run as administrator")
After trying these steps, please remember to re-enable your firewall and virus scanner so your system isn't vulnerable.
No map is drawn after a reasonable amount of time. This issue cannot be corrected, as issue cannot be replicated. Troubleshooting is noted in issue text.
The simulation completes, and the hourglass is spinning waiting for the results population map to paint. However, no map is drawn after reasonable amount of time. Please note that large populations do take a longer time to paint the map. The cmd window reports that it is calculating the population map when application is working.
In this error case, the cmd window gives this error repeatedly: Waiting on population map
Exception in thread population_map_thread:
Traceback(most recent call last):
File “X:\Python34\lib\threading_py”, line 929, in _bootstrap_inner
File “Results\interactive_graphing.py”, line 180, in run
File “Results\interactive_graphing.py”, line 174, in make_population_map_file
File “Results\interactive_graphing.py”, line 130, in population_results_map
File “Results\interactive_graphing.py”, line 138, in (listcom)
File “Django\db\models\fields\related.py”, line 462, in get
Django.db.models.fields.related.RelatedObjectDoesNotExist: Unit has no unitstats.
Return to Inputs, delete results and apply changes. Run the simulation again.