Array already allocated in sbc_rnf_alloc

[ufla]

When running ORCA1_LIM3 in coupled mode, I get an error in sbc_rnf_alloc (sbcrnf.F90). This statement:

ALLOCATE( rnfmsk(jpi,jpj)         , rnfmsk_z(jpk)          ,     &
  &      h_rnf (jpi,jpj)         , nk_rnf  (jpi,jpj)      ,     &
  &      rnf_tsc_b(jpi,jpj,jpts) , rnf_tsc (jpi,jpj,jpts) , STAT=sbc_rnf_alloc )

returns with STAT=151, which for my compiler (Intel) means "array already allocated".

This is with trunk at revision 5423.

[cetlod]

Yes, the allocation is sometimes done twice - in sbcmod.F90 and sbcrnf.F90. Can be solved with the lines below

    sbc_rnf_alloc = 0   !  set to zero if no array to be allocated
    IF( .NOT. ALLOCATED( rnfmsk ) ) THEN
       ALLOCATE( rnfmsk(jpi,jpj)         , rnfmsk_z(jpk)          ,     &
          &      h_rnf (jpi,jpj)         , nk_rnf  (jpi,jpj)      ,     &
          &      rnf_tsc_b(jpi,jpj,jpts) , rnf_tsc (jpi,jpj,jpts) , STAT=sbc_rnf_alloc )
          !
       IF( lk_mpp            )   CALL mpp_sum ( sbc_rnf_alloc )
       IF( sbc_rnf_alloc > 0 )   CALL ctl_warn('sbc_rnf_alloc: allocation of arrays failed')
    ENDIF

[ufla]

Hi, thanks for the quick response! I'm not sure I understand why double allocation should happen in sbcmod.F90 - I see only one call to sbc_rnf_alloc, just as for the other sbc_*_alloc functions. Anyway, will your fix be committed to the trunk?

[cetlod]

The call of sbc_rnf_alloc is done in the subroutine sbc_rnf_init. The latter is call in sbcmod only if the runoff are taken into account ( ln_rnf set to true ). Even if ln_rnf is set to false, the variables rnfmsk* are still used ( equal to 0 ) - in traadv_muscl or sbcssr for example -

We have ( I see ) 2 options :

• either we allocate these variables once and then use them under the logical ln_rnf ( traadv*, sbcssr, step, ldfeiv etc...)
• or we keep the code as it is now and add the correction I proposed

Yes I will fix it in the trunk unless objections

[timgraham]

Aren't they already allocated in sbcmod if ln_rnf is false?

IF( .NOT. ln_rnf ) THEN                      ! no specific treatment in vicinity of river mouths
         ln_rnf_mouth  = .false.                     
         IF( sbc_rnf_alloc() /= 0 )   CALL ctl_stop( 'STOP', 'sbc_init : unable to allocate sbc_rnf arrays' )
         nkrnf         = 0
         rnf     (:,:) = 0.0_wp
         rnf_b   (:,:) = 0.0_wp
         rnfmsk  (:,:) = 0.0_wp
         rnfmsk_z(:)   = 0.0_wp
ENDIF

I'm still a bit confused how this can end up getting called twice as sbc_rnf_init is only called if ln_rnf is true and sbc_rnf_alloc is only called directly from sbcmod if ln_rnf is false. I think your fix will work but I don't see why it should be needed.

[cetlod]

Because there are still some inconsistencies in the code. In coupled mode, ln_rnf is forced to true when we receive runoff from OASIS.
This is done in sbc_cpl_init. The calling sequence in coupled mode is :

• you first read namsbc and get ln_rnf which can be set to false in the namelist ; then 1st call of sbc_rnf_alloc in sbcmod
• then you get runoff from oasis and then force ln_rnf to true
• this implies the call of sbc_rnf_init and then the 2nd call of sbc_rnf_alloc

[smasson]

give me 5mn to write my comments ! :-)

[smasson]

ln_rnf can now be changed by sbc_cpl_init. If you receive the runoff from the atmosphere, they are no more added to the precipitation but treated as "real" runoffs by sbcrnf. So we make sure that ln_rnf = .true. and we define another variable: l_rnfcpl = .true. which will tell to sbcrnf that runoffs array is already filled and should not be read in a netcdf file.

So a possible fix would be avoid this automatic redefinition of ln_rnf and to stop the model in sbc_cpl_init if you receive the runoffs and if ln_rnf = F. By doing this, we will make sure that the user put ln_rnf = T from the beginning.

Another fix will be to call sbc_rnf_init in any case. Inside sbc_rnf_init, you allocate the arrays, if ln_rnf is true you do the usual business, if it is false you define all arrays to 0 as actually done in sbcmod

Personally, I prefer the second solution as I don't like this the declaration of rnf arrays in sbcmod (without any clear comments to explain why we do it) outside of sbc_rnf_init.

[smasson]

fixed in changeset:5431