make_se_grid.sh tool is broken

[adamrher]

What happened?

tools/se_grid/make_se_grid.sh only works for older code bases and would need to be updated to run with the current code base. There are at least 3 issues:

1. Assumes the scratch directory is /glade/scratch/ rather than /glade/derecho/scratch/
2. Requires you add the new grid entry to bld/config_files/horiz_grid.xml, which is no longer necessary for SE grids
3. Assumes the code is using the MCT coupler with grid aliases defined in cime/config/cesm/config_grids.xml, rather than in ccs_config in newer code bases

The tool still works with the cesm2.2.2 release branch provided you manually fix (1).

@gold2718 @jtruesdal

What are the steps to reproduce the bug?

try running make_se_grids.sh

What CAM tag were you using?

cam6_4_077

What machine were you running CAM on?

CISL machine (e.g. cheyenne)

What compiler were you using?

Intel

Path to a case directory, if applicable

No response

Will you be addressing this bug yourself?

No

Extra info

No response

[nmizukami]

Hi Shervan, checkMassBalance is indeed new, but this is to check domain wide water balance (integral of storage change over domain = integral of input over the domain - integral of outflow from the most downstream reaches over the domain), not per reach/lake. per-reach water balance is printed out in log whenever it exceeds the tolerance. is it way off (so something missing) or how much is the balance error roughly?

lake water balance tolerance is lakeWBtol=1.e-3_dp [mm] now (in public_var.f90). if you make this huge (this is not solution though, just test), the model properly finish?

[ShervanGharari]

Hi @nmizukami,

The lake water balance currently triggers warnings because runoff is no longer being added to lakes, even though it’s still included in the water balance calculations. As a result, every lake generates a warning message, leading to a very large number of print statements during the simulation. While the simulation does complete successfully (which is good), the volume of these messages becomes problematic — they're captured in the log files or returned by Python’s multiprocessing interface, and I suspect this might be causing the workflow to hang.

In my next pull request, I plan to explore a more robust fix for managing lake water balance under different input conditions for lakes and reservoirs. In the meantime, I have a simpler question: Is there a way to suppress all print statements in mizuRoute using a control file flag, rather than modifying the executable or adding a flag when simulating mizuRoute?

For now, I’ve temporarily commented out the specific water balance print statements to test whether that resolves the issue.

Any thoughts or suggestions would be greatly appreciated, and thank you again!

[nmizukami]

Hi Shervan, right now, we don't have any in control file. It may be reasonable to add water balance tolerance in control file. it is now hard-coded in pulic_var.f90 and can be exposed in a control file (so should be one line addition). Now, this is only for lake, but maybe river reach could use the same tolerance (may need testing)