Feature hamocc sediment spinup #162
Conversation
Conflicts: hamocc/accfields.F90 hamocc/hamocc_init.F hamocc/inventory_bgc.F90 hamocc/mo_bgcmean.F90
…compatibility. A change to the correct value will require some re-tuning.
|
I have tested for bit-identical results for the NOINYOC compset on the T62_tn21 grid (OMIP1 simulation) and a fully coupled NorESM2 1%-CO2 simulation. By the way, the previous BLOM version that is in the master currently wouldn't compile for fully coupled compsets (variable "atm" wasn't included in use statement in hamocc4bcm) - the automated testing doesn't seem to catch such errors? |
|
Hi @JorgSchwinger , I'll try to have a look into this soon (being a bit time constrained). With regards to the compilation error: thanks for catching this. I suspect, the automated testing might not have included the right pre-processor flag(s) which would have enabled to catch this error, but I haven't looked into this, thus far. For other cases, NorESM was compiling. |
Conflicts: cime_config/buildnml hamocc/hamocc_init.F hamocc/mo_control_bgc.F90
TomasTorsvik
added
enhancement
|
|
|
The |
| @@ -173,7 +175,7 @@ SUBROUTINE HAMOCC4BCM(kpie,kpje,kpke,kbnd,kplyear,kplmon,kplday,kldtday,& | |||
| #endif | |||
|
|
|||
| #ifdef BROMO | |||
| !$OMP PARALLEL DO | |||
| !$OMP PARALLEL DO PRIVATE(i) | |||
There was a problem hiding this comment.
Separate openMP bugfix?
| @@ -353,7 +377,7 @@ SUBROUTINE HAMOCC4BCM(kpie,kpje,kpke,kbnd,kplyear,kplmon,kplday,kldtday,& | |||
| !-------------------------------------------------------------------- | |||
| ! Pass bromoform flux. Convert unit from kmol CHBr3/m^2 to kg/m^2/s. | |||
| ! Negative values to the atmosphere | |||
| !$OMP PARALLEL DO | |||
| !$OMP PARALLEL DO PRIVATE(i) | |||
There was a problem hiding this comment.
Separate openMP bugfix?
There was a problem hiding this comment.
I agree, I should have done this in a separate commit, but now I don't have the time to disentangle this so I'll leave it as it is.
|
The openMP bug fixes seem to be unrelated to the sediment spinup. Would it make sense to do this in a separate commit / PR? Probably this should also be included as a bug fix to the |
| @@ -105,6 +106,9 @@ subroutine powach(kpie,kpje,kpke,kbnd,prho,omask,psao) | |||
| ! needed for boundary layer vertilation in fast sediment routine | |||
|
|
|||
| real :: bolven(kpie) | |||
|
|
|||
| ! Set array for saving diffusive sediment-water-column fluxes to zero | |||
| sedfluxo(:,:,:) = 0.0 | |||
There was a problem hiding this comment.
Here you set sedfluxo to zero every time powach is called, but in dipowa this is written as something should be accumulated.
| sedfluxo(i,j,iv) = sedfluxo(i,j,iv) & | ||
| & + ocetra(i,j,kbo(i,j),iv) - aprior | ||
| & -(ocetra(i,j,kbo(i,j),iv) - aprior)* bolay(i,j) |
There was a problem hiding this comment.
Should this be without accumulation in sedfluxo?
There was a problem hiding this comment.
I think this is correct as it is: In powach sedfluxo is set to zero when entering the sediment. Then it is receiving a value for silicate and oxygen (but not the others) in powach. After that dipowa is called, where sedfluxo is updated in a loop. In order to avoid overwriting the values for oxygen and silicate, it is written as above.
|
Regarding the save attributes in modules: It's not true that they are redundant. The Fortran standard only guarantees that the values of module variables are "saved" if a variable is referenced in the compiled main program (same as for COMMON blocks). I don't think that any compiler would NOT save the values of module variables that are not referenced in main, but strictly speaking this is necessary (as far as I know, maybe my knowledge is outdated). |
@jmaerz I am not able to request a review from you. Maybe you can have a look nevertheless (and probably you need to be added by someone to something that you can be requested as reviewer?).