IMPORTANT change in the devel version

[Knut]

Hi all,

I just committed a necessary code change to the devel version regarding
the definition of land in GETM.

Due to a missing initialisation until now land was defined by all areas
with non-positive bathymetries. Of course this completely neglected the
flooding of mudflat areas initially being dry. NOW with the new commit
land is defined by all areas with bathymetries <= -10.

In the future this fixed setting should be changed to the missing_value
read in from the topo file. But so far this has no high priority :-)

PLEASE BE AWARE, that now there can be (more) drying and flooding in
your setups with possible stability implications!


Regards,
Knut

[Karsten Bolding]

did you check before the commit - now I get:

postinit_2d
postinit_3d
init_input
2004-01-01 00:00:00: saving 2D ....
2004-01-01 00:00:00: saving 3D ....
------------------------------------------------------------------------
integrating....
------------------------------------------------------------------------
forrtl: error (65): floating invalid

Stack trace terminated abnormally.
Aborted (core dumped)

and that is compiled without 'export FABM=true'

Karsten

--
http://www.getm.eu

[Knut]

> did you check before the commit - now I get:
>

yes with our favourite sylt :-)

> postinit_2d
> postinit_3d
> init_input
> 2004-01-01 00:00:00: saving 2D ....
> 2004-01-01 00:00:00: saving 3D ....
> ------------------------------------------------------------------------
> integrating....
> ------------------------------------------------------------------------
> forrtl: error (65): floating invalid
>
> Stack trace terminated abnormally.
> Aborted (core dumped)
>
> and that is compiled without 'export FABM=true'
>

but with -fpe0, right?
Can you do a traceback?

Knut

[Bjarne Büchmann]

Dear Knut,

Did you guard the test "<= -10." against rounding errors? No matter if the bathy is read from single or double the number "-10" cannot be represented exactly in IEEE floating point arithmetic. As a consequence, you should ensure that "-10+epsi" is also LAND. You could make the test with e.g. -9.999D0 or something similar...
I don't know how you actually implemented it, just being cautious here. And using the lists to tell people to be cautious regarding these issues.


Best,
 
Bjarne Büchmann
 Civilingeniør, PhD

Overgaden oven vandet 62 B Postboks 1919
DK - 1023 København K
TLF. +45 3268 697
B...@FRV.DK

-----Oprindelig meddelelse-----
Fra: getm-...@googlegroups.com [mailto:getm-...@googlegroups.com] På vegne af Knut
Sendt: 8. maj 2012 13:16
Til: getm-...@googlegroups.com; getm-...@googlegroups.com
Emne: [getm-devel:3086] IMPORTANT change in the devel version

[Knut]

Dear Bjarne,

> Did you guard the test "<= -10." against rounding errors? No matter if the bathy is read from single or double the number "-10" cannot be represented exactly in IEEE floating point arithmetic. As a consequence, you should ensure that "-10+epsi" is also LAND. You could make the test with e.g. -9.999D0 or something similar...
> I don't know how you actually implemented it, just being cautious here. And using the lists to tell people to be cautious regarding these issues.
>

Since the issue was also sent to the users list, indeed I did not
mention all details. The basic implemention is untouched:

where (H .gt. Hland+SMALL) az=1

The only thing I did was to initialise Hland=-10.0 instead of keeping it
uninitialised (luckily most compilers seemed to initialise it then at
least to 0.0).

Knut