switching of cppdefs.h options

[nageswararao]

Hi all,
I am modelling indian ocean region and for my domain I kept south as open and all other as closed. I switched on the tracer boundary condition namely SOUTH_TNUDGING. But when I am running the code, it is not writing the SOUTH_TNUDGING in CPP information. What it means? Is that option is activated or not? If it is not activated why it is not activated? I also used SOUTH_M3RADIATION,SOUTH_FSCHAPMAN,SOUTH_M2FLATHER as open boundary conditions.
Please tell me why it is not switching on ......?????

Thanks in advance.

With regards,
G.NageswaraRao.

[wilkin]

Look at your .f90 files for the open boundary conditions and you will see whether the cpp definitions are indeed active. There are 4 common ways to make this error:

1. you spelled the cpp flag wrong
2. you reset the flag with a subsequent definition of the same flag in your cppdefs file
3. you made the flag redundant by choosing another boundary option that takes precedence
4. you edited the wrong application block in cppdefs because they all look the same (e.g. inside if defined UPWELLING when your application is something esle).

John.

[nageswararao]

Thanks John for ur reply. But I didn't do any mistake in my application regarding what u had said. I checked the checkdefs.f90. In that SOUTH_TNUDGING is not switched on. Why it is happening? Along with SOUTH_TNUDGING I had defined the TCLIMATOLOGY,SOUTH__M3RADIATION,SOUTH_FSCHAPMAN,SOUTH_M2FLATHER regarding tracers and boundary conditions.
Please reply me.

Thanks in advance.

G.NageswaraRao.

[wilkin]

G.NageswaraRao sent me his list of cppdefs and the stdout report that ROMS gives to show which options are in fact active and now I can conclude this thread.

The option SOUTH_TRADIATION was not defined, and therefore the option SOUTH_TNUDGING was never activated because the nudging option is nested within the radiation option. This combination of options implements the open boundary approach described by Marchesiello et al 2001. The method applies nudging at the boundary to constrain an errant radiation scheme. Note that OBCFAC and TNUDG in the ocean.in file interact to set the nudging time scale depending on the sense of the radiation direction as determined by the radiation option, hence the nesting of the schemes.

Arguably, there is a case for having these options separate so that either one but not the other can be active, but that does not happen to be the way it is now. It would require modification to the logic that sets the nudging time scale since radiation direction information would be absent.

Debugging this error shows the value of carefully reviewing the stdout report showing the cppdefs - this gave it away immediately.

Also note that in general it is our practise to indent the cpp directives in the code when they are nested, and thus in t3dbc_im.F the #ifdef SOUTH_TNUDGING is indented further than #define SOUTH_TRADIATION to draw attention to the nested logic.

Marchesiello, P., J. C. McWilliams, and A. F. Shchepetkin (2001), Open boundary conditions for long-term integration of regional oceanic models, Ocean Modelling, 3, 1-2, 1-20.

[nageswararao]

Hi John,
Thanks for ur detailed explanation. I got from ur conclusion that we have to use both SOUTH_TRADIATION,SOUTH_TNUDGING and only SOUTH_TNUDGING will not be effective.
So I switched on both the terms and now it is writing both conditions in stdout report of ROMS. In t3dbc_im.f90 it is written that southern edge implicit upstream radiation condition is active. Now I am getting some input error saying:

OPENCDF - inconsistent size of dimension: xi_rho 359 361
ROMS/TOMS - IO error ................. exit_flag: 4

Elapsed CPU time (seconds):
I had given the correct LLm and MMm values in mod_param.F
In preparing input netcdf files using Preprocessing_tools we will get 2-3 points more than the LLm and MMm values I think this is the cause of error and again listed out the files with same LLm and MMm values in ferret. But now it is showing the error that "unable to find the variable (sustr) in forcing file" But I am having that variable in forcing file.
When I switched on only SOUTH_TRADIATION, I am not getting good results like vertical profiles with no proper thermocline,etc..

I am unable to fix the problem. Please tell me what caused me this error.

Thanks in advance.

G.NageswaraRao.

[kate]

OPENCDF - inconsistent size of dimension: xi_rho 359 361
ROMS/TOMS - IO error ................. exit_flag: 4

Well, what are your dimensions, both in your NetCDF files and in mod_param.F?

Guidelines are that you want Lm and Mm to have factors of two if you are going to be running in parallel. This assumes that you run on say a system with nodes of eight processors so that you will want a factor of eight somewhere, in your case maybe Lm=360.
Now, the grid will actually have two more rho points than that for the boundary/image points just outside the domain. What opencdf calls xi_rho should then be 362. All of the grid, boundary, forcing, initial, etc. files should be prepared with that in mind.

[nageswararao]

Hi Kate,
My original Lm and Mm values are only 359,251.I had given those values in mod_param.F only. In my all input files the x ranges from 1:361 and y ranges from 1:252. According to what u said it should not give error. But I am getting the error.

OPENCDF - inconsistent size of dimension: xi_rho 359 361
ROMS/TOMS - IO error ................. exit_flag: 4

Any help is appreciated.
Thanks in advance.

G.NageswaraRao.

[m.hadfield]

My original Lm and Mm values are only 359,251.I had given those values in mod_param.F only. In my all input files the x ranges from 1:361 and y ranges from 1:252. According to what u said it should not give error. But I am getting the error.

OPENCDF - inconsistent size of dimension: xi_rho 359 361
ROMS/TOMS - IO error ................. exit_flag: 4

The message is telling you that you have tried to open a netCDF file in which dimension xi_rho has size 359 (not 361 as required). I suggest you examine your files closely with ncdump.

[nageswararao]

Hi all,
Thanks for all who had given reply to me. I got that problem because I didnt give any boundary file till now and I also dont know how to create boundary file till now. But now using Schepet post in ROMS problems thread I had created the boundary file and now I am able to overcome that problem.

Thanks each and all.

With regards,
G.NageswaraRao.