Custom Query (2547 matches)
Results (28 - 30 of 2547)
Ticket | Resolution | Summary | Owner | Reporter |
---|---|---|---|---|
#1223 | fixed | Surface pressure gradient error | acc | JohnSiddorn |
Description |
Line 136 in the DYN/dynspg.F90 routine at NEMO3.6 updates the surface pressure trend for v twice, rather than for u.
|
|||
#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? |