ROMS<kshedstrom version> blow at the fist timestep
-
- Posts: 10
- Joined: Mon Jul 01, 2019 1:22 pm
- Location: Nanjing University
ROMS<kshedstrom version> blow at the fist timestep
I'm recently studying the kshedstrom version <https://github.com/kshedstrom/roms/tree/master>, and the model blow up at the first timestep. However, the same input 'grid.nc, initial conditions, and atmospheric forcings' can work with the roms-3.7 version. The following is the running log <intelmpi_3181622.out>.
Hope to get some help with this problem. Great thanks!
Hope to get some help with this problem. Great thanks!
- Attachments
-
run.log
- (54.63 KiB) Downloaded 366 times
Re: ROMS<kshedstrom version> blow at the fist timestep
are you using the newest version of the input scrip?
you need to have the tracer advection schemes selected, such as
! Set horizontal and vertical advection schemes for active and inert
! tracers. A different advection scheme is allowed for each tracer.
! For example, a positive-definite (monotonic) algorithm can be activated
! for salinity and inert tracers, while a different one is set for
! temperature. [1:NAT+NPT,Ngrids] values are expected.
!
! Keyword Advection Algorithm
!
! A4 4th-order Akima (horizontal/vertical)
! C2 2nd-order centered differences (horizontal/vertical)
! C4 4th-order centered differences (horizontal/vertical)
! HSIMT 3th-order HSIMT-TVD (horizontal/vertical)
! MPDATA recursive flux corrected MPDATA (horizontal/vertical)
! SPLINES parabolic splines (only vertical)
! SU3 split third-order upstream (horizontal/vertical)
! U3 3rd-order upstream-biased (only horizontal)
!
! The user has the option of specifying the full Keyword or the first
! two letters, regardless if using uppercase or lowercase. If nested
! grids, specify values for each grid (see glossary below).
Hadvection == MPDATA \ ! temperature
MPDATA ! salinity
Vadvection == MPDATA \ ! temperature
MPDATA ! salinity
you need to have the tracer advection schemes selected, such as
! Set horizontal and vertical advection schemes for active and inert
! tracers. A different advection scheme is allowed for each tracer.
! For example, a positive-definite (monotonic) algorithm can be activated
! for salinity and inert tracers, while a different one is set for
! temperature. [1:NAT+NPT,Ngrids] values are expected.
!
! Keyword Advection Algorithm
!
! A4 4th-order Akima (horizontal/vertical)
! C2 2nd-order centered differences (horizontal/vertical)
! C4 4th-order centered differences (horizontal/vertical)
! HSIMT 3th-order HSIMT-TVD (horizontal/vertical)
! MPDATA recursive flux corrected MPDATA (horizontal/vertical)
! SPLINES parabolic splines (only vertical)
! SU3 split third-order upstream (horizontal/vertical)
! U3 3rd-order upstream-biased (only horizontal)
!
! The user has the option of specifying the full Keyword or the first
! two letters, regardless if using uppercase or lowercase. If nested
! grids, specify values for each grid (see glossary below).
Hadvection == MPDATA \ ! temperature
MPDATA ! salinity
Vadvection == MPDATA \ ! temperature
MPDATA ! salinity
-
- Posts: 10
- Joined: Mon Jul 01, 2019 1:22 pm
- Location: Nanjing University
Re: ROMS<kshedstrom version> blow at the fist timestep
Great thank! The problem has bees solved! ![Smile :)](./images/smilies/icon_smile.gif)
![Smile :)](./images/smilies/icon_smile.gif)
Re: ROMS<kshedstrom version> blow at the fist timestep
Hi, Dr. Wu,
How did you solve the problem of blowing up? Could you show it in this forum? I suffer the same problem. I update the ROMS from Version 3.4 to 4.1, then the salinity blows up in the 1st step, while it runs well in ROMS version 3.4. The salinity in initial, boundary and clim files are all correct. Hope to hear from you. Thank you.
How did you solve the problem of blowing up? Could you show it in this forum? I suffer the same problem. I update the ROMS from Version 3.4 to 4.1, then the salinity blows up in the 1st step, while it runs well in ROMS version 3.4. The salinity in initial, boundary and clim files are all correct. Hope to hear from you. Thank you.
Re: ROMS<kshedstrom version> blow at the fist timestep
did you also update your ocean.in file to include the BC's and advection choices?
-j
-j
Re: ROMS<kshedstrom version> blow at the fist timestep
Yes, I have used new *.in file of Version 4.1 , and changed the TS_advection to be Hadvection==C4 Vadvection== C4. I also alternatively change it to be HSIMT or MPDATA. It also blow up at the 1st step. When I change the DT=0.1, it blows up at 18th step. Any suggestion is appreciated. Thank you.
By the way, when I compile the ROMS, there are warming:
There are also an error:
How to install 'libubsan.so'? Where is it? Which version should I install?
By the way, when I compile the ROMS, there are warming:
Code: Select all
"4277 | CALL mpi_allreduce (Asend, Areduce, Npts, MP_FLOAT, handle, &
| 1
......
4510 | CALL mpi_allreduce (Asend, Areduce, Isize, &
| 2
Warming: Rank mismatch between actual argument at (1) and actual argument at (2) (rank-1 and scalar)
distribute.f90:4164:28:
"
Code: Select all
/usr/bin/ld: can not find "/usr/lib64/libubsan.so.1.0.0"
Last edited by zhaoyun on Tue Jul 26, 2022 10:25 am, edited 1 time in total.
Re: ROMS<kshedstrom version> blow at the fist timestep
ok so this is a different user on the same post.
to zhaoyun- all you are telling us is that it blows up on first time step. You need to provide more information.
Look at the std out and see if there is any information like h<0 and no wetdry, or nans in input forc fields, etc.
the warnings are ok, that is gfortran having an issue.
the error is not ok. the program should not have built an executable if there is an error. That is an operating system library. it needs to be included in your path.
-j
to zhaoyun- all you are telling us is that it blows up on first time step. You need to provide more information.
Look at the std out and see if there is any information like h<0 and no wetdry, or nans in input forc fields, etc.
the warnings are ok, that is gfortran having an issue.
the error is not ok. the program should not have built an executable if there is an error. That is an operating system library. it needs to be included in your path.
-j
Re: ROMS<kshedstrom version> blow at the fist timestep
Dear Jcwarner,
Thanks for your kind assistance. I install 'libubsan-11.3.1-2.1.el9.x86_64' and solve the problem of 'can not find libubsan.so.1.0.0'.
I also check the log file (pls see the attached file), I can not find any abnormal data. I change the TS_Advection Scheme to be HSIMT and MPDATA, the model still blows up
. I also try to close the river discharge, close the tides, close the nudging to CLM file, and it doesn't work. The salinity blows up in the several surface layers.
Thanks for your kind assistance. I install 'libubsan-11.3.1-2.1.el9.x86_64' and solve the problem of 'can not find libubsan.so.1.0.0'.
I also check the log file (pls see the attached file), I can not find any abnormal data. I change the TS_Advection Scheme to be HSIMT and MPDATA, the model still blows up
![Embarassed :oops:](./images/smilies/icon_redface.gif)
- Attachments
-
a.dat
- (104.82 KiB) Downloaded 267 times
Re: ROMS<kshedstrom version> blow at the fist timestep
we have
MAIN: Abnormal termination: BLOWUP.
REASON: MaxDensity = 3.4E+02
can you look in the ocean_rst.nc and see where that density is large?
is it at the open boundary? at a river location?
maybe try to turn off the rivers, and turn off clm nudging. see if it runs without them to help diagnose the issue.
-j
MAIN: Abnormal termination: BLOWUP.
REASON: MaxDensity = 3.4E+02
can you look in the ocean_rst.nc and see where that density is large?
is it at the open boundary? at a river location?
maybe try to turn off the rivers, and turn off clm nudging. see if it runs without them to help diagnose the issue.
-j
Re: ROMS<kshedstrom version> blow at the fist timestep
Dear jcwarner,
Thanks for your kind reply. Since I can run the model in version 3.4, but it blows up in version 4.1. Finally, I find the problem!
I define the ana_initial, ana_ssflux, and define the periodic condition to check if it is the problem of initial, surface forcing or boundary files. It works when I define ana_ssflux! Then, I find the problem is the units of swflux. It is centimeter day-1 in version 3.4, but is meter second-1 in version 4.1. The values are 7 orders between them. I propose this solution here, which may be helpful to the users who update the ROMS. Cheers
.
To the other users: It is also a reminder that you'd better check the units when you update the ROMS.
Thanks for your kind reply. Since I can run the model in version 3.4, but it blows up in version 4.1. Finally, I find the problem!
I define the ana_initial, ana_ssflux, and define the periodic condition to check if it is the problem of initial, surface forcing or boundary files. It works when I define ana_ssflux! Then, I find the problem is the units of swflux. It is centimeter day-1 in version 3.4, but is meter second-1 in version 4.1. The values are 7 orders between them. I propose this solution here, which may be helpful to the users who update the ROMS. Cheers
![Very Happy :D](./images/smilies/icon_biggrin.gif)
To the other users: It is also a reminder that you'd better check the units when you update the ROMS.