Add LLC CPU data canonicalization - #670
Conversation
509b762 to
91815a4
Compare
d201ce9 to
8aa8e76
Compare
91815a4 to
7440baa
Compare
8aa8e76 to
d738b00
Compare
6aa69de to
35caa19
Compare
a21e9c9 to
4276e4a
Compare
4276e4a to
5c2d900
Compare
|
@fomo-bot can you please rebase this PR into a single clean commit on top of the latest main? |
5c2d900 to
47d5ed9
Compare
|
Done. PR #670 is now a single commit on top of latest Codex work
Codex transcript |
|
@fomo-bot can we unify the two different mock LLC datasets in tests, please? I also don't really understand all the complexity around the time stuff. Why do we need to change |
47d5ed9 to
0d2e5f3
Compare
|
Done and pushed. Codex work
Codex transcript |
0d2e5f3 to
dece93c
Compare
dece93c to
0c477e4
Compare
|
@fomo-bot can you rebase this on the latest main please |
fc087cd to
d304b25
Compare
|
Rebased PR branch New branch head: Validation:
Debug info
|
379d3ab to
16a2638
Compare
|
@fomo-bot please fix precommit |
|
Fixed pre-commit and pushed The failure was Verification:
Debug info
|
alxmrs
left a comment
There was a problem hiding this comment.
Looks really great! I mostly have questions about factoring (where to put the new things), and then some conversations with myself to understand the PR.
Thanks for this change, this is really valuable.
|
|
||
| if TYPE_CHECKING: | ||
| from samudra.config import TimeConfig | ||
| from samudra.config import SourceTimeConfig |
There was a problem hiding this comment.
Is there also a non-source TimeConfig that we're keeping around? If not, then should we just keep the name "TimeConfig"? WDYT?
| ) | ||
|
|
||
|
|
||
| def _rename_llc_level_index_vars(ds: xr.Dataset) -> xr.Dataset: |
There was a problem hiding this comment.
I hope there are roundtrip tests for these. Nice to see a function and its inverse.
| return mask_vars | ||
|
|
||
|
|
||
| def canonicalize_llc_datasets( |
There was a problem hiding this comment.
Idea: should we start to create data source specific utility files? e.g. keep data.py generic, and then separate out OM4 vs llc specific utilities? This might help us create better abstractions later on.
There was a problem hiding this comment.
We could also do this after one more dataset gets added (to channel my inner YAGNI).
There was a problem hiding this comment.
It seems like we're fairly close to creating new overridable abstract methods in DatasetSpec for these kinds of functions, but not quite yet.
There was a problem hiding this comment.
Looks like this somewhat exists in config.py. Nice.
There was a problem hiding this comment.
Yeah, I can break out the LLC-specific stuff.
Co-authored-by: Alex Merose <alex@openathena.ai>
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: ee56e6c977
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| train=source.slice(self.train_time), | ||
| val=source.slice(self.val_time), |
There was a problem hiding this comment.
Avoid train/val slicing during eval-only builds
For eval-only runs whose data source contains only the configured inference period, Eval.__init__ calls cfg.data.build() and then only consumes data_container.inference_source, but this return path now slices the train and validation windows for every source first. Because DataSource.slice() raises when those windows are outside the store, standalone evaluation fails before reaching inference even though the train/val splits are unused; defer these slices to training or let eval build just the inference source plus unsliced source metadata.
Useful? React with 👍 / 👎.
|
@alxmrs I think I did all the things above, RFAL! |
…canonicalization # Conflicts: # src/samudra/train.py # tests/conftest.py # tests/test_datasets.py
ba58035 to
1c26183
Compare
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 1c26183151
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
|
|
||
| n_levels = data_copy[name].sizes["lev"] | ||
| expected_levels = len(dataset_spec.depth_i_levels) | ||
| if n_levels != expected_levels: |
There was a problem hiding this comment.
Select requested LLC levels instead of rejecting full-depth stores
When a raw LLC store contains more k/lev levels than the model spec consumes (for example a full-depth root while single_1 only needs Theta_0), this equality check raises before any requested level can be selected. That makes otherwise usable LLC data/configs fail during canonicalization; flatten the configured level indices and only error when a needed level is missing.
Useful? React with 👍 / 👎.
| requested_data_vars.update( | ||
| [dataset_spec.mask_all_levels_var, "mask_c", *dataset_spec.mask_vars] | ||
| ) |
There was a problem hiding this comment.
Keep hFacC as a center wet-mask fallback
When an LLC store uses hFacC for tracer-cell wetness—the center-grid counterpart to the hFacW/hFacS fallbacks handled below—this whitelist drops it before the rename to wetmask, so flatten_masks() later cannot build wetmask_* and LLC loading fails. Include hFacC and rename it like mask_c for stores that do not already provide mask_c.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
@fomo-bot can you please verify if our LLC mock data includes hFacC? If it does, please fix this comment. Either way let's then get this merged.
There was a problem hiding this comment.
Verified: the LLC mock fixture includes mask_c, hFacW, and hFacS, but not hFacC, so I did not change the comment.
PR #670 was approved, checks passed, and I added it to the merge queue. It merged successfully at 2026-07-24T13:31:33Z: #670
Debug info
- Repository:
m2lines/Samudra - Trigger: Add LLC CPU data canonicalization #670 (comment)
- Request ID:
01fa0742-b13e-4d3f-98a4-4a2b2b3b058a - Accepted:
true
Add LLC data support (preprocessing, etc). Brings time configuration down into the data source since LLC data has different time formats than OM4, and we likely want to use different time ranges even for different resolutions of OM4 data.
It looks big but a lot of it is mechanical config changes and tests; happy to walk through live and/or break up further if desired!