Let ww3_grid specify output boundary conditions to rotated grids

[CarstenHansen]

I am working on a feature branch fb_rtd2 which is an extension to the /RTD switch. It provides a method to output boundary conditions to a rotated lat/lon grid. This fulfills our need to create one-way nesting to a 9-nmi grid around Greenland. I will await Chris Bunney and colleagues at UKMO to give it a critical look and expect to send a pull request before end of august. https://github.com/CarstenHansen/WW3/tree/fb_rtd2

[ajhenrique]

Hi @CarstenHansen do you have any progress to report on this issue? Thanks.

[CarstenHansen]

Hi @ajhenrique. I am waiting, with patience, for hopefully critical feed-back from @ukmo-ccbunney and @ukmo-ansaulter. The feedback is needed because 1) it is possible at run an SMC model with the /RTD switch, 2) they made the 2018 enhancements that makes my enhancement possible, and 3) ww3_ounf.ftn becomes more complex because the suggested enhancement allows a standard lat-lon model to be set up with the /RTD switch. Maybe also I should learn to run run relevant regtests?

[ukmo-ccbunney]

Hello @CarstenHansen , I'm sorry I have not had a chance to have a proper look at this yet - I've been a bit snowed under since returning from 5 weeks parental leave! I'm working on a PR at the moment to fix some bugs that are stopping the Met Office from achieving our Trusted Institutional Fork status. Once this is sorted, @ukmo-ansaulter or myself will review of your feature branch ASAP! Regards, Chris.

[ukmo-ansaulter]

Hi @CarstenHansen . @ukmo-ccbunney and I have looked through the changes you've proposed. The concept and code changes seem fine, although I have added one comment regarding the logic in ww3_ounf.ftn for you to look at. There is probably a requirement for some further testing (maybe we need to run your code with our rotated grid models for a comparison) and an update to the manual (as this option means we need to compile a standard grid model with /RTD if any of the nested models are rotated).

[CarstenHansen]

Thank you @ukmo-ansaulter and @ukmo-ccbunney for looking this through. I agree with your comment that there should be no special logical conditions in ww3_ounf.ftn in case you are running an SMC grid. I will appreciate if you try to run my code in a rotated grid model of yours. Especially if you run an SMC grid model for which I have no experience.

[CarstenHansen]

@ukmo-ansaulter and @ukmo-ccbunney: I agree there should be additional three or four sentences in the manual stating three additional points: 1) With RTD in the switch file, output b. c. to one or more nested grids, being either rotated or standard lat-lon, can be written to files nestI.ww3 by specifying in the namelists the latitude and longitude of each nested file. 2) When applying the boundary conditions from such a file to a model on a standard lat-lon grid, the RTD switch is not required in compiling the executables for that model. 3) Without the compile switch RTD it is still possible (I think) to output to out_pnt.ww3 the wave spectra in the individual nesting grid points and pre-process these data for the nested run using the programs ww3_ounp and ww3_bounc or ww3_bound (this must be more precise - I havn't tried this procedure).

[ukmo-ccbunney]

Hello @CarstenHansen ,

I have run a test using your fb_rtd2 branch on our Global configuration and nested Atlantic Margin Model (AMM; formulated on a rotated pole). I have also run the same configurations using the develop branch as a control.

The results confirm that the nest files are the same between the develop and fb_rtd2 branches (using WW3_BOUND to check the indices and interpolation coefficients of the boundary spectra).

The only difference is in the output netCDF file for the non-rotated SMC global model: this contains attributes and variables relating to the rotated pole that should not be there; this was expected and discussed in the comments above.

When you have made the changes discussed in previous comments, I will rerun the test again. However, it all looks pretty good from our end! Nice work.

One small related comment (and not an action on you): I notice that when running the WW3_GRID program with the !/O2 switch (to produce a list of input boundary locaitons), the output is missing for grids using the SMC scheme. This is due to the way that the boundary points are dealt with internally by the SMC code. We have SMC grid generation tools here at the Met Ofice (which we intend to share with the wider community) that do provide a list of boundary points as part of the output, but it is worth noting that the method described in the manual will not work for SMC grids.

[CarstenHansen]

Thank you @ukmo-ccbunney, I am very happy to see this.

I have removed the condition ' .OR. SMCGRD' in the two paces in ww3_ounf.ftn that cause the wrong NetCDF attributes related to a rotated pole (noticed by @ukmo-ansaulter) and I have push'ed a new commit ddbaa879afff09702c2135a4fbfd9220d9400e9f also including simplifications to a few comments.

[CarstenHansen]

I will dig into the manual and suggest the few necessary updates to sections 4.4.9 Rotated grids, G1.1 ww3 grid.inp, and G.1.2 ww3 grid.nml. Also check for consistency with Sect. B1, step (4) in the instructions for setting output boundary conditions.

[CarstenHansen]

Hi @ukmo-ccbunney and @ukmo-ansaulter. I have modified the manual (file manual/num/rotagrid.tex and pushed to commit https://github.com/CarstenHansen/WW3/commit/6a0ffacdcfefe3cc72bfc5906feb9242f4fb6394. I think Jian-Guo Li should be consulted to see if the text reads OK. I have kept the reference to the traditional format of input file ww3_grid.inp, not mentioning the 'new' format ww3_grid.nml. This is because the example in manual Sect. G.1.2 does not show how to define the namelists ROTD and ROTB, but only how to define the containing filename GRID%NML= ’namelists.nml’. This seems to be a separate issue with the manual, since that file also contains the example of an ’Out of the box’ test setup.

[CarstenHansen]

Here is a print of the two pages modified: manual_pp151-152.pdf

[ukmo-ccbunney]

@CarstenHansen - that all looks very sensible to me. Cheers, Chris.

[CarstenHansen]

Incorporated in Pull request "UKMO Staging [fb_rtd2, bf_coupling condition, bf_smc_omp]" #254