Inquiry about Hycom Model Simulation Issues and Boundary Conditions

[zhong minglei]

Dear Alan,

I hope this email finds you well.

I am a user of the Hycom model. I am writing to you today to seek your guidance and assistance regarding some issues I have encountered during my model simulations.

Firstly, I am running a regional simulation using the Hycom model. However, the model crashes with an error after running for seven years. I have reviewed my configurations but have been unable to identify the cause of the problem. I have attached my grid file (regional.grid), depth file (regional.depth), blkdat.dat setting file (do_blkdat.ksh)and the running log file (nohup.out) for your reference. I hope these files will provide you with more details about the issue.

Secondly, I have some confusion regarding the climatological relaxation boundary condition in the Hycom model. I understand that climatological relaxation is often used for open boundary treatment. I would like to ask how this climatological relaxation is related to the open boundary. Does it only apply to temperature and salinity relaxation, or does it also include velocity relaxation? I am particularly interested in whether water is allowed to flow out of the simulation domain at the boundaries under this condition.

I have also attached my climatological relaxation setting file (fort.dat) for your review.

Thank you very much for taking the time to read my email. I look forward to hearing from you soon.

Sincerely

[Alan Wallcraft]

My usual advice for a simulation that dies after 7 years is to halve the baclin time step for the segment that dies and then continue with the original time step.  If it repeatedly dies, then try reducing baclin slightly.  Keep batrop as large as possible.

In your case, there are many instances of "neg. dp" that are not large enough to stop the model run.  I am not concerned about these in the early months but you have them throughout the run:

COAPS 127> egrep " SSH |neg. dp" nohup.out > ! nohup.out.SSH
COAPS 128> paste -d " " - - < nohup.out.SSH | egrep "SSH.*neg" | sed -e "s/mean.*neg/neg/g"
     9504 (0001/038 00) neg. dp (m) in loop 19      -0.56E-01 max
     9936 (0001/039 00) neg. dp (m) in loop 19      -0.22E-01 max
    12528 (0001/045 00) neg. dp (m) in loop 19      -0.72E-01 max
    12960 (0001/046 00) neg. dp (m) in loop 19      -0.40     max
   424656 (0003/279 00) neg. dp (m) in loop 19      -0.51     max

   440208 (0003/315 00) neg. dp (m) in loop 19      -0.70E-01 max
   456624 (0003/353 00) neg. dp (m) in loop 19      -0.98     max
   589680 (0004/301 00) neg. dp (m) in loop 19      -0.27E-01 max
   641088 (0005/060 00) neg. dp (m) in loop 19      -0.31E-01 max
   644112 (0005/067 00) neg. dp (m) in loop 19      -0.10E-01 max
   648000 (0005/076 00) neg. dp (m) in loop 19      -0.63E-01 max
   669168 (0005/125 00) neg. dp (m) in loop 19      -0.24     max
   672624 (0005/133 00) neg. dp (m) in loop 19      -0.22E-01 max
   675648 (0005/140 00) neg. dp (m) in loop 19      -0.20E-01 max
   731808 (0005/270 00) neg. dp (m) in loop 19      -0.21E-01 max
   733104 (0005/273 00) neg. dp (m) in loop 19      -0.59E-01 max
   738288 (0005/285 00) neg. dp (m) in loop 19      -0.12E-01 max
   746928 (0005/305 00) neg. dp (m) in loop 19      -0.81E-01 max
   760752 (0005/337 00) neg. dp (m) in loop 19      -0.29E-01 max
   769392 (0005/357 00) neg. dp (m) in loop 19      -0.79     max
   771984 (0006/003 00) neg. dp (m) in loop 19      -0.49E-01 max
   772416 (0006/004 00) neg. dp (m) in loop 19      -0.41E-01 max
   796176 (0006/059 00) neg. dp (m) in loop 19      -0.31E-01 max
   800064 (0006/068 00) neg. dp (m) in loop 19      -0.36E-01 max
   815184 (0006/103 00) neg. dp (m) in loop 19      -0.52E-01 max
   817344 (0006/108 00) neg. dp (m) in loop 19      -0.67E-01 max
   818208 (0006/110 00) neg. dp (m) in loop 19      -0.41     max
   819504 (0006/113 00) neg. dp (m) in loop 19      -0.33E-01 max
   830736 (0006/139 00) neg. dp (m) in loop 19      -0.58E-01 max
   850608 (0006/185 00) neg. dp (m) in loop 19      -0.15     max
   858816 (0006/204 00) neg. dp (m) in loop 19      -0.13E-01 max
   874800 (0006/241 00) neg. dp (m) in loop 19       -2.7     max
   886896 (0006/269 00) neg. dp (m) in loop 19      -0.20     max
   905472 (0006/312 00) neg. dp (m) in loop 19      -0.20E-01 max
   928368 (0007/005 00) neg. dp (m) in loop 19      -0.25E-01 max
   928800 (0007/006 00) neg. dp (m) in loop 19      -0.19E-01 max
   935712 (0007/022 00) neg. dp (m) in loop 19      -0.19E-01 max
   939168 (0007/030 00) neg. dp (m) in loop 19      -0.29E-01 max
   940032 (0007/032 00) neg. dp (m) in loop 19      -0.85E-01 max
   940896 (0007/034 00) neg. dp (m) in loop 19      -0.37E-01 max
   945216 (0007/044 00) neg. dp (m) in loop 19      -0.75E-01 max
   952128 (0007/060 00) neg. dp (m) in loop 19      -0.25     max
   983232 (0007/132 00) neg. dp (m) in loop 19      -0.14E-01 max
   983664 (0007/133 00) neg. dp (m) in loop 19      -0.57E-01 max
  1032480 (0007/246 00) neg. dp (m) in loop 19      -0.22E-01 max
  1035072 (0007/252 00) neg. dp (m) in loop 19      -0.71     max
  1054080 (0007/296 00) neg. dp (m) in loop 19      -0.14E-01 max
  1076544 (0007/348 00) neg. dp (m) in loop 19       -1.0     max
  1102464 (0008/048 00) neg. dp (m) in loop 19      -0.31E-01 max
  1102896 (0008/049 00) neg. dp (m) in loop 19      -0.26E-01 max
  1103760 (0008/051 00) neg. dp (m) in loop 19      -0.12     max
  1104192 (0008/052 00) neg. dp (m) in loop 19      -0.23E-01 max

On the other hand, your time step of 200 seconds seems OK for a 9 km grid.

So I guess I would try baclin=180.0 and see if this gets rid of the neg. dp's.

HYCOM has two options for regional models:

a) Relaxation (some ocean models call this SPONGE) to monthly climo T&S near the open boundaries.  There is no velocity relaxation and there is no flow through the boundary (which is therefore not actually open).

b) One-way nesting inside an "outer" HYCOM model solution (archive files) that has two parts (1) barotropic flow through the open boundary and (2) relaxation of T&S&velocity near the open boundary.  The nesting archives can be more frequent than monthly, e.g. daily means are often used, and this implies that the e-folding time of the relaxation can be much smaller than for climo. relaxation depending on the frequency of archive input.

Nesting can very easily be setup to use the GOFS 3.1 Reanalysis monthly means from http://data.hycom.org/datasets/GLBb0.08/expt_53.X/data/meanstd/ which provide a comparable alternative to climo. relaxation, but the latter is even easier to setup.  We use the climo. approach for models of large regions, the entire North Atlantic (30S to 80N) for example, but also for small regions where the flow does not depend on the details of the boundaries, a Strait of Gibraltar model for example.  If you want to include tides then the nesting approach is best.

In either case, a common problem is for the rmu file to be setup incorrectly.  The best way to check is to plot the e-folding time (inverse of the coefficient).  The nest_rmu_linear.csh script illustrates how to calculate the e-folding file.

For example, here is our Strait of Gibraltar rmu with 10-60 day e-folding time:

Finally, there is almost no use case any more for monthly atmospheric forcing.  It is impossible to get the mixed layer correct in such cases.  I suggest you switch to CFSR or CFSv2.  

If you want a repeated year, what I use now is CFSR 2003.  The way to create this is:

a) Setup the model on your region to use CFSR forcing and run the preprocessing only for 2003 (standard model run script, but comment out the actual model run).

b) Shift the wind days from 2003 to 1903 (indicating a climatology), I attach a very old script to do this.

This will get you a 365 day climatology.  If you want 366 days, then do the above but add one day to the end date of 2003.  Note that either way you will  need both 2003 and 2004 CFSR input files.

Alan.

[hao ming]

Dear Alan,

I am writing to express my sincere gratitude for your prompt and helpful response to my previous inquiry. Your insights were invaluable in clarifying several aspects of the HYCOM model.

However, I still have some lingering questions that I hope you might be able to shed some light on.

Firstly, I am exploring alternative methods to simulate outflow at the boundaries without resorting to nesting, which I find quite complex at this stage. I was wondering if modifying the source code to set the boundary current velocities to match those of the layer above would achieve a similar effect, essentially allowing water to exit the domain. If this approach is viable, could you please provide some guidance on how to implement such a modification within the HYCOM framework?

Secondly, if nesting is indeed the only reliable solution for simulating outflow, I would greatly appreciate some advice on how to proceed. Would it be appropriate to use data from a resource like http://data.hycom.org/datasets/GLBb0.08/expt_53.X/data/meanstd as the larger-scale background field for the nested simulation? Additionally, I have noticed that most nesting examples focus on actual runs rather than climatological runs. Are there any specific considerations or resources available for nesting within a climatological simulation?

Thank you very much for your time and expertise. I look forward to hearing from you at your convenience.

Sincerely

[Alan Wallcraft]

When looking at the velocities from relaxation or nesting, it is the profiles just outside the rmu zone that matter.  The velocities in the rmu zone are adjusting to the relaxation and typically look very strange.

Just outside the rmu zone with climo relax the average barotropic velocity across the entire boundary line will be approximately zero but the point by point barotropic velocity need not be zero (even though is is exactly zero on the closed boundary).  Similarly, the baroclinic velocity is often "realistic" even though it is exactly zero on the boundary and the relaxation is for T&S only.  This is why climo relaxation works at all, and also why it does not work well if there is a large net barotropic velocity through the boundary.

In principle it should be possible to add a barotropic velocity through the boundary to climo. relax but I have never seen this done successfully.  It is just too hard to some up with a balanced line of velocities.  If you wanted to try this, the best approach would be to use nesting with 3-D nesting archives from the monthly climatology and with velocity relaxation turned off (configure nest/rmu with just one field instead of two) and add "fake" 2-D archives containing your barotropic velocity fields.  This is a lot of work, when probably the long term monthly means for 53.X would be a better option, for example 53X_archMN.1994_01_2015_01.a is the average of all the Januaries.  These can be used for both relaxation and barotropic nesting, and you can turn off velocity relaxation if you want the true climo relaxation effect (no real need to do this though).

If you want to continue to use a monthly atmosphere, at a minimum you need to add 6hrly (or 1hrly) anomalies to the wind stresses.  This is to get the mixed layer right.  We used to do this a lot, but now I just use repeated CFSR_2003 forcing if I want to exclude inter-annual variability from forcing.  The CICE sea ice model does not have a climo option and so when we couple to it our climo cases start in 1911 and use the same forcing every year.  This is probably your best bet for climo nesting, just use the same multi-year monthly means (12 archive files) every year.  This might involve shifting the wind day of the forcing and the model day of the nesting archive files (i.e. editing their ,b files, the ,a files don;t change).

Alan.

[hao ming]

Dear Alan, 

Thank you very much for your previous guidance on setting up the HYCOM simulation. Your explanations were extremely helpful. I have a few follow up questions regarding the forcing file generation and the use of restart files, particularly in my climatological run. 

Question 1: Forcing File Generation with Repeated CFSR_2003 

You previously advised me to use repeated CFSR_2003 forcing. I'm now working on generating the forcing files, and I'm unsure about the correct value for `IFFILE` when using `ap_nc`. Previously, I used ERA15 climatological forcing, and `IFFILE` was set to 3 (monthly). My understanding is that for actual-year runs, `IFFILE=5` (actual-day) would be appropriate. However, I'm running a climatological simulation (`yrflag=0` in my `blkdat.input`). 

My specific questions are: 

1. Given my `yrflag=0` (360-day year) , should I generate the forcing files as if I were doing an actual-year run (i.e., using the process for `IFFILE=5`), and then use the `CFSR-2003-shift` script you provided earlier? Or is there a different `IFFILE` value I should use for a climatological run with repeated annual forcing? 

2. Should I modify any of the following parameters in my `blkdat.input` file when using the repeated CFSR_2003 forcing? Here are the current settings: 

12 'clmflg' = climatology frequency flag (6=bimonthly, 12=monthly) 2 'wndflg' = wind stress input flag (0=none,1=uv-g,2,3=p-grd,4,5=wnd10m) 3 'ustflg' = ustar forcing flag (3=input,1,2=wndspd,4=stress) 4 'flxflg' = thermal forcing flag (0=none,3=net_flx,1-2,4-6=sst-based) 4 'empflg' = E-P forcing flag (0=none,3=net_E-P,1-2,4-6=sst-bas_E) 0.0 'emptgt' = E-P balance target (mm/week, into ocean) 0 'empbal' = E-P balance flag (0=none,1=offset,2=scale) 0 'dswflg' = diurnal shortwave flag (0=none,1=daily to diurnal corr.) 0 'albflg' = ocean albedo flag (0=none,1=const,2=L&Y) 1 'sssflg' = SSS relaxation flag (0=none,1=clim,-1=clim&rmx) 0 'sssbal' = SSS rlx balance flag (0=none,1=offset,2=scale) 2 'lwflag' = longwave (SST) flag (0=none,1=clim,2=nwp,-1=lwdn) 0 'sstflg' = SST relaxation flag (0=none,1=clim,2=nwp,3=observed) 0 'icmflg' = ice mask flag (0=none,1=clim,2=nwp,3=obs/coupled) 1.e5 'prsbas' = msl pressure is input field + prsbas (Pa) 0 'mslprf' = msl pressure forcing flag (0=F,1=T) 0 'stroff' = net strs offset flag (0=F,1=T) 0 'flxoff' = net flux offset flag (0=F,1=T) 0 'flxsmo' = smooth surface fluxes (0=F,1=T) 1 'relax ' = activate lateral boundary nudging (0=F,1=T) 0 'trcrlx' = activate lat. bound. tracer nudging (0=F,1=T) 1 'priver' = rivers as a precipitation bogas (0=F,1=T) 0 'epmass' = treat evap-precip as a mass exchange (0=F,1=T)

Question 2: Nesting Problem 

I've seen example of HYCOM simulations (like the Gulf of Mexico nested example) that use restart files to quickly approach a realistic ocean state. I'm wondering if this technique is also beneficial for my climatological simulation to reduce spin-up time, especially since I plan to conduct sensitivity experiments on mixing parameters. If I use the same restart file (derived from GLBb0.08) for all my sensitivity experiments, will this impact the differences in results between the experiments? My concern is that using the same initial state might artificially constrain the range of variability I see. 3. My `yrflag` is set to 0 (360-day year). The example setting `'bnstfq'` and `'nestfq'` to -30.5 for monthly average archive files however the 'yrflag' set to 3(actual run). Should I set these parameters to `30` instead, to align with my 360-day year? 

I appreciate your time and expertise in addressing these questions. Your insights will be invaluable as I move forward with my simulations. 

Sincerely

[Alan Wallcraft]

I suggest you setup exactly like HYCOM-examples/GOMb0.08 /expt_01.2/ In other words, same resolution same layers as GOFS 3.1 Reanalysis.

This is using cfsr_gom forcing, which you would replace with cfsr forcing.

Once this is setup, you can generate CFSR 2003 forcing as I described in my first post, or perhaps this isn't necessary (see below).

If I was dong a mixing parameter study, I would probably choose two seasons (e,g, winter and summer, or a Monsoon season) and run for two months from a GOIFS 3.1 initial state for each and look at the 2nd month.  The reason for the short run is that current features will diverge in twin runs after 60-90 days.  This is assuming that mixing parametrizations take effect quickly.  Write out hourly archives to capture the daily effect of solar heating which is in the hourly CFSR fields.

I would probably choose 2003 for my case studies, since I know that CFSR 2003 is a "typical" year.  But if you choose a different year (or several years) in this setup you can use the CFSR forcing for the actual year you are running.

Alan.