Error "neg. dp (m) < -10.00" when running HYCOM

[Alfredo Terrazas]

Dear HYCOM team,

I'm currently running into an error when executing the model:

error: neg. dp (m) < -10.00

I've already tested different time step values, including very low ones, but the error persists. I'm beginning to suspect that the issue might be related to the rmu files, although I'm not entirely sure what could be wrong with them.

To help diagnose the problem, I'm attaching a few relevant files in case you're able to take a look and provide any guidance.

Thank you very much in advance for your support.

Best regards,

[Alan Wallcraft]

Reset 'baclin' and 'batrop' back to their original values.  If the run gets past the first time step than 'batrop' is OK, and note that it should be as large as possible.  If it dies after the 1st time step but very quickly then 'baclin' could be too large, but usually it is configuration issue.

Did the outer model include tides?  if so then it would be usual to run from daily means, rather than once a day snapshot archives, to filter the tides (and then add back accurate tides at the boundary).

If you do want to add tides, they should have 'tidgen' = 0 to use nodal corrections for actual time.  Also, if you use all 8 tidal constituents you will need hourly output for 6 months to do a tidal analysis, but if you only use the 5 largest constituents 30 days of hourly SSH is enough.

I suggest initially turning off tides.  Then also turn off nestfq and finally turn off 'bnstfq' (and 'lbflag').  One of these runs will presumably work, and which one will tell you what was causing the problem.

Alan.

[Alfredo Terrazas]

Dear Alan,

Thanks a lot for your detailed response.

I’ve followed your suggestions, but unfortunately I’m still encountering the same issue. I set batrop to 6.25 and baclin to 200, and I also disabled the flags you mentioned (tides, nestfq, bnstfq, and lbflag), but the model still crashes. It doesn't fail immediately, it runs until hour 11 of the first simulation day, and then crashes with the same error:

error: neg. dp (m) < -10.00

I’m attaching the blkdat.input file and the corresponding log in case they provide further insight.

Thanks again for your support.

Alfredo.

[Alan Wallcraft]

Running for 11 model hours before negative layer thickness confirms the issue is with something you turned off.  Since this isn't a realistic setup it isn't necessarily a problem that it dies.

For GOMb0.04 we use:

 180.0    'baclin' = baroclinic time step (seconds), int. divisor of 86400
 6.428571 'batrop' = barotropic time step (seconds), int. div. of baclin/2

So it is possible that 200 seconds is slightly too large, but it (or 240 seconds) could be OK.

I originally suggested 3 cases:

a) turn off tides

b) also turn off nestfq and 

c) finally turn off 'bnstfq' (and 'lbflag')

You have run (c)

Try (a) and (b).  If these don't work there is also:

d) No tides, no 'bnstfq'.

Alan.

[Alfredo Terrazas]

Dear Alan,

Thanks again for your continued support.

I had actually tested the different configurations you suggested earlier, but only shared the details of the last run in my previous message. To be thorough, I re-ran all four cases using the time steps you mentioned (baclin = 180.0, batrop = 6.428571), and here are the results:

1. Case (a) — tides off: model crashed at hour 2.

2. Case (b) — tides + nestfq off: model ran for 16 hours.

3. Case (c) — tides + nestfq + bnstfq + lbflag off: this time it also ran for 16 hours (previously crashed at hour 11).

4. Case (d) — tides off + bnstfq off: also ran for 16 hours.

In all cases, the crash occurred with the same error:

error: neg. dp (m) < -10.00

Could you please confirm if I’m disabling tides correctly? I’ve been setting

tidcon = 00000000, tidrmp = 0, tidflg = 0

Thanks again for your help,

[Alfredo Terrazas]

Dear Alan,

Just a quick follow-up regarding the issue.

While waiting for a response, I’ve continued troubleshooting on my end. I tried running the same region using an earlier version of the model, specifically, a version prior to the inclusion of the newer flags such as hybthk, cbtidc, and mstrcr.

I used a similar blkdat.input configuration I shared at the beginning of this thread (and I'm reattaching it here for reference). To my surprise, the model successfully completed a full one-month simulation without crashing.

Since the configuration is practically the same, this makes me suspect that the issue might be related to something introduced in the newer model versions, possibly a bug.

I understand that the forum encourages using the most up-to-date version of HYCOM for support, but given this result, I’d appreciate your advice on how to proceed. Is this a known issue? Would you recommend sticking with the earlier version for now, or is there a workaround with the latest version that I could try?

Thanks again for your guidance and time,

Alfredo.

[Alan Wallcraft]

The following differences are probably significant:

<  0.00625   'visco4' = deformation-dependent biharmonic viscosity factor
---
>    0.25    'visco4' = deformation-dependent biharmonic viscosity factor

<    1      'mlflag' = mixed layer flag  (0=none,1=KPP,2-3=KT,4=PWP,5=MY,6=GISS)
---
>    6    'mlflag' = mixed layer flag  (0=none,1=KPP,2-3=KT,4=PWP,5=MY,6=GISS)

We used to use the GISS mixed layer for global runs because it can be better than KPP at high latitudes, but these days the only well tested mixed layer scheme is KPP.

Your momentum setup makes no sense:

   4      'momtyp' = momentum advection type (2=2nd; 3=S.QUICK; 4=M.S.QUICK)
  -1.0    'slip  ' = +1 for free-slip, -1 for non-slip boundary conditions
 0.05     'visco2' = deformation-dependent Laplacian  viscosity factor
 0.00625   'visco4' = deformation-dependent biharmonic viscosity factor
 0.0625    'facdf4' =       speed-dependent biharmonic viscosity factor
   0.00286 'veldf2' = diffusion velocity (m/s) for Laplacian  momentum dissip.
   0.02   'veldf4' = diffusion velocity (m/s) for biharmonic momentum dissip.

The header says "A=20;Smag=.05;momtyp=2", which is out standard setup for 0.08 degree grids, e.g. GOFS 3.1 has:

   2      'momtyp' = momentum advection type (2=2nd order, 4=4th order)
  -1.0    'slip  ' = +1 for free-slip, -1 for non-slip boundary conditions
   0.05   'visco2' = deformation-dependent Laplacian  viscosity factor
   0.0    'visco4' = deformation-dependent biharmonic viscosity factor
   0.0    'facdf4' =       speed-dependent biharmonic viscosity factor
 -0.00286 'veldf2' = diffusion velocity (m/s) for Laplacian  momentum dissip.
  -0.02   'veldf4' = diffusion velocity (m/s) for biharmonic momentum dissip.

The minus sign on veldfX indicates that a 2-D field is read in for df and its absolute values indicates a "typical" value.  So the input veldf2 varies in latitude to produce A=20 m^2/s^ everywhere and at mid-latutudes this is veldf2=0.00286.  If we use veldf2=0.00286 everywhere on a 0.08 degree grid we get:

So in your case A2 is about 11, for 0.04 grid in the Gulf of Mexico.  This is perfectly fine, except that the header should be updated.

We almost never use both visco2 and visco4, and in the case of 'momtyp'=4 visco4 will actually remove the possibility of high order accuracy.  I suggest trying montyp=2 first, but if you want to use momtyp=4 try:

  4      'momtyp' = momentum advection type (2=2nd; 3=S.QUICK; 4=M.S.QUICK)
  -1.0    'slip  ' = +1 for free-slip, -1 for non-slip boundary conditions
 0.05     'visco2' = deformation-dependent Laplacian  viscosity factor
 0.0       'visco4' = deformation-dependent biharmonic viscosity factor
 0.0625    'facdf4' =       speed-dependent biharmonic viscosity factor
   0.00286 'veldf2' = diffusion velocity (m/s) for Laplacian  momentum dissip.
   0.0    'veldf4' = diffusion velocity (m/s) for biharmonic momentum dissip.

What  'facdf4' does is set veldf4(t) to facdf2 * speed(t), so there is usually no need for a constant veldf4 value although it could be used to set a minimum value.

Try running the latest code with uodated blkdat.

Alan.

[Alfredo Terrazas]

Dear Alan,

Thanks again for your continued support.

I’ve now tested two different configurations using the latest version of the model and setting mlflag = 1 (KPP), as you suggested. Here are the results:

---

Test A

4 'momtyp' = momentum advection type (2=2nd; 3=S.QUICK; 4=M.S.QUICK) 

 -1.0 'slip ' = +1 for free-slip, -1 for non-slip boundary conditions 

 0.05 'visco2' = deformation-dependent Laplacian viscosity factor

 0.0 'visco4' = deformation-dependent biharmonic viscosity factor 

 0.0625 'facdf4' = speed-dependent biharmonic viscosity factor

 0.00286 'veldf2' = diffusion velocity for Laplacian momentum dissip.

 0.0 'veldf4' = diffusion velocity for biharmonic momentum dissip.

→ Crashed at hour 2 of the first simulation day.

---

Test B

2 'momtyp' = momentum advection type (2=2nd order) 

-1.0 'slip ' = +1 for free-slip, -1 for non-slip boundary conditions 

 0.05 'visco2' = deformation-dependent Laplacian viscosity factor 

 0.0 'visco4' = deformation-dependent biharmonic viscosity factor 

 0.0 'facdf4' = speed-dependent biharmonic viscosity factor 

 0.00286 'veldf2' = diffusion velocity for Laplacian momentum dissip. 

 0.02 'veldf4' = diffusion velocity for biharmonic momentum dissip.

→ Crashed at hour 4 of the first simulation day.

---

Both tests crash with the same error

error: neg. dp (m) < -10.00

At this point, I’m not sure what else to adjust in this latest version of the model.  Do you have any more suggestions for alternative momentum configurations or additional diagnostics I could try?

Thanks again for your help — I truly appreciate your time and guidance.

Best regards,

[Alan Wallcraft]

Turn off tides.

For momtum4 you likely need to set MOMTUM4_CFL at compile time, and you should also set RDNEST_MASK and LATBDT_NPLINE3:

# Miscellaneous CPP flags (-DSTOKES -DOCEANS2 etc...)
# -DSTOKES  : Stokes drift
# -DOCEANS2 : master and slave HYCOM in same executable
# -DMOMTUM_CFL     : include an explicit CFL limiter
# -DMOMTUM4_CFL    : include an explicit CFL limiter
# -DRDNEST_MASK    : mask velocity outliers
# -DLATBDT_NPLINE3 : update pline every 3 time steps
# -DMASSLESS_1MM   : lowest substantial mass-containing layer > 1mm thick
#setenv OCN_MISC ""
#setenv OCN_MISC "-DMASSLESS_1MM"
setenv OCN_MISC "-DMASSLESS_1MM -DRDNEST_MASK -DLATBDT_NPLINE3"

It should not be necessary to set MOMTUM_CFL, but you can if you want.

If these are not currently on, I suggest deleting all *.o amd *.mod files and remaking with the new OCN_MISC.

Alan.

[Alfredo Terrazas]

Dear Alan,

Thank you again for the recommendations.

I recompiled the model with the flags you suggested:

After cleaning all .o and .mod files, I ran both Test A and Test B again, using both momentum advection schemes (momtyp = 2 and momtyp = 4), and with tides turned off. Unfortunately, both runs still crash after a few of simulation hours with the same neg. dp error. I’m attaching the log files from tests, in case it helps diagnose what’s happening.

If you recommend using the configuration from Test B (momtyp = 2), I’d be happy to follow your guidance to get the model running successfully with that setup.

Thanks once again for your time and help, I truly appreciate it.

Best regards,
Alfredo

[Alan Wallcraft]

This setup should work.

If you point me to a tar bundle of the data scratch directory (expt_01.1/data) and the model run directory (expt_01.1) I will run it and gtrack down what is wrong.

Alan.

[Alfredo Terrazas]

I have compressed the requested directories into a tar.gz archive. You can download it here:

 http://187.251.135.214:6300/hycom/

Please let me know if you need any additional files or information.

Thank you very much for your help.

Best regards,
Alfredo

[Alan Wallcraft]

I was able to run with no problems.  The significant differences in the .log files are:

7078c522
< equation of state is 7-term sigma-2
---
> equation of state is 17-term sigma-2

7309c753
< zaiost - Array I/O is Fortran DA I/O from the 1st task
---
> zaiost - Array I/O is MPI-2 I/O from one task per row

7829c1325
< Browning and Kreiss barotropic nesting, npline =  1
---
> Browning and Kreiss barotropic nesting, npline =  3
8363a1860
>  42886.00000  nest mask counts =    23825    23831
8364a1862
>  42887.00000  nest mask counts =      270        0

The problem is likely using the 7-term equation of state, but I also applied the _MASK and _NPLINE3 macros.

In Make.csh, change to the following:

# Equation Of State
setenv OCN_SIG  -DEOS_SIG2 ## Sigma-2

setenv OCN_EOS -DEOS_17T ## EOS 17-term

# Miscellaneous CPP flags (-DSTOKES -DOCEANS2 etc...)

# -DRDNEST_MASK    : mask velocity outliers
# -DLATBDT_NPLINE3 : update pline every 3 time steps
# -DMASSLESS_1MM   : lowest substantial mass-containing layer > 1mm thick

setenv OCN_MISC "-DMASSLESS_1MM -DRDNEST_MASK -DLATBDT_NPLINE3"

Delete all the *.o and *.mod files and rerun Make.csh.

You could also try removing -DSERIAL_IO, but this will only effect I/O performance not the answers.

Alan.

[Alfredo Terrazas]

Thanks for your previous message. I followed your instructions: I modified Make.csh to use the 17-term equation of state, added the flags, removed all the .o and .mod files, and recompiled from scratch.

Unfortunately, the model still crashes after a few simulated hours. I’m attaching the updated log file in case that helps you spot the issue.

Also, thank you very much for the attention and time you’ve given me throughout this process. I really appreciate your help in trying to get this running.

Best regards,
Alfredo.

[Alan Wallcraft]

The only blkdat.input difference is:

narwhal08 102> diff -bwi blk*
117c117
<    0.0    'proffq' = number of days between model diagnostics at selected locs
---
>   .020833 'proffq' = number of days between model diagnostics at selected locs

Your version fails after 5 model hours:

narwhal10 101> grep "SSH " 012y118f.log
 30877921 (2018/152 00) mean      SSH (mm):   -0.11  (-1.7E+00 to  2.3E-01)
 30877935 (2018/152 00) mean      SSH (mm):  100.49  (-2.1E+03 to  3.8E+03)
 30877950 (2018/152 01) mean      SSH (mm):  281.28  (-2.3E+03 to  6.7E+03)
 30877965 (2018/152 01) mean      SSH (mm):  564.18  (-1.9E+03 to  8.6E+03)
 30877980 (2018/152 02) mean      SSH (mm):  946.56  (-1.4E+03 to  1.0E+04)
 30877995 (2018/152 02) mean      SSH (mm): 1410.75  (-1.2E+03 to  1.2E+04)
 30878010 (2018/152 03) mean      SSH (mm): 1920.38  (-1.4E+03 to  1.3E+04)
 30878025 (2018/152 03) mean      SSH (mm): 2416.32  (-1.1E+03 to  1.4E+04)
 30878040 (2018/152 04) mean      SSH (mm): 2877.15  (-1.0E+03 to  1.6E+04)
 30878055 (2018/152 04) mean      SSH (mm): 3318.56  (-1.2E+03 to  1.6E+04)
 30878070 (2018/152 05) mean      SSH (mm): 3761.12  (-9.2E+02 to  1.7E+04)

My version times out after 30 wall minutes, having run 12+ days:

narwhal10 102> grep "SSH " 012y118F.log | head -n 6
 30877921 (2018/152 00) mean      SSH (mm):   -0.11  (-1.7E+00 to  2.3E-01)
 30877950 (2018/152 01) mean      SSH (mm):   69.69  (-2.4E+03 to  1.5E+03)
 30877980 (2018/152 02) mean      SSH (mm):   86.22  (-1.5E+03 to  1.4E+03)
 30878010 (2018/152 03) mean      SSH (mm):   77.75  (-1.7E+03 to  1.3E+03)
 30878040 (2018/152 04) mean      SSH (mm):   76.63  (-1.0E+03 to  1.2E+03)
 30878070 (2018/152 05) mean      SSH (mm):   72.22  (-9.3E+02 to  9.2E+02)
narwhal10 103> grep "SSH " 012y118F.log | tail -n 2
 30887220 (2018/164 22) mean      SSH (mm):    0.52  (-5.0E+02 to  5.3E+02)
 30887250 (2018/164 23) mean      SSH (mm):    1.43  (-5.1E+02 to  5.3E+02)

My executable was created via config/shasta-intel-relo_mpi and 

Intel(R) Fortran Intel(R) 64 Compiler Classic for applications running on Intel(R) 64, Version 2021.7.1 Build 20221019_000000

You will probably need to use a different config file.

I suggest downloading the very latest code from GitHub, compiling it and rerunning with  'proffq'=0.0

What compiler version and what config file are you using?

Alan.

[Alfredo Terrazas]

Hi Alan,

 Thanks again for your help. I already tried using 'proffq'=0.0 with the current compilation, but unfortunately it still didn't work, the model crashes after a few hours as before.  

I'm using the intelIFC-impi-sm-relo_mpi config file, which sets the compiler as:

FC = \time -v mpiifort

Running mpiifort --version returns:

ifort (IFORT) 2021.7.1 20221019
Copyright (C) 1985-2022 Intel Corporation.  All rights reserved.

I've attached the full config file for your reference. Do you see any issue when the config file and the compiler version before trying to compile the latest code?

Thanks again

[Alan Wallcraft]

Use generic-intel-relo_mpi,which I just added to GitHub, but replace mpif90 with mpiifort and mpicc with mpiicc.

Alan.

[Alfredo Terrazas]

Dear Alan,

I am pleased to inform you that the model is now running successfully after recompiling with the configuration file you provided. I sincerely appreciate your guidance in resolving the previous issue.

I am currently encountering a problem when attempting to convert the outputs from one of these new runs to NetCDF format. The tools report a mismatch between the bathymetries; however, I have verified that the bathymetry files used in the model run are indeed the same.

Could you please confirm whether it is necessary to recompile HYCOM-tools using the same configuration file (generic-intel-relo_mpi or similar) that was used to compile HYCOM-src?

Thank you once again for your continued support.

Best regards,

Alfredo.

[Alan Wallcraft]

Almost always, if a mismatch is reported then the wrong bathymetry is being used.

Use hycom_archive_sea_ok to check the archive and bathymetry:

narwhal03 242> hycom_archive_sea_ok 704_archv.2016_092_00.a ../regional.depth.a 704_archv.2016_092_00_anom.a > ! 704_archv.2016_092_00_anom.b
narwhal03 243> cat 704_archv.2016_092_00_anom.b
 
ARCHIVE LAND/SEA is OK
 
Depth anomaly: min,max =   -0.00098150    0.00095692

In the above example, I am running in the expt scratch directory, and so regional.depth.a is definitely the right bathymetry.

In your case, you should do the same check, but then also run against the bathymetry input to the netcdf program.

Alan.

[Alfredo Terrazas]

I followed your suggestion and ran hycom_archive_sea_ok both against the regional.depth.a file in the experiment scratch directory and against the regional.depth.a file used by the NetCDF conversion program (archive/ncdf_2010_hindcast).

Both checks return:

terrazas.alfredo@hadad:~/HYCOM/SCRATCH/GDMi0.04/expt_01.2/data$ hycom_archive_sea_ok KEEP/archv.2010_033_01.a regional.depth.a archv.2010_033_01_anom.a > archv.2010_033_01_anom.b
terrazas.alfredo@hadad:~/HYCOM/SCRATCH/GDMi0.04/expt_01.2/data$ cat archv.2010_033_01_anom.b

ARCHIVE LAND/SEA is OK

Depth anomaly: min,max =   -0.00116944    0.00114454
-----------------------------------------------

terrazas.alfredo@hadad:~/HYCOM/SCRATCH/GDMi0.04/expt_01.2/data$ hycom_archive_sea_ok KEEP/archv.2010_033_01.a archive/ncdf_2010_hindcast/regional.depth.a archv.2010_033_01_anom2.a > archv.2010_033_01_anom2.b
terrazas.alfredo@hadad:~/HYCOM/SCRATCH/GDMi0.04/expt_01.2/data$ cat archv.2010_033_01_anom2.b

ARCHIVE LAND/SEA is OK

Depth anomaly: min,max =   -0.00116944    0.00114454

-----------------------------------------------

I also ran cmp between the two regional.depth.a files, and it confirms that they are identical. The output from hycom_archive_sea_ok appears consistent with this.

However, when I run the NetCDF conversion, I still get:

archive depth mismatch range = -2.2888184E-05 7849.788 error - wrong bathymetry for this archive file number of depth mismatches = 106723

Given that the depth files seem identical, I am wondering if this could be related to how the NetCDF conversion tools were compiled, rather than to the files themselves.

Alfredo.

[Alan Wallcraft]

This might be a compiler issue, e.g. a big to little endian conversion issue, but the error does not look right for that.

Other possibilities:

a) Wrong idm and jdm in the netcdf script

b) wrong regional.grid in the netcdf script

Alan.

[Alan Wallcraft]

HYCOM-tools are mostly serial programs (except in the MPI sub-directory) and don't need to be compiled with the same compiler as HYCOM, e.g. you could use gfortran instead of ifort.

Alan.

[Alan Wallcraft]

I still think the most likely reason is the wrong bathymetry, and based on your netcdf program error, the regional.depth.a file is either zero length or the wrong size.

Add the commands:

echo $PWD

/bin/ls -laF

immediately before you invoke the archv2ncdf* program.

This will tell you which directoy you are in and what the regional.depth.a file is.

Alan.

On Thursday, August 14, 2025 at 3:44:22 PM UTC-4 Alan Wallcraft wrote:

[Alfredo Terrazas]

Thank you very much for your guidance and patience, you were totally right about the wrong sizes, but it was not about idm or jdm, it was kdm.  The problem was not with the bathymetry files themselves, they were indeed identical, as we had confirmed, but with the EXPT.src being read, which had a different number of vertical levels defined.

This mismatch was driving me crazy, especially after the earlier compilation problems, and I overlooked it for quite some time. After correcting the vertical levels, the NetCDF conversion works correctly.

I really appreciate your continued support in helping me work through these issues.

Best regards,

Alfredo