[MITgcm-devel] advection scheme 42 and 81
Dimitris Menemenlis
dmenemenlis at gmail.com
Fri Feb 15 12:57:29 EST 2019
A band-aid fix would be to identify routine that causes problem and add to NOOPTFILES list in the build option file.
But I am guessing you are asking question below because yo do not want a band-aid fix.
> On Feb 15, 2019, at 8:08 AM, Martin Losch <Martin.Losch at awi.de> wrote:
>
> Hallo,
>
> I am having a problem (one of many) on our Cray CS400 computer ollie with the latest version of the cray compiler (8.7.7). This problem may have to do with a bug in the code (or in the compiler):
>
> verification experiment advect_xz fails for optimization level > 1, i.e. with -O1 it works, but with -O2 (default), it doesn’t, and the model explodes in temperature, so that the run "stops due to EXTREME Pot. Temp”. Some numerical instability develops around grid points (i,k) = ( 2, 16) in timestep 2. The two optimization level imply a lot of smaller differences, but I think it has to do with the scalar optimization level (when it move from “conservative” for -O1 to moderate” for -O2)
>
> in data we have:
> tempAdvection = 42,
> saltAdvection = 81,
> Interestingly, this problem is the same for tempAdvection = 40, 41, 50, 51, 52 but goes away when I change saltAdvection to a non-prather-scheme (i.e. with saltAdvection=80, the problem is still there, but e.g. 2, 77, 30, 33 makes it go away), also any combination of saltAdvection=81 (or 80) with anything, but the ppm/pqm schemes (40,41,42,50,51,52), seems to work.
> In summary, the combination of prather advection with ppm/pqm schemes does not work for default optimization.
>
> I think
> 1. there shouldn’t be any interaction between the schemes
> 2. if there’s something wrong with the code (memory access, floating point operations), this interaction should not depend on the (scalar) optimization levels
>
> Do you have any thoughts on this? Any comment is appreciated. I just don’t know what to do here. I could just stop investigating this and wait for the next compiler ...
>
> Martin
> _______________________________________________
> MITgcm-devel mailing list
> MITgcm-devel at mitgcm.org
> http://mailman.mitgcm.org/mailman/listinfo/mitgcm-devel
More information about the MITgcm-devel
mailing list