clcoagTend output looks bizarre

[sarambl]

Hi all! I had a quick look at the SOA_NAclcoagTend from a run I did and the other clcoagTend outputs and they look like they have some kind of numerical issue, possibly on top of the real values. I also checked the aerocom runs that @Kirkevag did and it seems to have the same issues. /projects/NS2345K/noresm/cases/NFHISTnorpddmsbcsdyn_f09_mg17_20191101

[MichaelSchulzMETNO]

Hi,

hmm--- does it also happen for other tendencies, maybe?

[sarambl]

No, not as far as I have seen! I really don't know the reason, but I'm a bit worried?

[DirkOlivie]

It might be a real error (the physics of the model really sees this strange field), but it might also be an error in the diagnostics.

There is a possibility that this error is related to the length of arrays used in the subroutines. Often arrays in the physics have lengths defined by pcols or ncol. Using pcols instead of ncol, or the inverse, has given earlier errors with similar patterns as seen here.

So we should have a look a the array-lengths in the corresponding subroutines, and check whether ncol and pcol are used correctly for this output field.

[gold2718]

@DirkOlivie , can you have a look at this in a recent run so we can see if it is fixed or needs to be fixed?

[oyvindseland]

I looked into the problem and I see it although slightly different in the historical CMIP6 simulations. It is not present in the Forces simulation even though there should not be any changes to this part. Vilje vs Betzy initialisation ?

[oyvindseland]

I checked the results more thoroughly and the problem is indeed still there.

[oyvindseland]

Likely an error in use of columns indices. No unphysical values, but some zero values that should be non-zero. If so it will change the answer.

[oyvindseland]

Hi

The error is not as straightforward as I thought, but based on results presented by Dirk and also the fact that the aerosol used inside these calculations seem to be quite dependent on core count, I think there is likely an error in the arrays that is communicated to the subroutine. module koagsub --< subroutine clcoag

[gold2718]

This is interesting. In our reproducibility testing and code review, we have found some bugs in the coag code (along with hetfrz). Doing some testing now but should have a version to look at soon. We need to discuss!

[oyvindseland]

The bug that was found in the code is the same that is giving strange output. Ie. the problem was not the output but the calculation. The fields looks correct after the bugfix

[gold2718]

fixed in #116