Repository navigation
Conversation
Different dof orderings could share a hash, and custom elements were hashed on truncated coefficients but compared with a tolerance, so equal elements could hash differently. Hash every dof ordering entry, the discontinuous flag, and the exact data defining custom elements, and compare that data exactly. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01JudYk8UecTQyirGsLsHUN2
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
FFCx stores each element's
hash()in the generatedufcx_form, and DOLFINx compares it with the elements it is given at run time (form_factory.h,expression_evaluate.h). Two different elements with the same hash get past that check, and two equal elements with different hashes fail it.hash()had both problems.Different dof orderings could collide. Only positions where
dof_ordering[i] != iwere hashed, and only through the offsetdof_ordering[i] - i. So[1, 0, 2, 3]and[0, 1, 3, 2]on a quadrilateral both hashed the offsets +1, −1 and collided, although==tells them apart. The ordering is now hashed entry by entry. An identity ordering still hashes like no ordering, astest_hashexpects. The duplicatedcombine_hashes(h, dof_ordering_hash)is gone.Custom elements: hash and
==disagreed. The hash truncated the coefficient matrix to five decimals withint(c * 100000), which is undefined for |c| > ~21474, while==compared coefficients to within 1e-10. Coefficients 1e-11 apart that straddle a 1e-5 boundary were equal but hashed differently. No quantised hash can match a tolerance comparison, so both now use the data that defines a custom element,wcoeffs,xandM, exactly. This is a behaviour change: custom elements built from inputs that differ only by round-off are no longer equal.discontinuousis now hashed explicitly. It was only covered through the Sobolev space before.std::hashandcombine_hashesare unchanged, so hash values still differ between standard libraries, e.g. MSVC and libstdc++. That's fine, since the hashes that are compared always come from the same platform.All hash values change, so this belongs in a minor release. Kernels generated with older hashes fail DOLFINx's check with an error rather than giving wrong results, and FEniCS/ffcx#926 makes FFCx regenerate cached kernels when the Basix version changes.
The new tests
test_hash_dof_ordering,test_hash_discontinuousandtest_hash_custom_elementcover these cases. The first and last fail onmainand pass here. The full Python suite passes locally: 10056 passed, 338 skipped, 23 xfailed.🤖 Generated with Claude Code
https://claude.ai/code/session_01JudYk8UecTQyirGsLsHUN2