Skip to content
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

Unify normalization conventions of dynamical correlation #235

Closed
kbarros opened this issue Feb 7, 2024 · 2 comments
Closed

Unify normalization conventions of dynamical correlation #235

kbarros opened this issue Feb 7, 2024 · 2 comments

Comments

@kbarros
Copy link
Member

kbarros commented Feb 7, 2024

Dynamical correlations calculated with spin wave theory and with classical dynamics currently follow different normalization conventions with respect to natoms (the number of atoms in the magnetic cell). The current state is:

  1. SpinW does not normalize by natoms
  2. Our current LSWT code does normalize by natoms
  3. Our current classical dynamics intensity code does not normalize by natoms.

@Lazersmoke argued on Slack that (2) is correct (even though it differs from the SpinW convention), and that (3) should be changed to match (2).

Here is my lightly edited summary of @Lazersmoke's argument:

Ok, so that everyone is on the same page, if I have a quantity S(x,t) with "units" S^2 and I Fourier transform it, then the result will have units S^2/BZ/fs where "per BZ" is [Length]^3 and "per fs" is [Time], and they indicate that the S(q,w) is a density in reciprocal space. In order for the typical density S(q,w) to be on the same order of magnitude as S(x,t), you need to do a fast Fourier transform (which is a sum of N terms with no normalization factor) and then divide by N.

For exactly the same reason, when you add Nm terms together in a spin wave code, you have to divide by Nm to get your intensity to be in the standard S^2/BZ/fs units; you're averaging Nm estimates of the correlation together.

For (once again) the same reason, you need to divide by prod(sys.latsize) when computing spatial correlations.

SpinW is adding together Nm terms and not dividing by Nm [bad]

LSWT is adding together Nm terms and using sqrt_Nm_inv to divide by Nm [good]

LL on main is correctly dividing by prod(sys.latsize) [good], but not by Nm [bad], and for energy axis it's dividing by nomega too many times

@Lazersmoke
Copy link
Contributor

This all looks good 👍 and the classical dynamics as implemented in #217 fixes the Nm and n_omega factors.

One caveat: everything mentioned above includes only up to the output of calc_intensity. There are additional normalization considerations that need to be made on case-by-case basis for each of the following functions, which consume the output of calc_intensity:

  • intensities_interpolated (no change)
  • intensities_binned (normalization having to do with bin width; implemented on 217 )
  • intensities_bands (normalization of delta functions needs to be documented)
  • intensities_band_structure (new in 217 ; normalization of delta functions within the BandStructure struct needs to be documented)
  • intensities_broadened (normalization of the broadening kernel needs to be documented)
  • Powder variants of all of the above (has a bin measure ~2|q|)

@kbarros
Copy link
Member Author

kbarros commented Mar 5, 2024

Work in progress at #240 is going to use the convention that the extensive intensity will be normalized by the number of chemical unit cells, i.e., in terms of the lattice vectors that define the RLU system. This has the advantages: (1) consistency with SpinW, (2) adding more magnetic ions adds more intensity (3) avoid ambiguity, e.g., when working with entangled units, where the number of "sites" is not well defined.

Note that the shape of the chemical cell is an invariant in Sunny. Reshaping the System will not change the reference ("original") chemical cell.

@kbarros kbarros closed this as completed Mar 5, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants