[WIP] Get DFTK fully generic in the floating point type #59

mfherbst · 2019-11-14T17:40:37Z

This PR will get DFTK agnostic to the floating point type used.

Get DoubleFloats to work
Tests
Merge magnesium examples

antoine-levitt

Looks great, victory is near! Left a few comments.

examples/magnesium_supercell.jl

src/core/PlaneWaveBasis.jl

src/core/energy_ewald.jl

antoine-levitt · 2019-11-14T18:01:03Z

src/core/energy_ewald.jl

@@ -22,7 +23,7 @@ function energy_ewald(lattice, recip_lattice, charges, positions; η=nothing)
    if η === nothing
        # Balance between reciprocal summation and real-space summation
        # with a slight bias towards reciprocal summation
-        η = sqrt(sqrt(1.69 * norm(recip_lattice ./ 2π) / norm(lattice))) / 2
+        η = T(sqrt(sqrt(1.69 * norm(recip_lattice ./ 2π) / norm(lattice))) / 2)


How do you more generally make sure that there are no implicit conversions to float64? Should it be T(1.69) and T(2pi) everywhere there are constant literals?

I do still not have a better solution here ... if you find one let me know.

src/core/generic_fftn.jl

src/core/lobpcg_hyper_impl.jl

src/core/self_consistent_field.jl

mfherbst · 2019-11-16T16:00:38Z

@antoine-levitt I'm waiting for your final verdict and then this goes in 😄.

src/core/PlaneWaveBasis.jl

src/core/fft.jl

antoine-levitt · 2019-11-16T16:07:45Z

src/core/occupation.jl

+
+    n_electrons_integration = compute_n_elec(εF)
+    if abs(n_electrons_integration - n_electrons) > sqrt(eps(real(T)))
+        @warn("`find_occupation_gap_zero_temperature` has a mismatch in number " *


wrong copy-paste here in the error message. Shouldn't these be asserts? It really shouldn't happen...

Well but it does for some floating point types ... albeit the error is really neglible.

Ah no, scratch that ... that's at the other instance, here it can be a proper assert.

really ? The other one should really be fine also... that's in float16 I guess?

No, it's for more accurate types like Double32 or Double64. I think the reason is because their density of representable floats is plainly different than for IEEE floats, such that eps(T) might not always be the best metric, or put another way: The prefactor for an eps(T) error bound might just be different, not sure.

Yeah that's what I meant by "diagnostic tool". So I did a quick grep for backslash, things that might get us into trouble is pretty much all of PspHgh, SphericalHarmonics, bzmesh, A_coeff(n) = (-1)^n / (factorial(n) * 4^n * sqrt(π))

Ah I see ... puh ... I can't be bothered to fix that all here. I made a separate issue for that, see #60.

Hmm ... but some of that might not actually matter that much, because it's later assigned to arrays of the appropriate type.

yeah but you lose precision, which matters if we want to push below Float64. Let's do that later, but keep the assert (which is pretty useful precisely because of this kind of things; in fact a better check would be to check against eps^2/3 or something)

Ok, I dropped the relevant commit.

antoine-levitt · 2019-11-16T16:08:12Z

test/silicon_runners.jl

@@ -7,7 +7,7 @@ include("testcases.jl")
 # TODO There is a lot of code duplication in this file ... once we have the ABINIT reference
 #      stuff in place, this should be refactored.

-function run_silicon_redHF(;Ecut=5, test_tol=1e-6, n_ignored=0, grid_size=15, scf_tol=1e-6)
+function run_silicon_redHF(T; Ecut=5, test_tol=1e-6, n_ignored=0, grid_size=15, scf_tol=1e-6)


T=Float64?

But then also at other places like in run_silicon_lda and so on ...
so far we explicitly specify the type everywhere, which I think is actually what you want.

antoine-levitt · 2019-11-16T16:08:57Z

Left of couple of nitpicking comments, but otherwise good to go!

antoine-levitt · 2019-11-17T10:24:45Z

As usual I'm thoroughly confused by the package system. I get

(v1.3) pkg> resolve
 Resolving package versions...
ERROR: Unsatisfiable requirements detected for package FourierTransforms [65ccaadd]:
 FourierTransforms [65ccaadd] log:
 ├─FourierTransforms [65ccaadd] has no known versions!
 └─restricted to versions * by DFTK [acf6eb54] — no versions left
   └─DFTK [acf6eb54] log:
     ├─possible versions are: 0.0.1 or uninstalled
     └─DFTK [acf6eb54] is fixed to version 0.0.1

on this branch

mfherbst · 2019-11-17T13:31:49Z

Ok ... I did some digging. Essentially all these problems boil down to the fact that FourierTransforms is unregistered and there seems to be no clean way to depend on unregistered packages from registered packages (as ours is now).

I propose the following: I'll open an issue asking about registration of the package (see 11 in FourierTransforms.jl). I would understand if that's not done to General, because it really is a little immature. In that case we have four options:

Do not allow for the generic stuff at all
Copy the files to DFTK
Register a fork in MolSim under a temporary name such that it is clear its a workaround
Register the package in MolSim as is. Requires some coordination with the authors to avoid registering different states under the same version or different versions for the same package state.

I personally prefer to the third option. It surely puts some maintenance burden on us, however.

What are your thoughts?

antoine-levitt · 2019-11-17T15:49:45Z

As usual I'm for the simplest and dirtiest solution :-p copy the files. It's fine under MIT (with proper attribution of course), it's just a temporary workaround to try stuff and it's the most flexible solution (eg if we want to change things in the FFT code)

mfherbst · 2019-11-18T10:13:34Z

Hmm ... ok ... after some thoughts I agree with you. I closed the issue at FourierTransforms and added the files as a copy.

mfherbst added the feature New feature or request label Nov 14, 2019

antoine-levitt reviewed Nov 14, 2019

View reviewed changes

mfherbst added 3 commits November 16, 2019 15:57

Allow a way to specify tolerance in compute_bands

fff308d

Adapt Jupyter notebook example for reduced precision

ea5c435

Small pymatgen cleanups

b4d77f8

mfherbst force-pushed the fully-generic branch from fedfef6 to eef5cb7 Compare November 16, 2019 15:44

antoine-levitt reviewed Nov 16, 2019

View reviewed changes

src/core/PlaneWaveBasis.jl Show resolved Hide resolved

antoine-levitt reviewed Nov 16, 2019

View reviewed changes

src/core/fft.jl Show resolved Hide resolved

antoine-levitt reviewed Nov 16, 2019

View reviewed changes

mfherbst added 8 commits November 16, 2019 17:26

Magnesium supercell example

8f44519

Correct typo

f1e4412

Generic FFTs and LOBPCG

eb807b5

Bugfix HamiltonianBlock

2fde102

Change way of determining assume_band_gap

d6244d1

Bugfix in Psi truncation

f9f5315

Silicon arbitrary floating point type example

e1f7222

Amend README

3182f7b

mfherbst force-pushed the fully-generic branch from eef5cb7 to 1e94e8a Compare November 16, 2019 16:37

mfherbst mentioned this pull request Nov 16, 2019

Proper type stability #60

Closed

mfherbst force-pushed the fully-generic branch from 1e94e8a to 15ff911 Compare November 16, 2019 16:56

mfherbst added 4 commits November 16, 2019 17:57

Small fixes Ewald

2ffd68c

Test for generic reduced HF

574fe90

Move determine_grid_size to fft.jl

934acf6

Ensure kweight computation in target type

e6b1bd4

mfherbst force-pushed the fully-generic branch from 15ff911 to e6b1bd4 Compare November 16, 2019 16:57

antoine-levitt mentioned this pull request Nov 16, 2019

Type instabilities #61

Merged

mfherbst force-pushed the fully-generic branch from 1906544 to 11dc169 Compare November 16, 2019 19:01

mfherbst force-pushed the fully-generic branch from 11dc169 to 3d899a7 Compare November 18, 2019 10:11

Add relevant files from FourierTransforms.jl as a copy

d13cc8e

mfherbst force-pushed the fully-generic branch from 3d899a7 to d13cc8e Compare November 18, 2019 10:32

mfherbst merged commit 8dab726 into master Nov 18, 2019

mfherbst deleted the fully-generic branch November 18, 2019 11:49

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[WIP] Get DFTK fully generic in the floating point type #59

[WIP] Get DFTK fully generic in the floating point type #59

mfherbst commented Nov 14, 2019 •

edited

Loading

antoine-levitt left a comment

antoine-levitt Nov 14, 2019

mfherbst Nov 16, 2019

mfherbst commented Nov 16, 2019

antoine-levitt Nov 16, 2019

mfherbst Nov 16, 2019

mfherbst Nov 16, 2019

antoine-levitt Nov 16, 2019

mfherbst Nov 16, 2019

antoine-levitt Nov 16, 2019 •

edited

Loading

mfherbst Nov 16, 2019

mfherbst Nov 16, 2019

antoine-levitt Nov 16, 2019

mfherbst Nov 16, 2019

antoine-levitt Nov 16, 2019

mfherbst Nov 16, 2019

antoine-levitt commented Nov 16, 2019

antoine-levitt commented Nov 17, 2019

mfherbst commented Nov 17, 2019 •

edited

Loading

antoine-levitt commented Nov 17, 2019

mfherbst commented Nov 18, 2019

[WIP] Get DFTK fully generic in the floating point type #59

[WIP] Get DFTK fully generic in the floating point type #59

Conversation

mfherbst commented Nov 14, 2019 • edited Loading

antoine-levitt left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mfherbst commented Nov 16, 2019

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

antoine-levitt Nov 16, 2019 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

antoine-levitt commented Nov 16, 2019

antoine-levitt commented Nov 17, 2019

mfherbst commented Nov 17, 2019 • edited Loading

antoine-levitt commented Nov 17, 2019

mfherbst commented Nov 18, 2019

mfherbst commented Nov 14, 2019 •

edited

Loading

antoine-levitt Nov 16, 2019 •

edited

Loading

mfherbst commented Nov 17, 2019 •

edited

Loading