TYPE *," " statement affects calculation

[Phares__Cliff]

When I include a TYPE *,"  " statement in a routine, the algorithm converges.

When I comment out the TYPE *," " statement, the algorithm will not converge.

If I decide to leave the TYPE *,"  " statement in, can I trust the results ?

Any help is appreciated. I'm really stumped.

I have Intel Cojmposer XE 2013 for Windows with update 5 integration for Microsoft Vinsual Studio 2012, 13.0.3636.11.

I have a Windows 7 operating x64 system with 8GB RAM and an Intel Core i5 2400 CPU @ 3.1 GHz.

[TimP]

If your algorithm requires assume:protect_parens, did you set that option?

[Phares__Cliff]

I'm not aware that my algorithm requires assume:protect_parens. I guess at a solution and use a bracketed secant method to converge. I could not find in the project properties how to set assume:protect_parens. How do I know if protect_parens is required? Floating point options used are Floating point model = fast and floating point speculation = fast.

Compiler command line is : /nologo /O2 /Qdiag-disable:8290,8291,10212 /warn:unused /warn:uncalled /warn:interfaces /module:"x64\Release\\" /object:"x64\Release\\" /Fd"x64\Release\vc110.pdb" /libs:static /threads /c

Linker command line is:  /fo "x64\Release/sSTHE2.res"

I sure do appreciate your time.

[Phares__Cliff]

Sorry. Linker command is : /OUT:"x64\Release\sSTHE2.exe" /INCREMENTAL:NO /NOLOGO /LIBPATH:"C:\Users\oi8063\Documents\Visual Studio 2012\Projects\DD\LIB" /NODEFAULTLIB:"MSVCRT" /MANIFEST /MANIFESTFILE:"C:\Users\oi8063\Documents\Visual Studio 2012\Projects\Console Apps\Shell and Tube Heat Exchanger Tube Failure - Simpson\sSTHE2\x64\Release\sSTHE2.exe.intermediate.manifest" /MANIFESTUAC:"level='asInvoker' uiAccess='false'" /SUBSYSTEM:CONSOLE /IMPLIB:"C:\Users\oi8063\Documents\Visual Studio 2012\Projects\Console Apps\Shell and Tube Heat Exchanger Tube Failure - Simpson\sSTHE2\x64\Release\sSTHE2.lib" SRS_AddIns.lib

[mecej4]

If the insertion of output statements (WRITE, PRINT, etc.) alters the sequence of operation and/or results of a program, suspect errors in the program, in particular the use of uninitialized or unsaved variables. In a very small fraction of such situations, a bug in the optimizer phase of the compiler may be responsible.

To test these conjectures further, you may comment out the additional output statements and specify the option /Od (disable optimization), or use a lower lever of optimization than the one that fails to produce correct program behavior.

[Phares__Cliff]

I narrowed the lack on convergence to one TYPE *," " statement. When it is commented out - no convergence. When not commented out - convergence. All module variables which are not PARAMETERs have SAVE attribute.

One interesting observation: While waiting for forum response, I started to clean up the code by removing unused variables in the modules. I found this had an impact on whether or not the TYPE *," " statement 'worked'.

I'm not interested in portability issues. How should floating point and optimizations options be set ? Does Intel have guidance on this issue ?

[Phares__Cliff]

When the optimization is disabled with Disable (/Od), the algorithm converges with AND without the TYPE *," " statement.

I will be inspecting for the use of uninitialized variables.

I would like to set the optimizer to maximum speed and specify floating point switches to give highly accurate results. I know these attributes are conflicting but I would rather sacrifice speed than accuracy. Is the assume:protect_parens switch available from the project properties tab ?

Thank you.

[Steven_L_Intel1]

More likely your algorithm is sensitive to the choice of instructions and instruction sequence, causing small differences in calculations. When you insert TYPE statements, some optimizations can't happen or are done differently as values have to be written to memory. That your algorithm converges without optimization lends support to this suggestion. /assume:protect_parens isn't a project option, but you might want to try changing the Floating Point > Floating Point Model to "Precise" and see what that does for you.