nesting problem: difference in bathymetry

[Luana F. Bueno]

Hi Alan,

I hope you are fine. I have some doubts about the restart file and the boundary conditions that I would like to ask you about it.

I am nesting my regional model of 1/36 resolution in a 1/12 global model. Both models have the same vertical structure (number of layers), however their bathymetries are different. I did the merge bathymetry considering 19 points, since my grid is IDM(741)xJDM(920), following from 1.0 (19) to 0.1 (1). Is this merge bathymetry enough to deal with the problem of bathymetry difference in the buffer zone? I am asking that because what I have seen is that when the bathymetry of the regional model is deeper than the bathymetry of the global model, it gives a negative dp. 

Besides that, when creating a restart file using an archv from the global model it carries the bathymetry of this model and not the bathymetry of my model that goes for example in the layers structure of the climatological restart used as the model input restart file. Shouldn't it follows the bathymetry that I gave when creating the restart file? Because it will give negative dp already in the first step.

I am confused about nesting models with different bathymetry because it seens that it will always follow the original bathymtry of the global model despite informing the bathymetry of my model.

I appreciate so much your help.

Best regards,

Luana Bueno

[Alan Wallcraft]

See GOMb0.08 or how to set-up a regional configuration nested in a global domain The bathymeyrty must be interpolated from the coarse depths and coastline in the buffer zone (where nest_rmu is non-zero), a combination "near" the buffer zone, and the fine depths and coastline everywhere else (step 1d). Note that there must be land behind the open boundary in the model bathymetry, but the nest files must be made with sea behind the open boundary (step 1b). Note that this works because the model bathymetry is the same as this bathymetry everywhere that the nested archive is used.

As you say, when creating the archive file that becomes the restart file, you need to use the find grid model bathymetry (that you created in step 1d).  This is covered in 5-D (How to create a restart file from the GLBb0.08 suitable for GOMb0.08) step b.

Alan.

[Luana F. Bueno]

Hi Alan,

Just now I had the chance to get back to this issue. I understand that the process that you described above is a way of treating the bathymetry in the buffer zone more carefully to avoid errors associated with the difference between both models' bathymetry.

The thing is that I am testing one configuration in many versions and what I found is that:
HYCOM version 2.2.14: NO problem with the boundaries from the IC or BC
HYCOM version 2.2.18: negative DP error in the first time step regarding the IC and BC
HYCOM version 2.3.01: NO problem with the boundaries from the IC or BC

So my question is, the newest version already treats the IC and BC properly to avoid this kind of problem or was I lucky and the process you described in your answers is needed anyway?

Another issue that I would like to check with you is about the time of processing. I just figured out with your help (answer from the other email) the flags to properly compile the HYCOM in the AWS cluster (see attached file). I compiled both versions of the model (2.2.18 and 2.3.01) and that inconsistency of files .ab was fixed, however, the newest version is much slower. It takes 2 min with versions 2.14 and 2.18 to run one day, while the newest version 3.01 takes 14 min. Do you know a way that I could optimize the compilation for the newest version?

I do appreciate your help.

Regards,

Luana Bueno

[Luana F. Bueno]

Sorry, I forgot to attach the file. Here it goes!

[Alan Wallcraft]

If the nesting archives do not have sea behind the open boundaries then the barotropic velocity through the boundary  is not correct, probably weaker than it should be and perhaps zero.

If the bathymetry in the nest buffer zone (rmu non-zero) is not from the coarse grid then the interpolation will try to handle the mismatch but it may not do a good job.  This might work OK even so, since you are relaxing to these archives.

The difference between 2 min and 14 min isn't due to compiler flags.  Please provide .log files from the 2.14/2.18 case and the corresponding 3.01 case.  Make sure 'btrmas' is 0 (false) because true is slow and isn't well tested.

Alan.