moved the Forcing to its own IO by alicebarthel · Pull Request #443 · E3SM-Project/Omega

alicebarthel · 2026-06-24T22:51:43Z

This PR updates the code to expect the forcing from a dedicated forcing IO (by Default forcing.nc)

A polaris PR is required to update the tests to read forcing from forcing.nc instead of the init.nc, under development at https://github.com/alicebarthel/polaris/tree/update-forcing-io

Checklist

alicebarthel · 2026-06-24T22:54:16Z

The following tests FAILED:
19 - IOSTREAM_TEST (Failed)
23 - FORCING_PLANE_TEST (Failed)
24 - FORCING_SPHERE_TEST (Failed)
25 - TENDENCIES_TEST (Failed)
27 - STATE_TEST (Failed)
35 - DRIVER_TEST (Failed)
Errors while running CTest

but the omega.log only shows expected errors. I'll investigate more tomorrow.

cbegeman · 2026-06-25T16:12:40Z

+void Forcing::readStreamIntoArrays() {
+   Error Err;
+
+   Real FillValueReal = -999._Real;


Should we be doing anything here to make it consistent with #428 or is the change best made after #428 is merged?

yes, I am aware of the overlap/conflict with #428.
My thought was to get that one in first and then update asap for #428. Or vice versa if #428 gets merged first.
I am not sure how to make this section consistent with #428 and test it without the whole #428 change.

cbegeman · 2026-06-25T16:13:44Z

+
+   std::string StreamName = "Forcing";
+
+   // Attempt to read stream; if unavailable, log and fall back to zero forcing.


Does it fall back to zero forcing because all forcing tendencies will be computed and applied with zeros?

yes, if the tendency flag is on but the forcing stream is missing, it defaults the forcing to zero and calculates the tendencies. If the tendency flag is off, then it skips the tendency calculation.
We can change that behavior later if we want a visible fail, the idea here was to write it in the log and proceed without failing.

@cbegeman I suggested this; in order to produce as few breaking changes as possible. With us staring down the coupling deadline, I figure this might be worth it (though in generally it's not the best practice).

I think if we are OK with this for now, we should open up a linked issue about "failing fast" here. We can circle back to this after delivering a first pass at the coupled model.

I don't want to speak for @alicebarthel, but I don't think we are that tied to this approach. We are just trying to mindful of the work left and timeline. If people feel very strongly against defaulting to zeros, then I'd think we are okay with dropping this and just failing if the read is unsuccessful.

Is there a check for whether any forcing tendency is on before we attempt to load the forcing stream? I.e., if we leave off the default-to-zero feature and the forcing stream is not provided, will the simulation always fail?

There isn't a check on the tendency flag before the Forcing::init() or read from file.
Because the tendency flags are per forcing type, I didn't think of that since I expect most longer cases to have some forcing, but for the spin-down ones, we may be able to skip this altogether?
A check on whether at least one forcing flag exists is worth considering...

I don't feel strongly that we need to run through all forcing flags before trying to read from the forcing stream. My concern with default-to-fill-value right now is that we may be introducing a requirement to provide a forcing file for all cases.

It could be good in the long run to have: if SfcStressForcingTendencyEnable is True, throw a critical error if SfcStressZonal and SfcStressMeridional are not included in the forcing stream (and do the same for other forcing fields and their corresponding flags).

I'm fine with default-to-zero for now as long as we open an issue that this needs to be fixed later.

Agreed! I'll open an issue.
The key point of default to zero was indeed to avoid introducing a forcing file requirement for now.

Great. Glad we're on the same page

alicebarthel · 2026-06-26T00:50:06Z

OK, here is an update:

because we added forcing into the yml file, IOStreams validateAll() now needed the forcing fields to be registered and a forcing file to be present --> i added these inits for the dependencies in IOStreams and StateTest.
to keep the coverage of the computeStress test, I had shifted the forcing test to have a SPHERE and a PLANE test at run time (based on existing tests). Thus this requires forcing files with the corresponding nCells dimensions. I have made these files manually and now call a different name for each forcing test (mirroring the treatment of the mesh at run time).

The ctests now all pass on pm-cpu (gnu).
They require the 3 new forcing files available on perlmutter at:
/global/homes/a/abarthel/pscratch/omega_scratch

I typically copy these in my base directory the run in each case directory:

cd test
ln -sf  ../../forcing_nCells_7153.nc forcing.nc
ln -sf  ../../forcing_nCells_2304.nc forcingPlanar.nc
ln -sf  ../../forcing_nCells_2562.nc forcingSphere.nc
cd ..

At this stage, anyone testing this PR with ctests should also fetch these.
Ultimately, these will be moved to be with the meshes if we keep this structure.

vanroekel · 2026-06-26T03:49:09Z

+    # and the surface restoring target files (if appl.).
+    Forcing:
+      UsePointerFile: false
+      Filename: forcing.nc


not saying we should do this, but could we set this to init.nc to delay the need for a polaris PR?

I think this could be helpful for the tests that do not have any forcing. It would be weird to me to create an (empty?) forcing file for cases that wouldn't otherwise need one.

I think it would be better to alter the logic so the forcing stream isn't read if it's not needed. Pointing to an unrelated file by default seems like a messy solution to me.

Or to comment out the forcing stream by default.

We could change the FreqUnits to never for now. And manually change to OnStartup for the few test we actually need it?

Yes, I think that's the right solution.

That sounds ideal. @alicebarthel Could you use this approach in a companion Polaris PR and check that it works as expected?

Yes, I like this approach. I'll look into it and check its behavior.

added the Forcing IO in yml and read from streams at startup

ce219d6

alicebarthel requested a review from andrewdnolan June 24, 2026 22:52

cbegeman reviewed Jun 25, 2026

View reviewed changes

alicebarthel added 3 commits June 25, 2026 16:59

added Forcing::init() needed before the IO calls

cac6985

added the forcing file name change for the mesh change

ffafd89

revert change to error message for read in

8d996bd

vanroekel reviewed Jun 26, 2026

View reviewed changes


		std::string StreamName = "Forcing";

		// Attempt to read stream; if unavailable, log and fall back to zero forcing.

Uh oh!

Conversation

alicebarthel commented Jun 24, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

alicebarthel commented Jun 24, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

andrewdnolan Jun 25, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

alicebarthel commented Jun 26, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

alicebarthel commented Jun 24, 2026 •

edited

Loading

andrewdnolan Jun 25, 2026 •

edited

Loading

alicebarthel commented Jun 26, 2026 •

edited

Loading