[MITgcm-devel] advection scheme 42 and 81

[Martin Losch]

Hi Dimitris,

you are right, the NOOPTFILES list would be a solution and I will probably be able to identify the responsible routines. There are other issues with this particular testreport (e.g. the dome experiment stalls somewhere in the initialization phase) that point to a compiler problem, and I don’t want to spend too much time on fixing a compiler problem (so a band aid solution would be great), but this particular problem with the destructive interaction of advection schemes could also be related to some instability in the code. I would like to hear your opinion about that: Do you think this possible and worth investigating, or do we not care about this peculiar combination of advection schemes + a peculiar computer with a peculiar compiler?

 I guess the sensible answer to this is: don't bother, but it’s such a great way to procrastinate!

Martin

> On 15. Feb 2019, at 18:57, Dimitris Menemenlis <dmenemenlis at gmail.com> wrote:
> 
> 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
> 
> _______________________________________________
> MITgcm-devel mailing list
> MITgcm-devel at mitgcm.org
> http://mailman.mitgcm.org/mailman/listinfo/mitgcm-devel