Add manufactured solution tendency terms to Omega

[hyungyukang]

This PR adds custom tendency terms required for the manufactured solution test case to Omega. This feature can be tested in conjunction with the Polaris package, which has included a convergence study leveraging this capability. The details of this test case can be found in Section 2.10 and Figures 13 and 19 in Bishnu et al. 2024 and the manufactured solution test in Polaris.

The error norms for this test case are expected to demonstrate second-order convergence. The test results will be posted in this PR following integration with Polaris for this test case.

This PR does not modify the unit tests but passed them on Frontier using both CPU and GPU.

Checklist

• [ ] Testing
  • [ ] Unit tests have passed. Please provide a relevant CDash build entry for verification.
  • [ ] Polaris test suite has passed

[hyungyukang]

Although personal testing indicates second-order convergence for 'Default,' 'Del2,' and 'Del4,' this must be validated with Polaris.

The above test was conducted on Frontier GPU using crayclanggpu.

[mwarusz]

@hyungyukang I have one small suggestion. Instead of clearing and re-creating default tendencies you could do this:

// these are empty by default
CustomTendencyType CustomThickTend;
CustomTendencyType CustomVelTend;

if (UseCustomTendency) {
   // get manufactured tendencies etc
   CustomThickTend = ManufacturedSol.ManufacturedThickTend;
   CustomVelTend = ManufacturedSol.ManufacturedVelTend;
}
// one unconditional call to create
Tendencies::DefaultTendencies = create("Default", DefHorzMesh, NVertLevels, NTracers, &TendConfig, CustomThickTend, CustomVelTend);

[hyungyukang]

@hyungyukang I have one small suggestion. Instead of clearing and re-creating default tendencies you could do this:

@mwarusz , thank you very much for the suggestion. I agree with you. I just tried it and it's working perfectly! I'm going to commit the code soon. May I include your name in the reviewer list if you are comfortable with it?

[mwarusz]

@hyungyukang

May I include your name in the reviewer list if you are comfortable with it?

Sure.

[hyungyukang]

@xylar and @cbegeman ,

To enable this feature, Polaris needs to make some changes from config/Default.yml. Here is the difference between omega.yml I used for the default manufactured solution test and config/Default.yml.

Diff. between `omega.yml` and `config/Default.yml`

```diff @@ -1,13 +1,13 @@ Omega: TimeIntegration: CalendarType: No Leap - TimeStepper: Forward-Backward + TimeStepper: RungeKutta4 TimeStep: 0000_00:10:00 StartTime: 0001-01-01_00:00:00 - StopTime: 0001-01-01_02:00:00 + StopTime: 0001-01-01_10:00:00 RunDuration: none Dimension: - NVertLevels: 60 + NVertLevels: 1 Decomp: HaloWidth: 3 DecompMethod: MetisKWay @@ -21,17 +21,17 @@ Omega: PVTendencyEnable: true KETendencyEnable: true SSHTendencyEnable: true - VelDiffTendencyEnable: true + VelDiffTendencyEnable: false ViscDel2: 1.0e3 - VelHyperDiffTendencyEnable: true + VelHyperDiffTendencyEnable: false ViscDel4: 1.2e11 TracerHorzAdvTendencyEnable: true TracerDiffTendencyEnable: true EddyDiff2: 10.0 TracerHyperDiffTendencyEnable: true EddyDiff4: 0.0 - UseCustomTendency: false - ManufacturedSolutionTendency: false + UseCustomTendency: true + ManufacturedSolutionTendency: true Tracers: Base: [Temperature, Salinity] Debug: [Debug1, Debug2, Debug3] @@ -49,7 +49,6 @@ Omega: UseStartEnd: false Contents: - State - - Base # Restarts are used to initialize for all job submissions after the very # first startup job. We use UseStartEnd with a start time just after the # simulation start time so that omega does not attempt to use a restart @@ -84,8 +83,8 @@ Omega: Mode: write IfExists: replace Precision: double - Freq: 1 - FreqUnits: months + Freq: 10 + FreqUnits: hours UseStartEnd: false Contents: - Tracers ```

[philipwjones]

@xylar and all. As I mentioned in the Error design, most of these errors should indeed be critical and abort, but we don't have a way of doing that easily until I get the new Error capability implemented (LOG_CRITICAL currently does not abort automatically). As part of that implementation, I'll be doing a pass through the code and replacing many of these error calls and error returns with critical errors and aborts when needed. But if we want to at least upgrade these to critical error messages, that will be a good hint about where we want this to happen.

[philipwjones]

And while I'm commenting on this PR...do we need to start thinking about multiple YAML configs now that we're starting to get conflicts. In particular, the streams unit test with this change will be writing output every 10 hours for a full year so probably not what we want.

[xylar]

@philipwjones, thanks for the update. I didn't realize that we weren't there yet with LOG_CRITICAL, sorry about that.

[xylar]

In particular, the streams unit test with this change will be writing output every 10 hours for a full year so probably not what we want.

I don't think @hyungyukang is proposing any changes to the YAML file (other than adding a few config options). These are the changes that Polaris will be making to the YAML file it uses (made manually for now).

[philipwjones]

Ah yes, I misread the comment on the Default.yml changes.