Another tracer OBC bug at tile boundaries
Closed this issue · 3 comments
I have found a spot in the Arctic domain in which the value of one point inside the halo doesn't match the value in the next tile over. This is on the eastern boundary after advect_x. This point then infects the tracer update in advect_y, but only sometimes, only below k=26. I'm still investigating.
For @adcroft, this is when going back to the old FMS1 code - which made the ice troubles go away.
For an eastern boundary, the OBC code is setting T_tmp(i+1,m), where I is at the boundary. The advection algorithm sometimes uses T_tmp(i_up+1,m) which in my case is at i+2.
My attempted fix didn't fix it at all. The trouble is instead happening in remap_OBC_fields in this line:
call remapping_core_h(OBC%remap_CS, nz, h1, segment%tr_Reg%Tr(m)%tres(I,j,:), nz, h2, tr_column, &
h_neglect, h_neglect, PCM_cell=PCM)
As far as I know, it should be getting the same inputs in both tile 7 at j=122 (out of 124) and tile 11 at j=6. The k value giving trouble is at 61, with thickness 9.9999999999999995E-007. The column at j=6 does not change below the bottom, while that at j=122 does change below the bottom. This is for a 4x6 layout, at the eastern boundary, in the first timestep. Is there any reason why this should be behaving differently inside the computational domain vs. outside? @adcroft @Hallberg-NOAA
Fixed with #507