Adds wetting and drying capabilities to RK4 with dam break

[pwolfram]

Adds simple RK4-based wetting and drying with testing via a dam break case against laboratory and ROMS data. This is a work in progress.

[pwolfram]

@mark-petersen, a good place to start is run_wetting_drying_test.sh.

Some helpful notebooks are at

Wetting and Drying, e.g., RK4: https://gist.github.com/bb25228c13a8034f0e882246c5040e2e
Barotropic split explicit component: https://gist.github.com/791d27c629ad85cc5e01d90d72a25fc2
Overflow: https://gist.github.com/9c57e8de11a70abf9bf9a38d929c42ca

[pwolfram]

Wetting and drying for RK4 is needed for #171. We should merge that commit here instead for the first PR of wetting and drying for simplicity.

[pwolfram]

Note, RK4 has a bug that appears resolved by #137.

[pwolfram]

Old archived branch is pwolfram:wettingdrying_test_case before extensive clean-up.

[pwolfram]

@xylar and @mark-petersen, the plan here is to bring in RK4 for the dam break problem as a first cut to keep the analysis and review cleaner and then progressively add more wetting and drying cases and features via new PRs. If there is a most time-efficient and clearer approach please recommend it!

[xylar]

@pwolfram, this seems like a reasonable way to proceed to me. But it looks like this PR needs to be rebased and a lot of commits should be squashed or otherwise cleaned up before this is ready to review. Let me know when this needs further testing or attention. I'm away both this week and next so won't be able to review until the week of the 15th.

[pwolfram]

Pushed previous work to pwolfram:wettingdrying_test_case_backup and cleaned this up to be specific to the dam break and RK4 wetting and drying.

[pwolfram]

@xylar and @mark-petersen, this demonstrates a simple element of wetting and drying and is a good starting point for a review and test of its minimal capabilities. The key thing here is that this test fails without wetting and drying and is compared against laboratory data and ROMS thanks to @caozd999

[pwolfram]

@caozd999 did a review and should be added to the reviewers' list so that he can confirm his review and post his results. @mark-petersen, can you please add him so that he can do a review?

[pwolfram]

004m case:

012m case:

[pwolfram]

Note, at present the station 8A deviation is due to implementation of the boundary condition. Warner et al (2013) allow the flow to fall out of the domain so there is no pressure gradient on the boundary of the box whereas we use a large domain so water "bunches" up more at 8A outside the dam break region.

[xylar]

@pwolfram, I believe we discussed that the oscillations in MPAS-O might be due to pressure-gradient errors, and we speculated that these might be reduced with a higher-order treatment. Is that still your best guess? They don't worry me at all, but it may suggest that we can't push the layers too thin with the current method for computing the pressure gradient.

[pwolfram]

@xylar, you are correct. I'm thinking it is worth documenting this in this PR to note the following things:

• Oscillations potentially due to pressure-gradient error making this test case a good test for new pressure-gradient code
• The minimal thickness does set the vertical offset of the MPAS-O results against the ROMS and observational results
• The ROMS and observational results use a "fall-off" boundary condition whereas for MPAS-O we just use an extended domain, which means the domain-averaged pressure gradient should be larger for ROMS and the observations and our results at 8A will likely be higher than ROMS and the observational results
• Wetting and drying is needed because otherwise the thin layers cause instability and the test case blows up, making this a great test case to verify that wetting and drying is working correctly.

@xylar, @mark-petersen, @caozd999 please comment on this page with any other comments and I'll incorporate this into the readme for the test case. I'm thinking it should go in the root level underneath dam_break.

[pwolfram]

@xylar and @mark-petersen, just want to be clear here that I would view this PR as sufficiently complete to be merged. Note, it does depend on #137 for long run times but that PR is almost complete as far as I can tell. Thanks!

[pwolfram]

@xylar and @mark-petersen, I know you need this work for ProSPECT (cc @stephenprice) and it has been sitting way too long on account of me. I've pushed up clean changes (and verify it works) and it should be ready for you now.

[pwolfram]

Please let me know if you would like any changes before a merge.

[xylar]

@pwolfram, I would like to review this but I don't have time right now. Are you feeling an urgent need to merge this? Also, I think @mark-petersen is coordinating all merges into ocean/develop up to the v2 code freeze so I don't think you should plan to merge this yourself.

[mark-petersen]

Passes nightly regression, bfb with ocean/develop. Of course, that does not exercise the new code. @pwolfram or @caozd999, please compile with DEBUG=true and exercise the new code additions. If you've already done that, please comment.

[pwolfram]

@mark-petersen, thank you. I've compiled and run the case with DEBUG=true and it produces the output as expected.

[mark-petersen]

Looks good thanks!