PBC fix bundle

[evaleev]

• nuclear density function fix
  • Added rscale
  • Replaced the R parameter with the cell : more readable and removes the assumption that the cell is a centered cube
  • Removes the hardcoded assumption that we're in PBC.
• PBC handling in separated convolution and its applications cleaned up

[evaleev]

@robertjharrison while trying to deal with FunctionImpl::do_apply PBC issues I ended up tackling the mixed BC handling in SeparatedConvolution ... is there more to it than just toggling lattice sum flag for each setop? A pair of eyes on this commit would be good. @JonathonMisiewicz u2

[robertjharrison]

Huh. Prolly also how the operator displacements are generated in func defaults (?). Also if the aspect ratio is far from cubic (e.g., finite slab width is many multiples of the periodic width) then the sorting of displacements and the screening algorithm in do apply could be optimized (but I think this is just performance). I can read thru this later in the week.

…

On Tue, Dec 3, 2024, 20:10 Eduard Valeyev ***@***.***> wrote: ***@***.**** commented on this pull request. ------------------------------ In src/madness/mra/operator.h <#563 (comment)> : > @@ -1061,7 +1050,7 @@ namespace madness { ops[mu].setfac(coeff(mu)/c); for (std::size_t d=0; d<NDIM; ++d) { - ops[mu].setop(d,GaussianConvolution1DCache<Q>::get(k, expnt(mu)*width[d]*width[d], 0, isperiodicsum)); + ops[mu].setop(d,GaussianConvolution1DCache<Q>::get(k, expnt(mu)*width[d]*width[d], 0, lattice_sum[d])); @robertjharrison <https://github.com/robertjharrison> while trying to deal with FunctionImpl::do_apply PBC issues I ended up tackling the mixed BC handling in SeparatedConvolution ... is there more to it than just toggling lattice sum flag for each setop? A pair of eyes on this commit would be good. @JonathonMisiewicz <https://github.com/JonathonMisiewicz> u2 — Reply to this email directly, view it on GitHub <#563 (review)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABZSAPN7RWJ5AF2FQT2FDUL2DZI7ZAVCNFSM6AAAAABS67KN6WVHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMZDINZXGA2TKMBVG4> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[evaleev]

Prolly also how the operator displacements are generated in func defaults (?).

I went through that code, I think it's fine. I presume we only want to generate displacements for 2 cases only: all non-periodic and all-periodic, with mixed cases handled by the periodic displacements (optimizing for mixed case would just reduce the number of replacements). Or, do we want to generate the displacements for the specific boundary conditions FunctionDefaults was initialized for (i.e. assume the boundary conditions are immutable?).

I think the spherical shell-based screening logic should be OK in do_apply in either case. We won't be as efficient as could be but OK, let's chase correctness first.

Also if the aspect ratio is far from cubic (e.g., finite slab width is many multiples of the periodic width) then the sorting of displacements and the screening algorithm in do apply could be optimized (but I think this is just performance). I can read thru this later in the week.

I also touched that code, and should be OK.