
#2212 closed Defect (fixed)
12 months runoff hard coded...
Reported by: | smasson | Owned by: | ![]() |
---|---|---|---|
Priority: | low | Milestone: | |
Component: | SBC | Version: | trunk |
Severity: | minor | Keywords: | |
Cc: | rblod | Branch review: | |
MP ready?: | Task progress: |
Description (last modified by nicolasmartin)
Context
Reported by Rachid: in sbc_rnf_init, the use of 12 record runoff files is hard coded…
Indeed we have a nice hard coded declaration…
REAL(wp), DIMENSION(12) :: zrec ! times records
No need to say that there is no call to any warning/stop or any comment to warn people about this hard coded definition…
This zrec is required but, in fact, not needed in iom_gettime:
CALL iom_gettime( inum, zrec, kntime=nbrec)
nbrec is next used to allocate a 3D array zrnfcl(jpi,jpj,nbrec) without any test on the error status exit… I let you imagine what happen when nbrec = 365…
Cherry on the cake: this 3D array is not needed as the iom_get is done in a temporal loop:
DO jm = 1, nbrec CALL iom_get( inum, jpdom_data, TRIM( sn_rnf%clvar ), zrnfcl(:,:,jm), jm ) END DO
Last point, iom_gettime mix-up unlimited dimension size with a time axis variable… this routine requires an input array (that is in fact never used) which size is not know when calling iom_gettime…
Analysis
Clean up all this mess…
Recommendation
Dont't let this king of crappy code to be commited…
Commit History (2)
Changeset | Author | Time | ChangeLog |
---|---|---|---|
10523 | smasson | 2019-01-16T10:36:03+01:00 | trunk: avoid the allocation of potentialy large array in sbcrnf, see #2212 |
10522 | smasson | 2019-01-16T09:35:15+01:00 | trunk: replace iom_gettime by iom_getszuld, see #2212 |
Change History (5)
comment:1
Changed 2 years ago by smasson
comment:2
Changed 2 years ago by smasson
[10522] : first step: get rid of iom_gettime to avoid the use of an array which size is unknown…
comment:3
Changed 2 years ago by smasson
In 10523:
comment:4
Changed 2 years ago by smasson
- Resolution set to fixed
- Status changed from new to closed
comment:5
Changed 2 years ago by nicolasmartin
- Description modified (diff)
In 10522: