-
Notifications
You must be signed in to change notification settings - Fork 145
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix mixed precision kpoint sorting #5327
base: develop
Are you sure you want to change the base?
fix mixed precision kpoint sorting #5327
Conversation
I guess all the changes under |
I took a quick look at the failures. Offload compilations obviously need fixing. The remaining ionion test failures look very reasonable and come from only a couple of systems. Importantly these are truly deterministic "simple" function evaluations of the fixed input atomic positions => if you wished you could set the mixed and full precision values identical in these cases (if they are not already) and bump the tolerances to suit. |
Test this please |
but how to update this with a sane amount of work is an issue
c4e1b82
to
399e4fb
Compare
Made #5341 after that this PR will be down to just 107 files 😭 |
I noticed that I agree with @PDoakORNL mentioned "CrystalLattice and KContainer should do the kpoint sorting in full precision." So I tried making all the use of "CrystalLattice" in full precision #5350 |
Proposed changes
To get consistent kpoint sorting across compilers and mixed and full precision simulations should rely on full precision for the CrystalLattice and KContainer should do the kpoint sorting in full precision. Then to preserve mixing precision performance where applicable reduced precision ksq and kpts_cart access via the get*Working calls added to KContainer are available.
This unfortunately touches a huge number of files since There are many tests that directly define CrystalLattice's and they do this either explicitly in mixed precision or by using the
PtclOnLatticeTraits::ParticleLayout
type alias.Some deterministic test values for mixed precision are now enough closer to full precision that they fall outside of the tolerance of the tests. Rather than drop the tolerance I have updated the values when they are closer to full precision that the previous test targets. This requires many one line updates through CMakeLists.txt in the deterministics tests and it will take some time to complete.
What type(s) of changes does this code introduce?
Delete the items that do not apply
Does this introduce a breaking change?
What systems has this change been tested on?
Checklist
Update the following with a yes where the items apply. If you're unsure about any of them, don't hesitate to ask. This is
simply a reminder of what we are going to look for before merging your code.