Bugfix rotbd#1
Conversation
| !! Use rotation angle and action conversion sub. JGLi12Jun2012 | ||
| USE W3GDATMD, ONLY: NK, NTH, NSPEC, AnglD, PoLat | ||
| USE W3SERVMD, ONLY: W3ACTURN | ||
| !! BCTURN==.TRUE. only when calling W3UBPT from W3IOBC, |
There was a problem hiding this comment.
W3IOBC is not calling W3UBPT, as far as I can tell? Isn't it W3WAVE?
There was a problem hiding this comment.
Yes, I think you are right. I now pushed a correction.
| IDSTRBC = 'WAVEWATCH III BOUNDARY DATA FILE' | ||
| !/ | ||
| #ifdef W3_RTD | ||
| ! Logical to tell subroutine W3UBPT if inbound boundary conditions are to be roteted |
There was a problem hiding this comment.
Spelling mistake: "roteted" --> "rotated"
There was a problem hiding this comment.
Changed this. To be committed and pushed. My fingers often makes this wrong auto-correction.
| USE W3SERVMD, ONLY: W3ACTURN | ||
| !! BCTURN==.TRUE. only when calling W3UBPT from W3IOBC, | ||
| !! This is in order *not* to turn 2-way nested bdy data under ww3_multi | ||
| USE W3IOBCMD, ONLY: BCTURN |
There was a problem hiding this comment.
Would it make more sense to control this behavior from W3WAVE instead of loading this variable from W3IOBCMD? I guess that W3WAVE only calls W3IOBC if it needs to write a nest.ww3 file, so one could also introduce the logical in W3WAVE instead of W3IOBCMD. This logical could then work as an input when calling W3UBPT in W3WAVE and then you would not have to reset BCTURN=FALSE at the bottom. With my limited insights into WW3 architechure I would think that this is a more readable edit.
There was a problem hiding this comment.
This sounds reasonable. Let us check the logic of such change when we discuss the code.
There was a problem hiding this comment.
CHA to understand where w3iobc is called in w3wave and determine how straightforward it is to modify to control behavior from there. Note that if controlled from w3wave it is not necessary to keep modifications to w3iobcmd.F90 (assumption).
| $ fp sip thm ncos xm six ym siy hmax | ||
| 0.10 0.0001 225. 100 -3.15 -0.675 -3.15 0.675 10.0 | ||
| $ -0.225*3 0.225*3 | ||
| $ 0.10 0.0001 225. 100 600.E3 -75.E3 600.E3 75.E3 10.0 |
There was a problem hiding this comment.
Remove these commented lines?
There was a problem hiding this comment.
Yes! To be removed in the next commit.
| @@ -0,0 +1,5 @@ | |||
| &OUTS E3D=1, TH1MF=1, STH1MF=1, TH2MF=1, STH2MF=1 / | |||
| &PRO2 DTIME = 0. / | |||
| &PRO3 WDTHCG = 0., WDTHTH = 0. / | |||
There was a problem hiding this comment.
Are settings for both PRO2 and PRO3 mentioned as the regtest can be run with different switches that both involve PRO2 and PRO3? The info_fcoo only mentions switch_PR3_UQ_MPI_RTD.
There was a problem hiding this comment.
This may be a reason, but I just copied the contents of namelisis_fine.nml without thinking about it.
| @@ -0,0 +1 @@ | |||
| 1.35 1.35 'point_A' | |||
There was a problem hiding this comment.
Please remind me; point output coordinates are defined in the rotated grid, correct? So this coordinate is within the fine grid?
There was a problem hiding this comment.
I actually forgot the answer to this. I think the answer is given in the User manual, or check the points specified for the FCOO GRL9 grid.
| # + grdset_b: outer + fine | ||
|
|
||
| # * Switch: | ||
| # + switch_PR3_UQ_MPI_RTD |
There was a problem hiding this comment.
I think you miss to add this switch to the pull request?
There was a problem hiding this comment.
Thanks, to be added in next commit
| # Run the WW3 run_cmake_test script at FCOO | ||
| # | ||
| # # Load a build environment using the gfortran compiler: | ||
| # | ||
| # spack load netcdf-fortran%gcc | ||
| # spack load cmake%gcc | ||
| # | ||
| # # Run the WW3 run_cmake_test script from the directory containg the WW3 repo: | ||
| # | ||
| # ../ww3_resurser/run_regtests.sh -N -g rtd -m grdset_r -n 3 -s PR3_UQ_MPI_RTD \ | ||
| # mww3_test_02 |
There was a problem hiding this comment.
We are moving away from Spack - let's discuss this tomorrow. Also, I don't think we want FCOO specific information in the pull request. All FCOO specific information must be put elsewhere, in my opinion. As the information is this file is more or less identical to what's written in info_rtd I suggest to delete this file.
There was a problem hiding this comment.
I agree. info_fcoo is to be removed in the next git commit
There was a problem hiding this comment.
You wrote a regtest that checks that behavior is as expected for ww3_multi with switch RTD. Are we missing any checks, e.g. that a ww3_multi model run with a regular pole is able to output boundary conditions to a destination grid that is rotated?
There was a problem hiding this comment.
If ww3_multi writes boundary files not identical to the output with ww3_shel, that would be a separate issue.
There was a problem hiding this comment.
CHA: Missing to test that if outer domain has incoming boundary conditions (nest.ww3 defined) it is correctly rotated to rank 1 grid and that BCTURN is correctly set to false afterwards when nesting between outer and fine grid. That would test both cases of BCTURN.
|
I am preparing an extension to the rotated grdset_r with a very coarse grid that reads boundary data from a file nest.ww3, which is first generated by bi-linear interpolation from three spectra at three points surrounding the (rotated-)southern grid edge. nest.ww3 is generated using the program ww3_bound, and the three spectra are copied from ChrisBunney's regtests/ww3_tr1/input_bndin/bnd{1,2,3}.spc. The spectra direction origin should be shifted 180 degree, as in Chris' case they are surrounding the (standard-)eastern boundary edge, and in my case the (standard-)western edge. |
…NROT=.FALSE. in namelist &ROTD
| @@ -0,0 +1,5 @@ | |||
| &OUTS E3D=1, TH1MF=1, STH1MF=1, TH2MF=1, STH2MF=1 / | |||
| &PRO2 DTIME = 0. / | |||
| if [ $grdstr ] | ||
| then | ||
| fileconf="${prog}_${grdstr}${gu}" | ||
| else | ||
| fileconf="${prog}${gu}" | ||
| fi |
There was a problem hiding this comment.
In some cases this does not exist: ww3_strt_${grdstr}${gu} while the version without ${grdset} does exist. Please consider.
| # ./bin/run_cmake_test -N -g rtd -m grdset_r -n 3 -p mpirun \ # | ||
| # -s PR3_UQ_MPI_RTD -w work_bp_PR3_MPI_RTD ../model mww3_test_02 # |
There was a problem hiding this comment.
I am able to run the regtest but not with the -N (use .mnl files) flag. It works with .inp files. The output looks strange, however, and not as presented in your issue post on NOAAs GitHub account. Are you able to run the regtest with .nml files successfully?
3 participants
Pull Request Summary
This bugfix corrects the erroneous advection across multi-grid boundaries when using rotated grids (switch RTD) with ww3_multi
This bug fix is intended to be pulled by @MadsBruunPoulsen into the FCOO/WW3 branch
fb_xsmf.It is a tentative solution to the issue NOAA-EMC#1579 by @CarstenHansen, following the suggestion given there.
Description
The bug is described in detail in NOAA-EMC#1579. The solution provides the expected correct grid boundary transfer under
ww3_multi, e.g. as illustrated in Fig. 2.A flag is declared global in
w3_iobcmd.F90where it is set to 'TRUE' only when reading boundary conditions from file (nest.ww3), and used inw3updtmd.F90to indicate when rotation must be done (as suggested in NOAA-EMC#1579 (comment)). Setting this flag is not a property of the individual grid, but distinguish if if boundary conditions are either read from file or transferred by theww3_multimechanism.Issue(s) addressed
Fixes NOAA-EMC#1579 (comment)
Commit Message
Correct the erroneous advection across multi-grid boundaries when using rotated grids (switch RTD) with ww3_multi.
Co-author: @MadsBrunPoulsen.
Check list
Testing
grdset_r), an extension to the existing advection regtestmww3_test02.grdset_rtomww3_test02. Suggested additions to theinfofile is provided ininfo_rtd. The program regtests/bin/run_cmake_test is modified to be able to create the initial files for the rotated grids.