Dear RegCNET,
I am getting a bizarre error when running the "icbc" preprocessing script -- here is a snippet of the terminal output:
...
Read in fields at Date: 1979-06-15 00:00:00 UTC
Read in fields at Date: 1979-06-15 06:00:00 UTC
Read in fields at Date: 1979-06-15 12:00:00 UTC
This error suggests I'm dividing by zero somewhere, or something else illegal. I ran with the debugger (gdb), which pointed me to the "qs" calculation in the humid1fv subroutine in PreProc/ICBC/mod_humid.f90 -- line 122 in RegCM-4.3.4.
....
Read in fields at Date: 1979-06-15 00:00:00 UTC
Read in fields at Date: 1979-06-15 06:00:00 UTC
Read in fields at Date: 1979-06-15 12:00:00 UTC
Program received signal SIGFPE, Arithmetic exception.
0x0000000000487818 in mod_humid::humid1fv (t=..., q=..., p3d=..., ni=192, nj=145, nk=38) at ./mod_humid.f90:123
122 qs = sep2*satvp/(p3d(i,j,k)-satvp) ! SAT. MIXING RATIO
Missing separate debuginfos, use: debuginfo-install glibc-2.12-1.149.el6_6.9.x86_64 zlib-1.2.3-29.el6.x86_64
I put a print statement in before the qs calculation to print out i, j, k, p3d(i,j,k), and satvp to figure out which (i, j, k) value it crashes and which quantity is zero.
This is what's bizarre... When I format the print statement output (e.g., print '(3I5, 2F10.3)', i, j, ...) versus leave it unformatted (e.g., print *, i, j, ...), the icbc script seems to stop at different values of i, j, and k:
formatted: 80, 64, 37
unformatted: 80, 75, 26
Why would simply changing print statement formatting cause the script to seemingly crash in two different places?
Any insights on why else I might get a floating point (arithmetic) exception error?
Alex