Vensim DSS Reproducible Crash Bug

[jrissman]

Hello Ventana Systems folks,

We are about ready to release a new version of the Energy Policy Simulator (1.3.0), but we have encountered an odd bug that appears to be an issue in Vensim. In Vensim DSS, our model passes both the error check and the unit check with no problems, and it runs flawlessly in "SyntheSim" mode. But if you click the "Simulate" button, Vensim immediately crashes.

We have also tested a published (.vpm) version of the model in Vensim Model Reader. There, both the "SyntheSim" and "Simulate" buttons work without crashing the program. So, the problem appears to be particular to Vensim DSS (not Model Reader) and particular to the Simulate button (not SyntheSim).

We have tested this under Vensim DSS 6.3C, 6.3G, and 6.4D. It happens in all of these versions.

Vensim command scripts require the ability to issue the "simulate" command to the model, so this bug blocks us from using command scripts. Also, our web application interface that runs the multi-context Linux shared object version of Vensim needs to be able to issue the "simulate" command, so this bug prevents us from updating the version of the Energy Policy Simulator used by the web application interface. (A link to the interface is https://us.energypolicy.solutions/scenarios/home.) Therefore, this is a very high priority bug for us, as it blocks our release.

Past versions of the Energy Policy Simulator did not cause Vensim to crash, so there is something about the latest update to the Energy Policy Simulator that is triggering this bug in Vensim. The ideal solution might be to both fix the crash bug in Vensim (presumably in Vensim 7.0.1) and for us to work around the bug in our Energy Policy Simulator 1.3.0, so that people who are still using Vensim versions in the 6.3.x and 6.4.x series will continue to be able to run our model. But I don't currently know enough about what is causing the crash to be able to work around it. Any insight you can provide would be helpful.

I've made a work-in-progress version of the Energy Policy Simulator for you to use to demonstrate the crashing bug. You can download it from https://www.dropbox.com/s/old3gen02nzi0 ... g.zip?dl=0.

Thank you so much for any help you can provide.

Best,
Jeff

[tomfid]

I grabbed a copy, if you want to take down the file now.

It runs fine for me. I'm on 7.0 single precision, so I'll try some other permutations. Are you using single or double?

[tomfid]

Win 7.0 dp works too. Hmmm ...

[tomfid]

6.3D x64 crashes, so we may have fixed something. I'll keep testing.

[jrissman]

I tested using single precision (the default for the Vensim DSS installer) on Windows (32-bit). We also tested a 64-bit Single Precision version of Vensim DSS for Windows.

I'm not familiar with whatever is the default on the Linux multi-context shared object, but it's probably single precision as well.

[Administrator]

Can you upload or email your vensim.ini file? It might be a setting in there that is causing the problem.

You can find the file in %APPDATA%\vensim.

[tomfid]

Win 6.4E x32 sp works.

[jrissman]

Sure, here's the vensim.ini file. (I had to zip it because the forum software rejects files with an extension of ".ini").

[jrissman]

Since it looks like the bug varies by Vensim version, let me be more clear about exactly which versions we tested.

DSS 6.3C, single-precision, 32-bit, Windows: crashes

DSS 6.3G, single-precision, 32-bit, Windows: crashes

DSS 6.4D, single-precision, 64-bit, Windows: crashes

Multi-context shared object version dated 2015-08-04, 64-bit, Linux: crashes

Model Reader 6.4E, single-precision, 32-bit, Windows: works

[tomfid]

Got it. Still doesn't crash for me, but I haven't backed up very far yet.

[tomfid]

6.4a single & double work for me, even with your .ini via

Code: Select all

SPECIAL>READINI|vensim.ini
MENU>RUN|o

What OS are you on?

[jrissman]

I'm using:

Windows 10 Pro
Version 1607
OS Build 14393.1480
64-bit operating system, x64-based processor

[tomfid]

Very strange. My 64D x64 is the only overlap. Does it crash immediately on launch of the simulation? Does it immediately cause a Win fault, or go unresponsive for a while?

[jrissman]

Here is the exact sequence of events:

1. I open the model in Vensim DSS by double-clicking the .mdl file.
2. I click the "Simulate" button.
3. If there already exists a file named "MostRecentRun.vdf" from a previous model run (using SyntheSim), a dialogue appears stating "Dataset MostRecentRun already exists. Do you want to overwrite it?" I click "Yes." (If no file by this name already exists, step 3 is skipped.)
4. The Vensim box "Setting up the simulation" appears, immediately followed by a Windows error message that says "Vensim family of products has stopped working". The only option in that dialogue box is a button that says "Close program". See the following screenshot. Clicking the button causes Vensim to quit.

Error message received when Vensim crashes

VensimErrorMessage.PNG (10.32 KiB) Viewed 10887 times

[Administrator]

A couple of things.

First, move the model out of DropBox. DropBox locks files while they're being read which causes problems for other applications (including Vensim). If a run is locked as it's being synced, this can easily cause a crash.

Saying that, I'm getting the crash as well on versions of Vensim prior to 6.4D. So it's either DropBox, or a bug that we've fixed.

[tomfid]

Dropbox wouldn't explain the Linux issue however (unless run from a Win dropbox mapped as a linux drive I guess).

[jrissman]

I'm pretty sure DropBox isn't the cause of the problem. I've had DropBox forever, and it never caused Vensim to crash on any prior version of the Energy Policy Simulator (EPS). And with EPS version 1.3.0, it crashes reliably even if I disable DropBox.

It does sound like something that may have been fixed in 6.4D or 6.4E. We can buy maintenance extensions and upgrade our Windows versions of Vensim DSS to the latest version and see if that fixes it for us. We can't get a new Linux multi-context shared object version on our own. Can you send us an updated one?

I wish we had some clue about what in the model causes the crash, so that I could work around it, so the EPS would keep working with older versions of Vensim. But I know that might not be possible. It's odd, because 1.3.0 doesn't use any named functions or unusual techniques that were not used in 1.2.4.

[tomfid]

I assume you've tried a model comparison with a previous version - are there too many differences to sort it out? (I'd be happy to take a look.)

[Administrator]

I've got a feeling that it might be related to code optimisation. We sometimes find these bugs, something works fine in debug mode, but release causes a crash. I do recall one recently where a simulate caused a crash, I cannot find the relevant ticket in our bug tracking system.

Tom's suggestion is a good one, a model compare with a working one might give a clue.

[jrissman]

There were a lot of changes made at once to the model (going from 1.2.4 to 1.3.0) because I removed the entire Transportation sector and rebuilt it from scratch. So there was a significant period of model construction during which the model did not run (as not all the new variables and equations were in place yet). As soon as 1.3.0 reached the point where it could run, the crash on "Simulate" started happening. This made it difficult to tell exactly which change triggered the crash bug.

Since the model was able to run using "SyntheSim," I was able to debug 1.3.0 and prepare it for public release. I hoped that by fixing various bugs in 1.3.0 that I could detect using SyntheSim, the crash bug would disappear along the way. But that didn't happen: the problem with crashing persisted all the way until the present time, when 1.3.0 is finished and debugged.

The previous version of the EPS, 1.2.4, is publicly released. It can be downloaded by anyone from the Archived Model Releases page on our website, which is at https://us.energypolicy.solutions/docs/ ... eases.html. So if you want to compare 1.3.0 to 1.2.4 and see if you notice anything suspicious, like a badly-formed equation or file corruption, please feel free to do so!

[jrissman]

We are using five subscripts on some variables now (Vehicle Type, Pollutant, Cargo Type, Vehicle Technology, Transportation Fuel), whereas I think the maximum number of subscripts we ever applied to a single variable in 1.2.4 (and earlier) was three or four. So that is one design difference between 1.2.4 and 1.3.0.

[tomfid]

I don't see any red flags.

[jrissman]

Okay, well, let me upgrade my Vensim DSS Windows installation to 7.0 and make sure the model works for me. If it does, then let's talk about getting a new version of the Linux shared object.

[jrissman]

Well, it runs under Vensim 7.0 without crashing, but the results look crazy. Take a look at these graphs comparing CO2 Emissions by Vehicle Type, generated from Vensim 6.4E and Vensim 7.0. Both are running the same model with the same input data.

Vensim 6.4E

Vehicle CO2 Emissions under Vensim 6.4E

VehEmissions-Vensim6.4E.PNG (17.18 KiB) Viewed 10849 times

Vensim 7.0

Vehicle CO2 Emissions under Vensim 7.0

VehEmissions-Vensim7.PNG (17.7 KiB) Viewed 10849 times

I'll investigate what's going on in Vensim 7.0. Maybe fixing whatever is causing the broken behavior in 7.0 will also fix the crashing in 6.3x and early 6.4x series models.

Nonetheless, I thought you would want to know about this difference, since Vensim isn't supposed to come out with dramatically different numerical results when running the same model when upgrading to a new version of Vensim.

[jrissman]

There is something wrong with the way Vensim 7.0 is performing the "ALLOCATE AVAILABLE" function in the variable named "New Vehicles Allocated by Technology". It is not allocating any of the airplanes, freight ships, or rail, even though there is capacity for them to be allocated (and they are allocated correctly under Vensim 6.4E).

Things I've tried:

Increasing the width (up from $1 to $10,000) doesn't affect the results.

Adding $2 million to all the priorities (so that none are negative) doesn't affect the results.

Changing from integer-only allocation (shape type 13) to remove this restriction (shape type 3) doesn't fix the problem.