noisy vertical velocity in deep bathymetry and uv with high value
-
- Posts: 31
- Joined: Thu Sep 21, 2023 2:52 pm
- Location: Sun Yat-sen University
noisy vertical velocity in deep bathymetry and uv with high value
Dear ROMS users:
I'm back. In my previous post:viewtopic.php?p=25370#p25370, the problem may not have been described clearly. I have made a lot of attempts during this period, and I would like to describe my running process in more detail. There may be other users who encounter the same problem, and we can discuss it together.
First, a well-behaved terrain reduces the potential risk of model blowup. GridBuilder is really a powerful tool for generating ROMS grids, and I also wrote a matlab script to modify the land elevation of the generated grid to the minimum water depth, and made appropriate smoothing in the place where the slope of the terrain changed too much, and got a grid with good performance of various parameters - it was not overly smooth, and the grid stiffness and orthogonality were not crazy.
I then used roms_clm/roms_master_climatology_coawst_mw.m to make ini, bdy and clm files (from hycom), and used my own script with mtools/create_roms_forcings to generate the surface force file (source ERA5). I have carefully examined these files and found that the zeta data seems to be somewhat discontinuous(shown below)... I'm not sure if this is the hycom dataset as it is or if there was an error in my interpolation process.
I now have a delicate problem: as stated earlier, I changed all the land elevation in the grid to the minimum water depth (hmin = 5m in my example), because as far as I know, the ROMS calculates all the points in the model domain and then masks out the result of the land. Therefore, in the model domain, no h < 0 can occur. What makes me uneasy, however, is that there are actually some very high mountains in my model domain, and the ERA5 data shows that the pressure in these places is much lower than the typical value of 1000mb at sea level. Since my forcing files are interpolated from ERA5 data in the grid, could these false low pressures be a potential cause of ROMS blowup?
Finally, I ran a real case for ten days, and although it ran smoothly, I found that the maximum of the horizontal flow field far exceeded that of the real ocean, and there was vertical flow noise in the bottom ocean near the eastern boundary. What are the underlying reasons for this phenomenon? Should I try to improve the flow behavior at the boundary with nudge and sponge? I also tried to enable UV_U3ADV_SPLIT and UV_VIS4 to improve fake mixing, but without success. Also, my maximum 2D uv speed can reach 1, which doesn't seem very normal either.
My operation log and various files are attached below. Any kind reply would be most appreciated.
I'm back. In my previous post:viewtopic.php?p=25370#p25370, the problem may not have been described clearly. I have made a lot of attempts during this period, and I would like to describe my running process in more detail. There may be other users who encounter the same problem, and we can discuss it together.
First, a well-behaved terrain reduces the potential risk of model blowup. GridBuilder is really a powerful tool for generating ROMS grids, and I also wrote a matlab script to modify the land elevation of the generated grid to the minimum water depth, and made appropriate smoothing in the place where the slope of the terrain changed too much, and got a grid with good performance of various parameters - it was not overly smooth, and the grid stiffness and orthogonality were not crazy.
I then used roms_clm/roms_master_climatology_coawst_mw.m to make ini, bdy and clm files (from hycom), and used my own script with mtools/create_roms_forcings to generate the surface force file (source ERA5). I have carefully examined these files and found that the zeta data seems to be somewhat discontinuous(shown below)... I'm not sure if this is the hycom dataset as it is or if there was an error in my interpolation process.
I now have a delicate problem: as stated earlier, I changed all the land elevation in the grid to the minimum water depth (hmin = 5m in my example), because as far as I know, the ROMS calculates all the points in the model domain and then masks out the result of the land. Therefore, in the model domain, no h < 0 can occur. What makes me uneasy, however, is that there are actually some very high mountains in my model domain, and the ERA5 data shows that the pressure in these places is much lower than the typical value of 1000mb at sea level. Since my forcing files are interpolated from ERA5 data in the grid, could these false low pressures be a potential cause of ROMS blowup?
Finally, I ran a real case for ten days, and although it ran smoothly, I found that the maximum of the horizontal flow field far exceeded that of the real ocean, and there was vertical flow noise in the bottom ocean near the eastern boundary. What are the underlying reasons for this phenomenon? Should I try to improve the flow behavior at the boundary with nudge and sponge? I also tried to enable UV_U3ADV_SPLIT and UV_VIS4 to improve fake mixing, but without success. Also, my maximum 2D uv speed can reach 1, which doesn't seem very normal either.
My operation log and various files are attached below. Any kind reply would be most appreciated.
-
- Posts: 31
- Joined: Thu Sep 21, 2023 2:52 pm
- Location: Sun Yat-sen University
Re: noisy vertical velocity in deep bathymetry and uv with high value
I took further steps to improve my run.
1. I tried to add the nud.nc to improve my boundary conditions, although I don't know if it's really a problem. I set outer = 1/5, inner = 1/60, and width = 8 by using d_nudgcoef.m to generate a nudge file with linearly reduced nudgcoef from the boundary to the model's internal field. After adding this file, the model was able to run stably for longer, but eventually blew up after 39 days.
2. I also tried to shorten the time step from 180s to 150s, but this did not make a significant difference and the model still blew up on day 39. Given that my spatial resolution is 3km, I don't think further narrowing the time step will help much.
The main problem I am facing now is that the temperature and salinity field shown in his.nc seem to have no big problems, but the velocity is generally too large, and the maximum value can reach 2m/s. Next, I might try it in two directions: enlarging the nudge region, for example, by making width = 10, and making the outer and inner time scales shorter, bringing them closer to the 3D climatology; Or try to increase the drag coefficient and reduce the velocity. I'll show my results later.
If I do something unreasonable or have any better suggestions for improvement, I sincerely hope that all ROMS experts will remind me.I have attached the roms.log of the latest run below.
1. I tried to add the nud.nc to improve my boundary conditions, although I don't know if it's really a problem. I set outer = 1/5, inner = 1/60, and width = 8 by using d_nudgcoef.m to generate a nudge file with linearly reduced nudgcoef from the boundary to the model's internal field. After adding this file, the model was able to run stably for longer, but eventually blew up after 39 days.
2. I also tried to shorten the time step from 180s to 150s, but this did not make a significant difference and the model still blew up on day 39. Given that my spatial resolution is 3km, I don't think further narrowing the time step will help much.
The main problem I am facing now is that the temperature and salinity field shown in his.nc seem to have no big problems, but the velocity is generally too large, and the maximum value can reach 2m/s. Next, I might try it in two directions: enlarging the nudge region, for example, by making width = 10, and making the outer and inner time scales shorter, bringing them closer to the 3D climatology; Or try to increase the drag coefficient and reduce the velocity. I'll show my results later.
If I do something unreasonable or have any better suggestions for improvement, I sincerely hope that all ROMS experts will remind me.I have attached the roms.log of the latest run below.
- Attachments
-
- roms.log
- (10.23 MiB) Downloaded 290 times
-
- Posts: 31
- Joined: Thu Sep 21, 2023 2:52 pm
- Location: Sun Yat-sen University
Re: noisy vertical velocity in deep bathymetry and uv with high value
The latest running were successfully completed, and it seems that expanding the nudging area and increasing the drag coefficient can help. But I still have a few questions:
1. in my .in file, my timestamp is set as follows:
2. The results show that the temperature and salinity fields are relatively normal, but the flow velocity fields still show some surprisingly high values: for example, the maximum u can reach 1.7m/s, and the maximum v can reach 2m/s. Compared with the maximum values corresponding to HYCOM (u~0.8m/s, v~1.5m/s), it seems somewhat abnormal, considering the data assimilation of HYCOM data, I think my running result is barely acceptable. Do you have any idea about it?
3. In fact, what is more difficult to accept than horizontal uv is the performance of vertical velocity w. I found a spurious strong vertical mixing at deeper water depths, especially at the southeastern boundary, where maximum flow rates could reach 10-2m/s! Considering that the maximum magnitude of upwelling is only in the order of 10-3m/s, I have no idea why this phenomenon occurs. Do you have any better suggestions ROMS experts? If necessary, I will provide you with more details for diagnosis.
1. in my .in file, my timestamp is set as follows:
This means that I want to use matlab canlendar to represent the time the pattern runs, not Julian Day or modified Julian Day. The time period I want to simulate is 2023/06/21/00-2023/07/30/00. As far as I know, the start time of matlab is 0000-01-00 00:00:00, and the datenum function is used to represent 2023.06.21.00 to get the result 739058:! Time-stamp assigned for model initialization, reference time
! origin for tidal forcing, and model reference time for output
! NetCDF units attribute.
DSTART = 739058.0d0 ! days
TIDE_START = 0.0d0 ! days
TIME_REF = 00000100.0d0 ! yyyymmdd.dd
So, is there something wrong with my Settings? Why is my roms.log showing that the model is running from 2024-06-22?>> datenum(0000,01,000,0,0,0)
ans =
0
>> datenum(2023,06,21,0,0,0)
ans =
739058
2. The results show that the temperature and salinity fields are relatively normal, but the flow velocity fields still show some surprisingly high values: for example, the maximum u can reach 1.7m/s, and the maximum v can reach 2m/s. Compared with the maximum values corresponding to HYCOM (u~0.8m/s, v~1.5m/s), it seems somewhat abnormal, considering the data assimilation of HYCOM data, I think my running result is barely acceptable. Do you have any idea about it?
3. In fact, what is more difficult to accept than horizontal uv is the performance of vertical velocity w. I found a spurious strong vertical mixing at deeper water depths, especially at the southeastern boundary, where maximum flow rates could reach 10-2m/s! Considering that the maximum magnitude of upwelling is only in the order of 10-3m/s, I have no idea why this phenomenon occurs. Do you have any better suggestions ROMS experts? If necessary, I will provide you with more details for diagnosis.
- Attachments
-
- roms.log
- (9.78 MiB) Downloaded 257 times
Re: noisy vertical velocity in deep bathymetry and uv with high value
Your choice of reference time is not recommended. See viewtopic.php?p=119#p119
Since you are working with MATLAB, you can easily convert a chosen reference time to datenum convention
In ROMS, e.g.:
TIME_REF = 20240101.00
In MATLAB:
>> dnum = datenum(2024,1,1) + ocean_time/86400;
But in MATLAB, consider using the datetime object instead. It's much more versatile.
Since you are working with MATLAB, you can easily convert a chosen reference time to datenum convention
In ROMS, e.g.:
TIME_REF = 20240101.00
In MATLAB:
>> dnum = datenum(2024,1,1) + ocean_time/86400;
But in MATLAB, consider using the datetime object instead. It's much more versatile.
John Wilkin: DMCS Rutgers University
71 Dudley Rd, New Brunswick, NJ 08901-8521, USA. ph: 609-630-0559 jwilkin@rutgers.edu
71 Dudley Rd, New Brunswick, NJ 08901-8521, USA. ph: 609-630-0559 jwilkin@rutgers.edu
-
- Posts: 31
- Joined: Thu Sep 21, 2023 2:52 pm
- Location: Sun Yat-sen University
Re: noisy vertical velocity in deep bathymetry and uv with high value
Thanks for your reply wilkin. I'll look into it.
Re: noisy vertical velocity in deep bathymetry and uv with high value
Just my two cents:
1. Be careful when interpolating from the global atmospheric data, especially near the coastal region. Meteorology field can be significantly different between neighboring grids. ERA5 provides well-documented definitions for land/sea grids (https://confluence.ecmwf.int/display/FU ... d-Sea+Mask).
2. Base on your research purpose, are isolate islands important to consider? If not, how about manually mask them as the ocean?
3. Have you checked the B.C. of southeast? ROMS diagnoses the vertical velocity from uv, where uv are calculated from the pressure field derived from t, s and zeta. I would advise you to carefully check each field step by step.
1. Be careful when interpolating from the global atmospheric data, especially near the coastal region. Meteorology field can be significantly different between neighboring grids. ERA5 provides well-documented definitions for land/sea grids (https://confluence.ecmwf.int/display/FU ... d-Sea+Mask).
2. Base on your research purpose, are isolate islands important to consider? If not, how about manually mask them as the ocean?
3. Have you checked the B.C. of southeast? ROMS diagnoses the vertical velocity from uv, where uv are calculated from the pressure field derived from t, s and zeta. I would advise you to carefully check each field step by step.
-
- Posts: 31
- Joined: Thu Sep 21, 2023 2:52 pm
- Location: Sun Yat-sen University
Re: noisy vertical velocity in deep bathymetry and uv with high value
Thank you wenpu. Very nice suggestion. I will try these suggestions slowly. If these makes my running better, I will show it.
-
- Posts: 31
- Joined: Thu Sep 21, 2023 2:52 pm
- Location: Sun Yat-sen University
Re: noisy vertical velocity in deep bathymetry and uv with high value
I recently went over my bdy and clm.nc and unfortunately they all seem to be in order, especially at the eastern and southern boundary. I don't know if I'm reading this wrong, but the presence of such a large vertical velocity at the near bottom of the southern boundary is really puzzling to me. I attach my bdy, clm and forcing.nc here, and I sincerely hope that you can help me to make a diagnosis
- Attachments
-
- ROMS_forcing.rar
- (1.41 GiB) Downloaded 550 times
-
- bdy and clm in first 10 days.rar
- (1.79 GiB) Downloaded 470 times
- arango
- Site Admin
- Posts: 1368
- Joined: Wed Feb 26, 2003 4:41 pm
- Location: DMCS, Rutgers University
- Contact:
Re: noisy vertical velocity in deep bathymetry and uv with high value
To me, the behavior of vertical velocity near the open boundary is the byproduct of the lateral boundary conditions. Recall that in ROMS, the vertical velocity (omega) is an expression of the 3D continuity equation computed by the horizontal divergence. There must be some vertical biases in your climatology and boundary data that cause such behavior. This is deep water, and there may be a water masses mismatch between the model and data that causes such a violent response to equilibrium.
Are you applying a sponge region next to the open boundary conditions?
Are you applying a sponge region next to the open boundary conditions?
-
- Posts: 31
- Joined: Thu Sep 21, 2023 2:52 pm
- Location: Sun Yat-sen University
Re: noisy vertical velocity in deep bathymetry and uv with high value
Thanks for your reply arango! Yes, as you said, the vertical velocity is calculated from the three-dimensional continuity equation by the horizontal divergence. The water mass mismatch between the model and the data should be the main reason for the abnormally high omega values in the deep water.
You also mentioned sponge. It occurred to me that warner had suggested this before, but I didn't use sponge because I didn't know much about it. By reading add_sponge.m, I found that if I want to apply sponge to a specific area, I need to enter the corresponding visc_factor and diff_factor. For my example, I set VISC2 == 5.0d0 and TNU2 == 2*0.0d0, so how should the corresponding visc_factor and diff_factor be set? Could you give me some advice?
You also mentioned sponge. It occurred to me that warner had suggested this before, but I didn't use sponge because I didn't know much about it. By reading add_sponge.m, I found that if I want to apply sponge to a specific area, I need to enter the corresponding visc_factor and diff_factor. For my example, I set VISC2 == 5.0d0 and TNU2 == 2*0.0d0, so how should the corresponding visc_factor and diff_factor be set? Could you give me some advice?
-
- Posts: 31
- Joined: Thu Sep 21, 2023 2:52 pm
- Location: Sun Yat-sen University
Re: noisy vertical velocity in deep bathymetry and uv with high value
Hey guys, I've got a new problem.
now I would like to try to run ROMS by adding wave data to my forcing.nc to see wave effects on current. To do this, I defined CPP:
and I added wec boundary condition to .in file:
now I would like to try to run ROMS by adding wave data to my forcing.nc to see wave effects on current. To do this, I defined CPP:
#define WEC_VF
#define WDISS_THORGUZA
and I added wec boundary condition to .in file:
However, when I started running, something strange happened, the ROMS seemed to have an error reading the lateral boundary condition, and when I looked at the log file, I found:! Wec boundary conditions
LBC(isU2Sd) == Shc Shc Shc Shc ! 2D U-stokes
LBC(isV2Sd) == Shc Shc Shc Shc ! 2D V-stokes
LBC(isU3Sd) == Rad Rad Rad Rad ! 3D U-stokes
LBC(isV3Sd) == Rad Rad Rad Rad ! 3D V-stokes
I look for previous posts. It seems that no one has made such errors as me. Do you have any ideas?ubar_stokes 1 a ðaUbU ^@^@^@^@^@ ^@ @^@ @^@ @^@ @ Nud Rad + Nud Rad + Nud
vbar_stokes 1 Shchepetkin Shchepetkin Shchepetkin Shchepetkin
u_stokes 1 Shchepetkin Shchepetkin Shchepetkin Shchepetkin
v_stokes 1 Radiation Radiation Radiation Radiation
...
===================================================================================
= BAD TERMINATION OF ONE OF YOUR APPLICATION PROCESSES
= PID 97058 RUNNING AT HeadNode
= EXIT CODE: 139
= CLEANING UP REMAINING PROCESSES
= YOU CAN IGNORE THE BELOW CLEANUP MESSAGES
===================================================================================
YOUR APPLICATION TERMINATED WITH THE EXIT STRING: Segmentation fault (signal 11)
This typically refers to a problem with your application.
Please see the FAQ page for debugging suggestions
- Attachments
-
- withwave.in
- (143.52 KiB) Downloaded 235 times
-
- roms.log
- (67.65 KiB) Downloaded 233 times
-
- Posts: 31
- Joined: Thu Sep 21, 2023 2:52 pm
- Location: Sun Yat-sen University
Re: noisy vertical velocity in deep bathymetry and uv with high value
Hello, guys. It has been a long time since I raised the question last time. I am sorry for not giving timely feedback on the follow-up operation. Now I have basically run through the results of the two-way nested run with waves, and nudge only at the boundaries of the model domain, without sponge. Now I'm analyzing the results, but here are some questions worth exploring:
By reading Kumar et al. (2012) "Implementation of the vortex force formalism in the coupled ocean-atmosphere-wave-sediment transport (COAWST) modeling system for inner shelf and surf zone applications ", I am more concerned about the contribution of wave induced non-conservative effects in my example. Therefore, I redefine my .h file as:
At first I thought it was a problem with the setup of my .in file, but after checking it didn't seem to be the case:
By reading Kumar et al. (2012) "Implementation of the vortex force formalism in the coupled ocean-atmosphere-wave-sediment transport (COAWST) modeling system for inner shelf and surf zone applications ", I am more concerned about the contribution of wave induced non-conservative effects in my example. Therefore, I redefine my .h file as:
It compiles successfully, but there are problems at runtime. After I enable USER_DEBUG and output log files:#define ROMS_MODEL
#define NESTING
#define UV_ADV
#define CURVGRID
#define UV_COR
#define UV_LOGDRAG
#define LIMIT_BSTRESS
#define UV_VIS2
#define TS_U3HADVECTION
#define TS_C4VADVECTION
#define SALINITY
#define TS_DIF2
#define NONLIN_EOS
#define BULK_FLUXES
#define EMINUSP
#define ATM_PRESS
#define SOLAR_SOURCE
#define DIAGNOSTICS_TS
#define DIAGNOSTICS_UV
#define SOLVE3D
#define SPLINES_VVISC
#define SPLINES_VDIFF
#define MASKING
#define SPHERICAL
#define DEBUGGING
#define MIX_GEO_UV
#define MIX_GEO_TS
#define LMD_MIXING
#define LMD_SKPP
#define LMD_BKPP
#define LMD_NONLOCAL
#define LMD_SHAPIRO
#define RI_SPLINES
#define WEC_VF
#define WET_DRY
#define WDISS_THORGUZA
#define WEC_BREAKING
#define WEC_ROLLER
#define WEC_WCAP
#define BOTTOM_STREAMING
#ifdef BOTTOM_STREAMING
# define BOTTOM_STREAMING_YU
#endif #define SURFACE_STREAMING
#define HDF5
I find that the boundary condition output of ubar_stokes is garbled. Confusingly, in my previous running with wave, I didn't define WEC_BREAKING, WEC_ROLLER, WEC_WCAP, BOTTOM_STREAMING and SURFACE_STREAMING, and the same gibberish appears in the log file, but the run is still OK. I checked lbc.F and us2bc_im.F carefully and found nothing wrong.-------------------------------------------------------------------------------
Model Input Parameters: ROMS/TOMS version 3.9
Wednesday - July 3, 2024 - 5:02:54 PM
--------------------------------------------------------------------------------
current simulation in Fujian coastal area
Operating system : Linux
CPU/hardware : x86_64
Compiler system : gfortran
Compiler command : /mnt/sdc/littlemarcoleung/COAWST/LIBRARIES/mpich/bin/mpif90
Compiler flags : -frepack-arrays -g -fbounds-check -fbacktrace -fcheck=all -fsanitize=address -fsanitize=undefined -finit-real=nan -ffpe-trap=invalid,zero,overflow -g -fbounds-check -fbacktrace -finit-real=nan -ffpe-trap=invalid,zero,overflow -I/usr/include -
OCN Communicator : 1140850688, PET size = 16
Input Script :
SVN Root URL :
SVN Revision :
Local Root : /mnt/sdd/cy22/COAWST-master
Header Dir : /mnt/sdd/cy22/COAWST-master//Projects/Fujian_withwave/
Header file : fujian_withwave.h
Analytical Dir : /mnt/sdd/cy22/COAWST-master//ROMS/Functionals/
Resolution, Grid 01: 285x214x40, Parallel Nodes: 16, Tiling: 4x4
Physical Parameters, Grid: 01
=============================
...
Lateral Boundary Conditions: NLM
============================
Variable Grid West Edge South Edge East Edge North Edge
--------- ---- ---------- ---------- ---------- ----------
zeta 1 Chapman Imp Chapman Imp Chapman Imp Chapman Imp
2 Nested Nested Nested Nested
ubar 1 Shchepetkin Shchepetkin Shchepetkin Shchepetkin
2 Nested Nested Nested Nested
vbar 1 Shchepetkin Shchepetkin Shchepetkin Shchepetkin
2 Nested Nested Nested Nested
u 1 Rad + Nud Rad + Nud Rad + Nud Rad + Nud
2 Nested Nested Nested Nested
v 1 Rad + Nud Rad + Nud Rad + Nud Rad + Nud
2 Nested Nested Nested Nested
temp 1 Rad + Nud Rad + Nud Rad + Nud Rad + Nud
2 Nested Nested Nested Nested
salt 1 Rad + Nud Rad + Nud Rad + Nud Rad + Nud
2 Nested Nested Nested Nested
ubar_stokes 1 ¾¾¾¾¾¾¾¾¾¾¾ ¾¾¾¾¾¾¾¾¾¾¾ ¾¾¾¾¾¾¾¾¾¾¾ ¾¾¾¾¾¾¾¾¾¾¾
2 ¾¾¾¾¾¾¾¾¾¾¾ ¾¾¾¾¾¾¾¾¾¾¾ ¾¾¾¾¾¾¾¾¾¾¾ ¾¾¾¾¾¾¾¾¾¾¾
vbar_stokes 1 Gradient Gradient Gradient Gradient
2 Nested Nested Nested Nested
u_stokes 1 Gradient Gradient Gradient Gradient
2 Nested Nested Nested Nested
v_stokes 1 Gradient Gradient Gradient Gradient
2 Nested Nested Nested Nested
...
TIME-STEP YYYY-MM-DD hh:mm:ss.ss KINETIC_ENRG POTEN_ENRG TOTAL_ENRG NET_VOLUME Grid
C => (i,j,k) Cu Cv Cw Max Speed
0 2024-07-21 00:00:00.00 1.262584E-02 1.476683E+04 1.476685E+04 2.880806E+14 01
(235,037,39) 3.250710E-02 3.102869E-02 0.000000E+00 1.533661E+00
At line 259 of file vs3dbc_im.f90
Fortran runtime error: Index '12' of dimension 2 of array 'lbc' above upper bound of 11
Error termination. Backtrace:
At line 160 of file vs3dbc_im.f90
Fortran runtime error: Index '12' of dimension 2 of array 'lbc' above upper bound of 11
Error termination. Backtrace:
At line 467 of file vs3dbc_im.f90
Fortran runtime error: Index '12' of dimension 2 of array 'lbc' above upper bound of 11
Error termination. Backtrace:
At line 357 of file vs3dbc_im.f90
Fortran runtime error: Index '12' of dimension 2 of array 'lbc' above upper bound of 11
Error termination. Backtrace:
At line 160 of file vs3dbc_im.f90
Fortran runtime error: Index '12' of dimension 2 of array 'lbc' above upper bound of 11
Error termination. Backtrace:
At line 467 of file vs3dbc_im.f90
Fortran runtime error: Index '12' of dimension 2 of array 'lbc' above upper bound of 11
Error termination. Backtrace:
At line 160 of file vs3dbc_im.f90
Fortran runtime error: Index '12' of dimension 2 of array 'lbc' above upper bound of 11
Error termination. Backtrace:
At line 259 of file vs3dbc_im.f90
Fortran runtime error: Index '12' of dimension 2 of array 'lbc' above upper bound of 11
Error termination. Backtrace:
At line 259 of file vs3dbc_im.f90
Fortran runtime error: Index '12' of dimension 2 of array 'lbc' above upper bound of 11
Error termination. Backtrace:
At line 357 of file vs3dbc_im.f90
Fortran runtime error: Index '12' of dimension 2 of array 'lbc' above upper bound of 11
Error termination. Backtrace:
At line 160 of file vs3dbc_im.f90
Fortran runtime error: Index '12' of dimension 2 of array 'lbc' above upper bound of 11
Error termination. Backtrace:
At line 259 of file vs3dbc_im.f90
Fortran runtime error: Index '12' of dimension 2 of array 'lbc' above upper bound of 11
Error termination. Backtrace:
#0 0x14d1caafc2ed in ???
#1 0x14d1caafced5 in ???
#2 0x14d1caafd2a7 in ???
#0 0x1512999cc2ed in ???
#1 0x1512999cced5 in ???
#2 0x1512999cd2a7 in ???
#0 0x14e2636402ed in ???
#1 0x14e263640ed5 in ???
#2 0x14e2636412a7 in ???
#0 0x14a05d4da2ed in ???
#1 0x14a05d4daed5 in ???
#2 0x14a05d4db2a7 in ???
#0 0x15279a1fb2ed in ???
#1 0x15279a1fbed5 in ???
#2 0x15279a1fc2a7 in ???
#0 0x14c42ce502ed in ???
#1 0x14c42ce50ed5 in ???
#2 0x14c42ce512a7 in ???
#0 0x152e6d6162ed in ???
#1 0x152e6d616ed5 in ???
#2 0x152e6d6172a7 in ???
#3 0x557a2de58109 in __vs3dbc_mod_MOD_vs3dbc_tile
at /mnt/sdd/cy22/COAWST-master/Build/vs3dbc_im.f90:259
#0 0x14d1bc8532ed in ???
#1 0x14d1bc853ed5 in ???
#2 0x14d1bc8542a7 in ???
#0 0x152dd506e2ed in ???
#1 0x152dd506eed5 in ???
#2 0x152dd506f2a7 in ???
#3 0x56323d7b15c8 in __vs3dbc_mod_MOD_vs3dbc_tile
at /mnt/sdd/cy22/COAWST-master/Build/vs3dbc_im.f90:160
#3 0x5558be1bdfb8 in __vs3dbc_mod_MOD_vs3dbc_tile
at /mnt/sdd/cy22/COAWST-master/Build/vs3dbc_im.f90:357
#3 0x55f3d5dfd6b3 in __vs3dbc_mod_MOD_vs3dbc_tile
at /mnt/sdd/cy22/COAWST-master/Build/vs3dbc_im.f90:467
#3 0x55ef764745c8 in __vs3dbc_mod_MOD_vs3dbc_tile
at /mnt/sdd/cy22/COAWST-master/Build/vs3dbc_im.f90:160
#0 0x14b0136a52ed in ???
#1 0x14b0136a5ed5 in ???
#2 0x14b0136a62a7 in ???
#4 0x557a2dd5de98 in wec_stokes_tile
at /mnt/sdd/cy22/COAWST-master/Build/wec_stokes.f90:328
#5 0x557a2dd7704f in __wec_stokes_mod_MOD_wec_stokes
at /mnt/sdd/cy22/COAWST-master/Build/wec_stokes.f90:79
#3 0x55d71c7166b3 in __vs3dbc_mod_MOD_vs3dbc_tile
at /mnt/sdd/cy22/COAWST-master/Build/vs3dbc_im.f90:467
#4 0x56323d6c8e98 in wec_stokes_tile
at /mnt/sdd/cy22/COAWST-master/Build/wec_stokes.f90:328
#5 0x56323d6e204f in __wec_stokes_mod_MOD_wec_stokes
at /mnt/sdd/cy22/COAWST-master/Build/wec_stokes.f90:79
#6 0x557a2c661ec9 in main3d_
at /mnt/sdd/cy22/COAWST-master/Build/main3d.f90:203
#7 0x557a2c659539 in __ocean_control_mod_MOD_roms_run
at /mnt/sdd/cy22/COAWST-master/Build/ocean_control.f90:192
#8 0x557a2c656021 in ocean
at /mnt/sdd/cy22/COAWST-master/Build/master.f90:108
#9 0x557a2c6561d6 in main
at /mnt/sdd/cy22/COAWST-master/Build/master.f90:50
#3 0x555ac78ac5c8 in __vs3dbc_mod_MOD_vs3dbc_tile
at /mnt/sdd/cy22/COAWST-master/Build/vs3dbc_im.f90:160
#4 0x5558be0b1e98 in wec_stokes_tile
at /mnt/sdd/cy22/COAWST-master/Build/wec_stokes.f90:328
#5 0x5558be0cb04f in __wec_stokes_mod_MOD_wec_stokes
at /mnt/sdd/cy22/COAWST-master/Build/wec_stokes.f90:79
#4 0x55f3d5cdce98 in wec_stokes_tile
at /mnt/sdd/cy22/COAWST-master/Build/wec_stokes.f90:328
#5 0x55f3d5cf604f in __wec_stokes_mod_MOD_wec_stokes
at /mnt/sdd/cy22/COAWST-master/Build/wec_stokes.f90:79
#6 0x56323bfccec9 in main3d_
at /mnt/sdd/cy22/COAWST-master/Build/main3d.f90:203
#7 0x56323bfc4539 in __ocean_control_mod_MOD_roms_run
at /mnt/sdd/cy22/COAWST-master/Build/ocean_control.f90:192
#8 0x56323bfc1021 in ocean
at /mnt/sdd/cy22/COAWST-master/Build/master.f90:108
#9 0x56323bfc11d6 in main
at /mnt/sdd/cy22/COAWST-master/Build/master.f90:50
#4 0x55ef7638be98 in wec_stokes_tile
at /mnt/sdd/cy22/COAWST-master/Build/wec_stokes.f90:328
#5 0x55ef763a504f in __wec_stokes_mod_MOD_wec_stokes
at /mnt/sdd/cy22/COAWST-master/Build/wec_stokes.f90:79
#0 0x15365c96b2ed in ???
#1 0x15365c96bed5 in ???
#2 0x15365c96c2a7 in ???
#4 0x55d71c5f5e98 in wec_stokes_tile
at /mnt/sdd/cy22/COAWST-master/Build/wec_stokes.f90:328
#5 0x55d71c60f04f in __wec_stokes_mod_MOD_wec_stokes
at /mnt/sdd/cy22/COAWST-master/Build/wec_stokes.f90:79
#3 0x55ad0cd78109 in __vs3dbc_mod_MOD_vs3dbc_tile
at /mnt/sdd/cy22/COAWST-master/Build/vs3dbc_im.f90:259
#6 0x5558bc9b5ec9 in main3d_
at /mnt/sdd/cy22/COAWST-master/Build/main3d.f90:203
#3 0x563cd9b18109 in __vs3dbc_mod_MOD_vs3dbc_tile
at /mnt/sdd/cy22/COAWST-master/Build/vs3dbc_im.f90:259
#6 0x55f3d45e0ec9 in main3d_
at /mnt/sdd/cy22/COAWST-master/Build/main3d.f90:203
#7 0x5558bc9ad539 in __ocean_control_mod_MOD_roms_run
at /mnt/sdd/cy22/COAWST-master/Build/ocean_control.f90:192
#8 0x5558bc9aa021 in ocean
at /mnt/sdd/cy22/COAWST-master/Build/master.f90:108
#9 0x5558bc9aa1d6 in main
at /mnt/sdd/cy22/COAWST-master/Build/master.f90:50
#7 0x55f3d45d8539 in __ocean_control_mod_MOD_roms_run
at /mnt/sdd/cy22/COAWST-master/Build/ocean_control.f90:192
#8 0x55f3d45d5021 in ocean
at /mnt/sdd/cy22/COAWST-master/Build/master.f90:108
#9 0x55f3d45d51d6 in main
at /mnt/sdd/cy22/COAWST-master/Build/master.f90:50
#6 0x55ef74c8fec9 in main3d_
at /mnt/sdd/cy22/COAWST-master/Build/main3d.f90:203
#7 0x55ef74c87539 in __ocean_control_mod_MOD_roms_run
at /mnt/sdd/cy22/COAWST-master/Build/ocean_control.f90:192
#8 0x55ef74c84021 in ocean
at /mnt/sdd/cy22/COAWST-master/Build/master.f90:108
#9 0x55ef74c841d6 in main
at /mnt/sdd/cy22/COAWST-master/Build/master.f90:50
#0 0x14f5a50f52ed in ???
#1 0x14f5a50f5ed5 in ???
#2 0x14f5a50f62a7 in ???
#6 0x55d71aef9ec9 in main3d_
at /mnt/sdd/cy22/COAWST-master/Build/main3d.f90:203
#4 0x555ac77c3e98 in wec_stokes_tile
at /mnt/sdd/cy22/COAWST-master/Build/wec_stokes.f90:328
#5 0x555ac77dd04f in __wec_stokes_mod_MOD_wec_stokes
at /mnt/sdd/cy22/COAWST-master/Build/wec_stokes.f90:79
#7 0x55d71aef1539 in __ocean_control_mod_MOD_roms_run
at /mnt/sdd/cy22/COAWST-master/Build/ocean_control.f90:192
#8 0x55d71aeee021 in ocean
at /mnt/sdd/cy22/COAWST-master/Build/master.f90:108
#9 0x55d71aeee1d6 in main
at /mnt/sdd/cy22/COAWST-master/Build/master.f90:50
#3 0x55fd20e1cfb8 in __vs3dbc_mod_MOD_vs3dbc_tile
at /mnt/sdd/cy22/COAWST-master/Build/vs3dbc_im.f90:357
#6 0x555ac60c7ec9 in main3d_
at /mnt/sdd/cy22/COAWST-master/Build/main3d.f90:203
#7 0x555ac60bf539 in __ocean_control_mod_MOD_roms_run
at /mnt/sdd/cy22/COAWST-master/Build/ocean_control.f90:192
#8 0x555ac60bc021 in ocean
at /mnt/sdd/cy22/COAWST-master/Build/master.f90:108
#9 0x555ac60bc1d6 in main
at /mnt/sdd/cy22/COAWST-master/Build/master.f90:50
#4 0x55ad0cc7de98 in wec_stokes_tile
at /mnt/sdd/cy22/COAWST-master/Build/wec_stokes.f90:328
#5 0x55ad0cc9704f in __wec_stokes_mod_MOD_wec_stokes
at /mnt/sdd/cy22/COAWST-master/Build/wec_stokes.f90:79
#4 0x563cd9a1de98 in wec_stokes_tile
at /mnt/sdd/cy22/COAWST-master/Build/wec_stokes.f90:328
#5 0x563cd9a3704f in __wec_stokes_mod_MOD_wec_stokes
at /mnt/sdd/cy22/COAWST-master/Build/wec_stokes.f90:79
#6 0x55ad0b581ec9 in main3d_
at /mnt/sdd/cy22/COAWST-master/Build/main3d.f90:203
#7 0x55ad0b579539 in __ocean_control_mod_MOD_roms_run
at /mnt/sdd/cy22/COAWST-master/Build/ocean_control.f90:192
#8 0x55ad0b576021 in ocean
at /mnt/sdd/cy22/COAWST-master/Build/master.f90:108
#9 0x55ad0b5761d6 in main
at /mnt/sdd/cy22/COAWST-master/Build/master.f90:50
#6 0x563cd8321ec9 in main3d_
at /mnt/sdd/cy22/COAWST-master/Build/main3d.f90:203
#7 0x563cd8319539 in __ocean_control_mod_MOD_roms_run
at /mnt/sdd/cy22/COAWST-master/Build/ocean_control.f90:192
#8 0x563cd8316021 in ocean
at /mnt/sdd/cy22/COAWST-master/Build/master.f90:108
#9 0x563cd83161d6 in main
at /mnt/sdd/cy22/COAWST-master/Build/master.f90:50
#3 0x5571aff245c8 in __vs3dbc_mod_MOD_vs3dbc_tile
at /mnt/sdd/cy22/COAWST-master/Build/vs3dbc_im.f90:160
#4 0x55fd20d10e98 in wec_stokes_tile
at /mnt/sdd/cy22/COAWST-master/Build/wec_stokes.f90:328
#5 0x55fd20d2a04f in __wec_stokes_mod_MOD_wec_stokes
at /mnt/sdd/cy22/COAWST-master/Build/wec_stokes.f90:79
#6 0x55fd1f614ec9 in main3d_
at /mnt/sdd/cy22/COAWST-master/Build/main3d.f90:203
#7 0x55fd1f60c539 in __ocean_control_mod_MOD_roms_run
at /mnt/sdd/cy22/COAWST-master/Build/ocean_control.f90:192
#3 0x562cb2627109 in __vs3dbc_mod_MOD_vs3dbc_tile
at /mnt/sdd/cy22/COAWST-master/Build/vs3dbc_im.f90:259
#8 0x55fd1f609021 in ocean
at /mnt/sdd/cy22/COAWST-master/Build/master.f90:108
#9 0x55fd1f6091d6 in main
at /mnt/sdd/cy22/COAWST-master/Build/master.f90:50
#4 0x5571afe3be98 in wec_stokes_tile
at /mnt/sdd/cy22/COAWST-master/Build/wec_stokes.f90:328
#5 0x5571afe5504f in __wec_stokes_mod_MOD_wec_stokes
at /mnt/sdd/cy22/COAWST-master/Build/wec_stokes.f90:79
#6 0x5571ae73fec9 in main3d_
at /mnt/sdd/cy22/COAWST-master/Build/main3d.f90:203
#7 0x5571ae737539 in __ocean_control_mod_MOD_roms_run
at /mnt/sdd/cy22/COAWST-master/Build/ocean_control.f90:192
#8 0x5571ae734021 in ocean
at /mnt/sdd/cy22/COAWST-master/Build/master.f90:108
#9 0x5571ae7341d6 in main
at /mnt/sdd/cy22/COAWST-master/Build/master.f90:50
#4 0x562cb252ce98 in wec_stokes_tile
at /mnt/sdd/cy22/COAWST-master/Build/wec_stokes.f90:328
#5 0x562cb254604f in __wec_stokes_mod_MOD_wec_stokes
at /mnt/sdd/cy22/COAWST-master/Build/wec_stokes.f90:79
#6 0x562cb0e30ec9 in main3d_
at /mnt/sdd/cy22/COAWST-master/Build/main3d.f90:203
#7 0x562cb0e28539 in __ocean_control_mod_MOD_roms_run
at /mnt/sdd/cy22/COAWST-master/Build/ocean_control.f90:192
#8 0x562cb0e25021 in ocean
at /mnt/sdd/cy22/COAWST-master/Build/master.f90:108
#9 0x562cb0e251d6 in main
at /mnt/sdd/cy22/COAWST-master/Build/master.f90:50
At first I thought it was a problem with the setup of my .in file, but after checking it didn't seem to be the case:
It looks normal. So, is it possible that there is a logical error in Nonlinear/Wec/'s internal program dealing with boundary conditions? Or is it simply a display error?! Wec boundary conditions
LBC(isU2Sd) == Gra Gra Gra Gra \ ! 2D U-stokes
Nes Nes Nes Nes
LBC(isV2Sd) == Gra Gra Gra Gra \ ! 2D V-stokes
Nes Nes Nes Nes
LBC(isU3Sd) == Gra Gra Gra Gra \ ! 3D U-stokes
Nes Nes Nes Nes
LBC(isV3Sd) == Gra Gra Gra Gra \ ! 3D V-stokes
Nes Nes Nes Nes