Custom Query (2547 matches)
Results (37 - 39 of 2547)
Ticket | Resolution | Summary | Owner | Reporter |
---|---|---|---|---|
#1250 | fixed | Array bound warnings in prt_ctl_init when jpnij /= jpni*jpnj | nemo | acc |
Description |
prt_ctl_init contains assignments such as: nlditl(:) = nldit(:) which generate compiler warnings on some systems when land only regions are being discarded (i.e. jpnij /= jpni*jpnj). This occurs because the left hand side arrays are allocated in nemogcm.F90 before the mppini calls and are declared as jpni*jpnj; the right hand side arrays are decalred in dom_oce after the mppini call as jpnij. The mismatch causes run-time warning messages with some compilers which can be avoided by using assignments such as: nlditl(1:jpnij) = nldit(:) in all cases. The same changes are also needed in TOP_SRC/prtctl_trc.F90. |
|||
#1305 | fixed | Wrong maximum level for light penetration in some mpp cases | acc | acc |
Description |
The trc_oce_ext_lev function (trc_oce.F90) often computes the wrong maximum level for light penetration in mpp runs. This is because in cases with land-only regions or regions where every wet-point is above the maximum penetration depth, the zem>= zhext test is never true. In these cases the penetration level is returned as jpkm1. This leads to, at best, unnecessary calculations and may be responsible for NaNs? arising from uninitialised values in some cases. Rewriting the test from: ! Level of light extinction pjl = jpkm1 DO jk = jpkm1, 1, -1 zem = MAXVAL( fsdepw(:,:,jk+1) * tmask(:,:,jk) ) IF( zem >= zhext ) pjl = jk ! last T-level reached by Qsr END DO to ! Level of light extinction pjl = jpkm1 DO jk = jpkm1, 1, -1 IF(SUM(tmask(:,:,jk)) > 0 ) THEN zem = MAXVAL( fsdepw(:,:,jk+1) * tmask(:,:,jk) ) IF( zem >= zhext ) pjl = jk ! last T-level reached by Qsr ELSE pjl = jk ! or regional sea-bed depth ENDIF END DO fixes the problem |
|||
#1307 | fixed | Slow start-ups with v3.6 on some systems | acc | acc |
Description |
I've been experiencing very slow start-ups on a new cluster with a lustre filesystem. It turns out to be the prevalence of output statements such as: WRITE ( numond, namsplit ) in the code which write out the results of merging the new style namelists. As it stands, every processing element writes this information to the same file which is unnecessary and, it seems, liable to cause a major problem on some systems. I propose to alter all writes to numond, numoni, numonp, numont, numonb and numonc by prepending a IF(lwp). There will also be a slight change in nemogcm.F90 to make sure the first writes occur after the definition of lwp. This will mean small changes in about 113 files. I'll make the changes next week unless there are any objections. One remaining problem will be the re-occurrance of the behaviour if ln_ctl is used. Should we introduce a new lwp equivalent that isn't altered by ln_ctl? |