CFD Online Logo CFD Online URL
www.cfd-online.com
[Sponsors]
Home > Forums > OpenFOAM Installation

divide by zero FPE issue in OpenFOAM 141 MingW port

Register Blogs Members List Search Today's Posts Mark Forums Read

Reply
 
LinkBack Thread Tools Display Modes
Old   September 3, 2008, 16:18
Default Hi, All, I am running a mod
  #1
New Member
 
Allen Zhao
Join Date: Mar 2009
Location: Westmont, IL, USA
Posts: 26
Rep Power: 8
allenzhao is on a distinguished road
Hi, All,

I am running a modified version of OpenFOAM 1.4.1 cross-compiled with MingW compiler on Windows, and we have a runtime error like:

forrtl: error (73): floating divide by zero

On Windows (MingW port) his error will get triggered with or without FOAM_SIGFPE being set.

The same source code compiled with Linux/gcc can run when FOAM_SIGFPE is NOT set, but will crash in the same location when FOAM_SIGFPE is set in the env.

So obviously, this is an issue with the Foam::sigFpe::set() implementation.

Is there any special gcc switch used in the Linux compilation that allows more tolerance to division by zero?

Any suggestions?
allenzhao is offline   Reply With Quote

Old   September 4, 2008, 04:36
Default OF on Linux does not set anyth
  #2
Super Moderator
 
Mattijs Janssens
Join Date: Mar 2009
Posts: 1,416
Rep Power: 16
mattijs is on a distinguished road
OF on Linux does not set anything unless FOAM_SIGPFE is set so guess default behaviour is different. No special gcc flags are used except -O3.

All applications should run with FOAM_SIGFPE switched on anyway.
mattijs is offline   Reply With Quote

Old   September 4, 2008, 08:41
Default It appears a MinGW compiled ex
  #3
Senior Member
 
gocarts's Avatar
 
Richard Smith
Join Date: Mar 2009
Location: Enfield, NH, USA
Posts: 138
Blog Entries: 4
Rep Power: 8
gocarts is on a distinguished road
It appears a MinGW compiled executable will raise a FPE by default, so I suggest modifying the Windows FPE code to respond to the FOAM_SIGFPE. For details visit:
http://www.symscape.com/openfoam-on-windows#comment-182
__________________
Symscape, Computational Fluid Dynamics for all
gocarts is offline   Reply With Quote

Old   September 4, 2008, 17:49
Default Hi, Richard, Just tried the
  #4
New Member
 
Allen Zhao
Join Date: Mar 2009
Location: Westmont, IL, USA
Posts: 26
Rep Power: 8
allenzhao is on a distinguished road
Hi, Richard,

Just tried the modification, but my colleague just told me that the fail-out error message is exactly the same.

What we did was just to update the file, and removed all the lib/<platform> directory, and force the linking of all the libraries.

Maybe that is not enough?
allenzhao is offline   Reply With Quote

Old   September 5, 2008, 10:32
Default Hi Allen, I think your comp
  #5
Senior Member
 
gocarts's Avatar
 
Richard Smith
Join Date: Mar 2009
Location: Enfield, NH, USA
Posts: 138
Blog Entries: 4
Rep Power: 8
gocarts is on a distinguished road
Hi Allen,

I think your compiling strategy is fine - the dependency tracking works well enough that you could just recompile without forcing relinks.

I just tried forcing a floating point exception with details at:
http://www.symscape.com/openfoam-on-windows#comment-184

I found that the original version of sigFpe.C worked as expected according to the env FOAM_SIGFPE setting under Wine on Linux and Windows XP.

As I recall you are running OpenFOAM from within a fortran process - right? I wonder if that is causing a problem.

Have you tried running using a vanilla dos cmd console?
__________________
Symscape, Computational Fluid Dynamics for all
gocarts is offline   Reply With Quote

Old   September 8, 2008, 16:08
Default We got the same error when run
  #6
New Member
 
Allen Zhao
Join Date: Mar 2009
Location: Westmont, IL, USA
Posts: 26
Rep Power: 8
allenzhao is on a distinguished road
We got the same error when running from dos command.

I am reviewing the way how we build the mingw compiler: we download the vanila copy of the source code, but I have "enable_sjlj_exceptions=1" enabled for the build.

Could it be part of the issue? I guess I know too little about this sjlj exception thing - it may not be relevant at all.
allenzhao is offline   Reply With Quote

Old   September 9, 2008, 10:14
Default In building the cross compiler
  #7
Senior Member
 
gocarts's Avatar
 
Richard Smith
Join Date: Mar 2009
Location: Enfield, NH, USA
Posts: 138
Blog Entries: 4
Rep Power: 8
gocarts is on a distinguished road
In building the cross compiler I did the same as you and also used the "--enable-sjlj-exceptions" option.

If it's any help I've posted a link to the MinGW cross compiler script I used at:
http://www.symscape.com/openfoam-on-windows

The link is within the sentence "I used the build-mingw script" which is part of stage 1 of the Patch Build Process.
__________________
Symscape, Computational Fluid Dynamics for all
gocarts is offline   Reply With Quote

Old   September 9, 2008, 10:52
Default It turns out that in order to
  #8
New Member
 
Allen Zhao
Join Date: Mar 2009
Location: Westmont, IL, USA
Posts: 26
Rep Power: 8
allenzhao is on a distinguished road
It turns out that in order to use your implementation of sigFpe.C, I have to use the MingW compiler with "--enable-sjlj-exceptions".

We actually tried to disable the setjmp/longjmp option when compiling the mingw gcc, then we got these:

signals/sigFpe.C: In function 'void clearFpe()':
signals/sigFpe.C:52: error: '_clearfp' was not declared in this scope
signals/sigFpe.C:53: error: '_controlfp' was not declared in this scope
signals/sigFpe.C: In member function 'void Foam::sigFpe::set()':
signals/sigFpe.C:137: error: '_controlfp' was not declared in this scope
signals/sigFpe.C:139: error: '_EM_ZERODIVIDE' was not declared in this scope
signals/sigFpe.C:139: error: '_EM_INVALID' was not declared in this scope
signals/sigFpe.C:139: error: '_EM_OVERFLOW' was not declared in this scope
signals/sigFpe.C:140: error: '_MCW_EM' was not declared in this scope

So, it seems that these native Win32 fpe exception call is only available when setjmp/longjmp is enforced.

Don't know what it means though.
allenzhao is offline   Reply With Quote

Old   September 10, 2008, 09:28
Default This is to be expected, as the
  #9
Senior Member
 
gocarts's Avatar
 
Richard Smith
Join Date: Mar 2009
Location: Enfield, NH, USA
Posts: 138
Blog Entries: 4
Rep Power: 8
gocarts is on a distinguished road
This is to be expected, as the FPE exception trap in OpenFOAM uses the setjmp/longjmp mechanism.

If you want to pursue this route (disabling setjmp/longjmp) then comment out the body of the methods in signals/sigFpe.C to avoid the compile errors. However, I think you'll also have to address other exceptions within signals/*.C
__________________
Symscape, Computational Fluid Dynamics for all
gocarts is offline   Reply With Quote

Old   September 22, 2008, 17:13
Default Sorry, just get chance to come
  #10
New Member
 
Allen Zhao
Join Date: Mar 2009
Location: Westmont, IL, USA
Posts: 26
Rep Power: 8
allenzhao is on a distinguished road
Sorry, just get chance to come back to the topic.

I guess I have to describe some details about our application.

1) Our main executable is compiled on Windows using Intel ifort compiler, with /fpe0 or fpe1 options.

2) The executable will dynamically load the OpenFoam.dll when needed.

We found that that the Foam::sigFpe::set() is always called when the OpenFOAM.dll is loaded (using LoadLibrary()), but the Foam::sigFpe::sigFpeHandler does not get invoked at all. We reach this conclusion by writing a line at the beginning of each of the 2 functions. It is indeed true, though surprising that sigFpeHandler() was never invoked, with or without FOAM_SIGFPE set.

According to Intel's ifort documentation, with /fpe0, Intel compiler does install its own fp exception handler, though with /fpe1, the fp exception is "disabled". Is it possible that the usage of _controlfp here is conflicting with Intel's FP exception handling?

Some further observation:

1) with ifort /fpe0 (Intel FP exception is used), the application will crash with or without FOAM_SIGFPE set, in either case, sigFpeHandler does not seem to be invoked.

2) with ifort /fpe1 (Intel FP exception is supposed to get disabled), the application will continue to run with some warning when FOAM_SIGFPE is not set; but crash when FOAM_SIGFPE is set (still the cout inside sigFpeHandler does not seem to have any effect).

Is it possible that in above case, some intel provided FPE handlers are in action?

I know that these observations can be interpreted in many ways, but hopefully someone already has a solution for it.
allenzhao is offline   Reply With Quote

Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On


Similar Threads
Thread Thread Starter Forum Replies Last Post
OpenFOAM 15x MinGW Windows Port gocarts OpenFOAM Installation 1 April 17, 2009 10:41
OpenFOAM on MinGW crosscompiler hosted on Linux allenzhao OpenFOAM Installation 127 January 30, 2009 20:08
Port OpenFOAM to IBM Cell BE mgarcia OpenFOAM Installation 2 November 1, 2007 08:33
OpenFOAM Cygwin port updated to 13 brooksmoses OpenFOAM Installation 29 November 30, 2006 06:49
OpenFOAM FreeBSD port upgraded to 13 thierry OpenFOAM Installation 4 April 1, 2006 18:25


All times are GMT -4. The time now is 16:52.