different answers upon removal of a "pause" statement

[Deleted_U_Intel]

I am currently developing an agent based simulation and have found a curious effect. In the set up stage of the model, I've coded output to be written to the screen; followed by a pause statement. What is curious is when I remove the pause, I get a somewhat different simulation results. What is causing this? Are there typical reasons for such behavior? Is it due to my machine having dual processors and the program runnin asynchronously? How do I find out the source of this problem?

Thank you!

John

[jimdempseyatthecove]

John,

If your program is multi-threaded then the sequence of operations may be different with PAUSE and without. Your results data may produce different values depending on the order of calculation, or, your use of shared variables is not correct causing incorrect results in one of the configurations (may error with PAUSE or may error without PAUSE, or error may very depending on sequencing).

Jim Dempsey

[gib]

Quoting - irenejohn@aol.com

I am currently developing an agent based simulation and have found a curious effect. In the set up stage of the model, I've coded output to be written to the screen; followed by a pause statement. What is curious is when I remove the pause, I get a somewhat different simulation results. What is causing this? Are there typical reasons for such behavior? Is it due to my machine having dual processors and the program runnin asynchronously? How do I find out the source of this problem?

Thank you!

John

Is your code explicitly parallelized? I presume you are generating random numbers. In certain situations where use is made of random numbers the results of computations become unrepeatable, because of the multi-threading behavior that Jim mentioned. This creates a potential difficulty for debugging such code. I have encountered this using OpenMP, but presumably it can occur whenever there is multi-threading, either explicitly in your code or behind the scenes by the compiler.

There is another, less obvious aspect to RNG in a multi-threaded context. Unless you take care there can be a severe performance degradation when the RNG is being called from different threads - this happens because each call to the RNG writes to its state variable (which may just be an integer), and memory contention can occur. For my OpenMP agent-based modeling, which makes heavy use of random numbers, I ensure that each thread uses its own RNG (not employing any Fortran intrinsics).

If you are not generating random numbers this is all irrelevant.

Gib

[jimdempseyatthecove]

I would suggest you look very carefully at the code changes you made to initialize those varaibles. If you simply "fixed" the code by inserting Variable=0 then the fix will not be correct when the called subroutine is expecting an input value as opposed to a default initialization of 0. When a subroutine expects an initial value to be 0 then it is best to insert the initialization into the subroutine as opposed to making it a requirement of the caller. Note, do not blindly make this change as you may also have exception cases where the initial value is not 0 (e.g. pass in a partial sum). Lack of "curious effect" may indicate you are now consistantly wrong, or worse intermittantly wrong. Also, do not rely on the comments explaining the argument list. Look at the code not only in the subroutine but also in all calls to the subroutine. Somtimes an extension may be added to the functionality of the subroutine without the corrisponding documentation in the comments.

Jim Dempsey