[MITgcm-support] Package global_ocean.cs32x15

[Entcho Demirov]

Hi Ed,

Thanks for your help. I have compiled and run the code on
"osf1_alpha_f77" system. Everything went well and the
run finished normally, though it prints messages:

forrtl: error (65): floating invalid
forrtl: error (65): floating invalid
forrtl: error (73): floating divide by zero
forrtl: error (73): floating divide by zero
NORMAL END
forrtl: info (299): 1890 floating divide-by-zero traps
forrtl: info (297): 4032 floating invalid traps

Do you think that I may ignore these messages?

Thanks again for your prompt response to my e-mail
from yesterday.

Entcho

----------------------------------------------------------------------
  Entcho Demirov                      e-mail: entcho at physics.mun.ca
  Physics and Physical Oceanography   Phone:  709-737-8834
  Memorial University
  St. John's, Newfoundland A1B 3X7    Fax:    709-737-8739
---------------------------------------------------------------------


On Thu, 28 Apr 2005, Ed Hill wrote:

> On Thu, 2005-04-28 at 16:52 -0230, Entcho Demirov wrote:
>> Hi Steph, Ed et al.
>>
>> I try to activate global_ocean.cs32x15 package on an alpha_linux_g77
>> computer. I use the standard packages.conf file in the code
>> subdirectory to generate Makefile and to compile the code. I have
>> tried to work with the both OPTFILES g77 and g77+mpi and got one
>> the same problem.
>>
>> The run crashes already at the initialization step giving an error
>> "Floating Exception". Since this kind of errors may occur everywhere,
>> I have tried to trace where the model stops. I have found that the
>> problem is related with the initialization of the the cubed-sphere
>> grid in
>>
>> file exch2_send_rs2.F
>>
>> Subroutine EXCH2_SEND_RS2,
>>
>>   line 146-147
>>
>>            val1=sa1*array1(isl,jsl,ktl)
>>       &       +sa2*array2(isl,jsl,ktl)
>>
>> It looks like that in all of the calls to this subroutine,
>> array1 and array2 are not initialized. Correspondingly the
>> value of val1 may vary from very small (O(1.e-100)) to very
>> large values (O(1.e300)). However the problem with the run
>> occurs only when the value of one of these arrays is NaN,
>> which produces the floating exception.
>>
>> Do you have an idea how I may work around this problem?
>
>
> Hi Entcho,
>
> Yes, I do know one way to work around this problem and it might help
> you.  Do you have access to a commercial (that is, an official "HP" or
> "Compaq" or "DEC") compiler for the Alpha architecture?
>
> Most of the commercial compilers for the alpha architecture have an
> option that allows floating point exceptions to result in warnings
> rather than errors that cause the program execution to halt.  And,
> unfortunately, I don't think there is any way to make the Gnu g77
> compiler behave that way -- it produces code that always halts when
> floating point exceptions occur.
>
> For instance, the "osf1_alpha_f77" optfile has:
>
>  FFLAGS='-fpe2 [...]'
>
> where the "-fpe2" flag tells the Fortran compiler to produce code that
> will ignore floating point exceptions (actually, it completely ignores
> all floating point exceptions after the first or second have happened).
>
> If you don't have access to one of the commercial alpha compilers, then
> it may be possible to re-write parts of MITgcm so that these floating
> point exceptions don't happen for you.  But that may (or may not?)
> entail a lot of work.
>
> Ed
>
> --
> Edward H. Hill III, PhD
> office:  MIT Dept. of EAPS;  Rm 54-1424;  77 Massachusetts Ave.
>             Cambridge, MA 02139-4307
> emails:  eh3 at mit.edu                ed at eh3.com
> URLs:    http://web.mit.edu/eh3/    http://eh3.com/
> phone:   617-253-0098
> fax:     617-253-4464
>
> _______________________________________________
> MITgcm-support mailing list
> MITgcm-support at mitgcm.org
> http://mitgcm.org/mailman/listinfo/mitgcm-support
>