DLL vs Vensim Behavior

[aliakhavan89]

I've been working on a version of the world dynamics model that uses analytical formulation instead of hand-crafted manual table functions, and under certain conditions, DLL throws a 'float divide by zero' whereas Vensim goes through the simulation without raising any errors. While I can't share a replicable version for DLL now, I'm sharing the mdl with the CIN file responsible for the dll error.

The part that I'm suspicious of is the order of mathematical operations or something related to that. The equation for 'POLCM pollution from capital multiplier' is given by:

Code: Select all

min16 + ((max16-min16)/(1+((max16-ry16)/(ry16-min16))^(("CIR capital-investment ratio"/CIR normal-M16)/(rx16-M16))))

which should be equal to this:

Screenshot 2025-03-08 at 11.40.37 AM.png (105.66 KiB) Viewed 9991 times

In the .cin file I've shared, I think dll throws the error when r_x_16 = M_16 = 1. I'm not sure why the error isn't raised in Vensim itself. There could be something else I'm missing (even in other parts of the mode), but inconsistent order of operations was the first thing that came to my mind. I would appreciate any feedback.

[aliakhavan89]

Additional notes: The error above, which was only raised by dll, was explicitly reported as a division by zero. Now, please use the new attached cin file to reproduce 'float invalid operation' that is only raised by dll not Vensim. The reason for getting this is error is that if you focus on the equation for BRMMT, you would see:

Code: Select all

Min(1.2, max(0.7,a5*(((ry5-c5)/a5)^(MSL material standard of living/rx5)) + c5))

which is what I manually added to keep the boundaries of the function similar to the original table functions in world dynamics. If ry_5 = c5 and a5 = 0, (ry5-c5)/a5) is undefined. DLL catches that even with Min/Max that I added, but not Vensim. Vensim only throws the error if the equation is explicitly written as:

Code: Select all

a5*(((ry5-c5)/a5)^(MSL material standard of living/rx5)) + c5

I'm not sure if the error messages from dll are coming from our program or they're built in the dll, but the error messages don't match.
dll message: OSError: exception: float invalid operation
Vensim message: Floating point overflow

But I guess the most important issue is the inconsistency in raising the error in general.

[Administrator]

Sorry, I'm confused. You mention you cannot share a version that throws the FP error in the DLL, I'm not sure what we can do to assist.

I'd start by simplifying the equation for "POLCM pollution from capital multiplier". There are a number of places in that where an FP error can happen. Anything that could generate division by zero. Plus also the power, if the numbers are too large, that will cause overflow. Things like "ry16-min16", move them to a separate variable so you can easily see what is causing this.

[aliakhavan89]

That's okay. I guess I'm reporting a bug. division by zero happens in the power (base^power) but vensim doesn't raise any error. At least this is my understanding. I have attached the same equation. Could you please explain why rx16 = M16 doesn't throw a division by zero error?

[Administrator]

I get a floating point error when I run it.

Code: Select all

ERROR:       Floating point error computing - y - at time = 0.000000.    
INFO:        Trying to save the results anyway
INFO:        Simulation and save took 2.156 seconds
INFO:        PeakWorkingSetSize: 167.383 MB
INFO:        WorkingSetSize: 124.150 MB
INFO:        GV.sim_vals_blk 0.100 MB

[aliakhavan89]

Interesting. You're right. I get an error on Windows too but not on Mac

Screenshot 2025-03-10 at 9.56.01 AM.png (1.2 MiB) Viewed 9361 times

Screenshot 2025-03-10 at 9.56.59 AM.png (353.42 KiB) Viewed 9361 times

[Administrator]

Throws a FP error as well for me on MacOS (15.3.1).

Are you on the latest MacOS? It's entirely possible that Apple have changed default behaviour in a system library again.

Code: Select all

INFO:        
INFO:        ERROR: Floating point error computing : y
INFO:        ERROR: Check causes and uses of y for division by zero or overflow
INFO:        
ERROR:       Floating point error computing - y - at time = 0.000000.    
INFO:        Trying to save the results anyway

[aliakhavan89]

macOS sequoia 15.3.1

Please see this:

https://youtu.be/qywCbmphC5I

Note that the first test is on my MacBook Pro M3, macOS 15.3.1, but the second one is on a windows machine (Intel) using Remote Desktop.

FYI, Parallels Desktop (on macOS), doesn't throw FP either, so it could be related to ARM or Apple.

If it is related to Apple, I'd really appreciate it if you could explain the details and specifics on how exactly this error happens. This can help researchers like me avoid getting caught in these issues.

Also, note that the same equation and parameters throw a division by zero on Excel on Mac!

Screenshot 2025-03-10 at 12.34.45 PM.png (328.1 KiB) Viewed 9262 times

[Administrator]

The model you sent operates in exactly the same way for me on MacOS and Windows.

I'm not sure what else I can suggest. I'm on a M1 processor Mac.

[aliakhavan89]

The original test I did was on M3, macOS 15.3.1, and Vensim 10.2.2. I just tested it on an M4 machine (but still on macOS 15.3.1) and Vensim 10.1.3. It doesn't throw an FP error either. So, I'm not suspecting Vensim or the build version anymore. Which macOS are you using?

At any rate, do you have any specific check inside the source code for division by zero? If not, could you please include it, rather than relying on platform-specific libraries, so that we have consistent behavior across different environments?

FYI, I crated the simplest test: (1/0)^(-2).

See this:

https://youtu.be/r7-pexr-Nd4

Finally, I'm not an expert so I can't tell if Excel or Calculator use the same libraries like Vensim for such operations, but Vensim is the only application that generates this unusual behavior.

Screenshot 2025-03-11 at 1.53.18 PM.png (238.37 KiB) Viewed 8376 times

[Administrator]

I'm totally confused. I've just run your minimal fp model on MacOS and Windows. In both cases, it gives the same correct behaviour, a floating point error at time = 0.

Can you explain why this is incorrect?

[aliakhavan89]

Did you see that I don’t get the error?

[Administrator]

Sorry, I'm struggling to follow this thread.

I see in the video that no error appeared. I cannot think of a reason why as it appears fine for me on both Apple Silicon and Intel. Could your Mac be running the Intel binary instead of the Apple silicon one? That would explain it, FP errors on Apple Silicon have to be handled in a different way to Intel.

[aliakhavan89]

It now throws an error on 10.3.0.

I agree with you. it might be the difference between ARM & Intel. Now that I installed 10.3.0, Mac throws an error (which is what we expect).

But I have a VM on Mac (Windows 11 using Parallel Desktop). The VM still has the same problem (not throwing an FP error) with the same model. I assume the code is getting translated in a weird way.