fix: ELEMENTAL_TE_SOURCE was never applied to the submitted job - #353
fix: ELEMENTAL_TE_SOURCE was never applied to the submitted job#353VsevolodX wants to merge 1 commit into
Conversation
… job The notebook's cell 4.2 uses ELEMENTAL_TE_SOURCE to preview which total_energy properties would be resolved, but formation_workflow (the object actually passed to create_job) was never patched with it -- the Resolve Total Energies for Elemental Materials subworkflow always ran with its standata-hardcoded 'public' value regardless of the parameter, so the preview and the real computation could silently disagree. Patch the workflow's assign-source-of-te-for-an-element unit the same way SCF_KGRID already patches pw_scf, right after the workflow object is created and before it's saved/submitted.
|
Check out this pull request on See visual diffs & provide feedback on Jupyter Notebooks. Powered by ReviewNB |
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
📝 WalkthroughWalkthroughThe Formation Energy notebook now applies ChangesFormation Energy workflow
Estimated code review effort: 2 (Simple) | ~10 minutes Possibly related PRs
Suggested reviewers: 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Problem
formation_energy.ipynb'sELEMENTAL_TE_SOURCEparameter (cell 1.3) was only ever used in cell 4.2's client-side preview print.formation_workflow-- the object actually passed tocreate_job-- was never patched with it, so theResolve Total Energies for Elemental Materialssubworkflow always ran with its standata-hardcoded'public'value on the cluster, regardless of what the notebook parameter said. Preview and reality could silently disagree.This was the source of intermittent formation_energy Cypress failures:
publicscope picks whichever account's total_energy for the same elemental structure currently has the highest recorded precision. Different accounts' default (unpinned) Total Energy jobs land on different auto-selected precision for the identical structure, so which one "wins" can permanently shift as new candidates enter the shared properties pool over time.Fix
Patch the workflow's own
assign-source-of-te-for-an-elementunit right after the workflow object is created, mirroring howSCF_KGRIDalready patchespw_scf.Verification
Confirmed locally end-to-end (local backend + a temporary Netlify preview of this branch): with this fix, plus pinning the elemental Si/Ge Total Energy jobs to an explicit k-grid in the Cypress test (a separate, already-existing gap in the test's Background),
formation_energyfor SiGe now resolves deterministically to1.3642469947276368 eV/atom-- matching the original calibration -- across repeated runs.Summary by CodeRabbit