Woods-Saxon confinement

[vanderhe]

Implements the Woods-Saxon confinement potential.

• generalize sktools to WS confinement and hand over to slateratom
• switch to numeric confinement evaluation throughout and abstract out
• implement WS potential in slateratom
• switch to $W,a,r_0$ representation
• add example(s)
• add regression tests
• validate results

Closes #89.

[vanderhe]

@samtsevich I have generalized parts of the infrastructure. To be continued here:

https://github.com/vanderhe/skprogs/blob/d27e6b355a1f526cef853422f9e7a355998bd96c/slateratom/prog/main.f90#L94-L101

[vanderhe]

@samtsevich I have switched over to an all numeric integration of the confinement potential and abstracted out the potentials form. In the future we could now easily add 'arbitrary' potentials without involved modifications. Validation is still pending, but I'm mostly confident that it works as intended, as the results of the previous analytical power compression are reproduced, i.e. the regression tests pass.

[vanderhe]

C_veff.pdf

[vanderhe]

@samtsevich I think this is fully operational now. Any ideas on how to further validate the newly implemented WS compression?

[chiarapan]

Wow that was fast, thank you so much! Not sure if we can validate it e.g. against published parametrizations (Chou's paper, or my lithium-graphite) because the atomic solvers and probably other finer details are all different and/or not available. Did you already give it a test run with some actual SK table generation?

[vanderhe]

Did you already give it a test run with some actual SK table generation?

I have generated some SK-files but did not perform the actual DFTB calculation. The two-center integration does not explicitly depend on the confinement potential, so I guess it is fine. The new numeric approach to the confinement in the one-center part seems to perfectly reproduce the analytical power compression and the WS implementation follows the same code path (but of course with a different functional form). You have way more experience with the WS compression than I have, would it be possible that you briefly check for a 'qualitatively correct/expected behavior'? But it is not urgent (at least not from my side).

[chiarapan]

I'll check soon with lithium (for which I haven't yet managed to get a great parametrization with the power compression). I'll update as soon as I test it!

[vanderhe]

I'll check soon with lithium (for which I haven't yet managed to get a great parametrization with the power compression). I'll update as soon as I test it!

Thanks a lot 👍.

[aradi]

Amazing, thanks Tammo! I've made a few comments on the code design.

[aradi]

Can you make the components allocatable and allocate on demand? There is less chance, that they are used uninitialized.

[vanderhe]

Sure, I was already thinking about this, don't know why I ultimately decided to not make use of it.

[vanderhe]

Should be addressed by the latest commit.

[aradi]

Do we really need getSupervec()? Both implementations are exact identical, if I have seen correctly. Let's introduce it only, if we really need it. Or, alternatively, create a concrete implementation in this base class, so that derived classes have only to define getPotOnGrid()

[vanderhe]

Exactly, I was trying to sharpen my Fortran OOP skills with this PR and would be very interested in your opinion/feedback. The getSupervec() routine is a 1:1 duplicate and does not depend on this. I wasn't quite sure how to handle this case in the most elegant way. Since it does not depend on the compression type, can it be associated with the overarching abstract type (is this what you meant by 'create a concrete implementation in this base class'?) or should it just live on its own in the confinement module?

[aradi]

• An abstract type can have non-deferred (normal) type bound procedures with actual implementation.
• You could either specify the routine there. You might then use the nopass option, so that this is not even passed to the routine.
• Alternatively, you just use it as a simple function outside. I don't have any strong opinions on this, but probably the way, how the integrals are calculated is independent from the actual potential form, so probably having it outside as a standalone function is more logical...

[vanderhe]

I see 👍. I have seen nopass in other projects before and always wanted to use it, seems like a reasonable opportunity for that. See the latest commit.

[samtsevich]

@vanderhe
Hey Tammo,
Should we first test this implementation before it is merged into the main repo or is that on your side?
[Nevertheless, we can start playing even with this version, and lets see how that works for our optimization procedure]

[chiarapan]

I'll check soon with lithium (for which I haven't yet managed to get a great parametrization with the power compression). I'll update as soon as I test it!

Thanks a lot 👍.

Tested, it seems to work fine!

[samtsevich]

@aradi
Can you please review these changes?
On our side, we are ready to start playing with the optimization run

[vanderhe]

@aradi Can you please review these changes? On our side, we are ready to start playing with the optimization run

Bálint currently is still on vacation and will pick up work next week. I would estimate that a realistic time frame for this PR getting reviewed/merged is 1-2 weeks from now. From my side this is the final version, so I would suggest that you resort to this branch until it gets merged into main.

[vanderhe]

@aradi Just a request: please do not squash f10a9b4 into any of the other commits when merging, I would like to keep the (fully working) $R_\mathrm{onset}, R_\mathrm{cut}$-representation in the history, if possible.

[vanderhe]

@aradi I had to push an additional commit to this branch that fixes a bug in the shelf search. Nothing dramatic, but the previous version was not recognizing matching calculations in the shelf anymore.