New URL for NEMO forge!

Since March 2022 along with NEMO 4.2 release, the code development moved to a self-hosted GitLab.
This present forge is now archived and remained online for history.
#1538 (Array already allocated in sbc_rnf_alloc) – NEMO

Opened 9 years ago

Closed 9 years ago

#1538 closed Bug (fixed)

Array already allocated in sbc_rnf_alloc

Reported by: ufla Owned by: nemo
Priority: low Milestone:
Component: OCE Version: trunk
Severity: Keywords:


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.

Commit History (1)


trunk bugfix see #1538

Change History (8)

comment:1 Changed 9 years ago by 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')

comment:2 Changed 9 years ago by 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?

comment:3 Changed 9 years ago by 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

comment:4 Changed 9 years ago by 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

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.

comment:5 Changed 9 years ago by 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

comment:6 Changed 9 years ago by smasson

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

comment:7 Changed 9 years ago by 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.

comment:8 Changed 9 years ago by smasson

  • Resolution set to fixed
  • Status changed from new to closed

fixed in changeset:5431

Note: See TracTickets for help on using tickets.