"Too many negatives" failure in atmos_main

Hi,

I’m attempting an AMIP timeslice run on Monsoon (u-ck729) using timeslice Ancils and emissions files. Atmos_main starts but after about 100 timsteps (~36 - 42 hours model time), I start getting the following message in pe_output:

[1] Negatives - exceeds maxneg
[1] Too many negatives (>2000) in spimpmjp (iter 7) lon= 11 lat= 0; halving step

This causes the model to run very slowly and eventually time out on the wallclock. It only occurs on some timesteps as well.

After some testing, I think this is a problem with my emission files as the model runs fine when I use standard CMIP6 emission files. I don’t think it is a problem with the branch either because other runs using different emissions but the same branch and chemistry work fine. I have checked my emission input files and there do not appear to be any negative values in them (the minimum value in all cases is 0).

Have you seen anything like this before? Would you recommend any other tests to diagnose this problem?

Many thanks,

James

Hi James,

This is an error from the UKCA chemical solver. This number (maxneg) was last increased when the CRI-Strat (v1) mechanism was added I think. What is probably happening is that the new emissions are leading to some more vigorous chemistry, which makes it harder to solve and causing the model to do halving steps prior to non-convergence. Lots of halving steps slow the model down a lot.

You could try upping the value of maxneg to see if that helps - that basically tells the solver to ignore the number of negatives and carry on. I’m not sure if it prints out how many negatives there are, but you could add that in as well to see just how much over you are going.

Best wishes,
Luke

Hi Luke,

Thanks for this. I’ll try changing maxneg - do you know where I can find it?

The pe_output prints out: “Too many negatives (>2000), Negatives - exceeds maxneg”

Best wishes,

James

Sorry, found it in asad_spimpmjp.F90 after a grep. Will increase it and see how it goes.

James

Great - you should also write out count_negatives as this is the number of negatives that is being checked against maxneg.

Best wishes,
Luke

Thanks, Luke, this worked when I increased maxneg to 5000. I printed the number of negatives and in most cases when this was non-zero, it tended to be 10-100 but in a few case was up to / over 1000. There just a few over 2000 and none over 2200 so I think I was just over the limit. Is there any advantage to keeping maxneg as low as possible in terms of accuracy of the solver? If so I could reduce maxneg from 5000 to say 3000.

Best wishes,

James

I’d probably put it to 2500 or 3000. I’m not sure if there are any particular advantages, it’s about how many negatives you think the mechanism can cope with before it halves the timestep. We’ve found that the larger the mechanism the more negatives it could get. If the solver can’t converge you’ll get a different error, so it must be converging OK after this point.

Best wishes,
Luke

Hi Luke,

Will do, thank you very much for your help.

James