Ocean Modeling Discussion

I installed the up-to-date ROMS from GitHub.
Below are three sections that should be included only under the SOLVE3D flag.
Yan

Utility/wrt_his.F
#ifdef SOLVE3D
USE extract_slice_mod, ONLY : extract_slice
#endif

Utility/wrt_quick.F
#ifdef SOLVE3D
USE extract_slice_mod, ONLY : extract_slice
#endif ...

Hi Zeng,
The .in file has NRREC == -1 for perfect restart, which looks for rzeta. If the initial file does not have that, you may try NRREC == 0.
Yan

Hi John,
1. Yes, it seems that ifort cannot do "DO i=1,0".
2. ic has an assigned value of 5, but since the do loop does not work (with ifort), isTvar is not assigned in the right way. That causes further problems anywhere using isTvar.
Thank you,
Yan

Hi All,
The problem comes from the variable MT defined in mod_param.F.
For version 3.8 and earlier, it is assigned as below
#if defined IS4DVAR || defined W4DVAR || defined W4DPSAS
MT=MAX(NAT,MAXVAL(NT))
#else
MT=MAX(2,MAXVAL(NT))
#endif

Starting from version 3.9, it is assigned only as
MT=MAX ...

Hi All,
I installed ROMS on the other HPC, also compiled with ifort (different version), still shows the same problem. However, it works when compiled with pgi. For the ifort compiles, I just use the original Linux-ifort.mk file, no additional flag is added or changed. Still looking for a solution ...

Hi Hernan,
Thanks for the suggestions. I am sure the roms.in and varinfo.dat are copied or cited from the corresponding version folder. I also tested the SOLITON case, it has the same problem.
Yan

Hi John,
Line 904 is 'isWvel=ic+1' in mod_ncparam.f90
Yan

Hi all,
I installed the newest version of ROMS and tried to run an old case of mine. The model runs OK under 3D mode. However, if undefined SOLVE3D, it reports 'segmentation fault' in the error file. Below is one part from the file
forrtl: severe (174): SIGSEGV, segmentation fault occurred
Image PC ...

According to the log file, the model loaded in the next boundary file name correctly. But the Tmin, Tmax, and ntime reported from get_cycle.F are still from the first boundary file. I noticed this because my next boundary file should have a longer ntime. Chasing down this, I found the ncid used by ...

I updated my ROMS to the newest version recently, with file /Utility/inquiry.F But it could not read in multiple boundary files correctly. Which previously works fine. And the older version has file /Utility/inquire.F
The inquiry.F file could not update the ncid to the second boundary.nc file, it ...

If using dye with nesting grids, some of the active tracers may not be written out properly, even with the corresponding switches turn on.
The bug comes from miss using Ltracer under case(‘Hout(idTvar)’) in read_phypar.F. If turn on dye, the size of Ltracer is larger than NAT*Ngrids. However, when ...

Below are what I found recently,

Line 609 'R.x_rho' should be 'R.x_psi';
line 610 'G(dg).y_rho(:)' should be 'G(dg).y_psi(:)', and 'R.y_rho' should be 'R.y_psi';
line 753~755 'FCr' should be 'FSr'.

Yan