maximum age bug

[briochemc]

Hi there,

I got bit by the age being capped. Not sure if this should be an issue here or on the ACCESS-ESM1.5 config or forums or even transferred to MOM6, but I feel it should be reported so here I am. The culprit:

MOM5/src/mom5/ocean_tracers/ocean_tracer.F90

Lines 2509 to 2525 in 6bdbdd4

	! For age tracer, limit the lower bound at 0
	! and upper bound at age_tracer_max.
	age_tracer_max = age_tracer_max_init + Time%itt0*dtts*sec_in_yr_r
	if(limit_age_tracer) then
	do n=1,num_prog_tracers
	if(T_prog(n)%name(1:3) =='age') then
	do k=1,nk
	do j=jsd,jed
	do i=isd,ied
	T_prog(n)%field(i,j,k,taup1) = max(0.0,T_prog(n)%field(i,j,k,taup1))
	T_prog(n)%field(i,j,k,taup1) = min(age_tracer_max,T_prog(n)%field(i,j,k,taup1))
	enddo
	enddo
	enddo
	endif
	enddo
	endif

For me this was an issue using ACCESS-NRI's ACCESS-ESM1.5 config because it kept capping the age I was trying to spin up using Anderson Acceleration. I would repeatedly run the 1850s but replacing the age restart file with the accelerated age, but it never reach beyond 1860 years, with lots of grid cells with exactly 1860 years.

I believe this was not caught up in ACCESS-ESM1.5 CMIP6 runs because their age was not fully spun up (reaching only about 500 years). Had the age been spun up for the preindustrial (with values reaching e.g. 2000 years), it would have been instantly modified to 1850 years right at the start of the historical runs (potentially introducing errors of many 100s of years in large parts of the deep ocean).

I understand I can turn this off with limit_age_tracer but I do feel like modifying the age is never a good idea. Shouldn't this simply trigger a warning by the end of the run instead? Additionally, shouldn't the age < 0 and age > max_age cases be treated separately?

Cheers,
Benoit

[aekiss]

Hi @briochemc, perhaps these will help?

• Age tracer reset in each IAF cycle COSIMA/access-om2#235
• incorrect initialisation for age_global #339 (comment)

[briochemc]

Thanks @aekiss for pointing me to these!

Reading your comment, it seems that you ended up not setting limit_age_tracer=.false. to avoid negative age. In my specific case I prefer setting limit_age_tracer=.false. because I prefer the age to represent the transport (including its numerics issues) than to be realistic. Hence while I have solved my specific problem, I still think the current implementation is somewhat inadequate? I think better to leave the age unaltered except by its explicit source and boundary condition, and leave sanity checks/alterations to the user of the output. Although again maybe I am still missing something. Maybe this numerics issue is unstable and the age eventually propagates large errors or "explodes" towards infinity?

[aekiss]

I'm not sure - maybe see how you go with limit_age_tracer=.false. and see if it leads to instability?