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

Refactor single ion anisotropies #93

Merged
merged 3 commits into from
Jul 14, 2023
Merged

Refactor single ion anisotropies #93

merged 3 commits into from
Jul 14, 2023

Conversation

kbarros
Copy link
Member

@kbarros kbarros commented Jul 13, 2023

  • Replace set_anisotropy! with set_onsite_coupling!. The new function expects a matrix built from stevens_operators or spin_operators. Provide print_stevens_expansion to decompose polynomials of spin operators into a linear combination of Stevens operators.

  • Make DynamicPolynomials an optional dependency. This provides symbolic functions print_classical_stevens_expansion and print_classical_spin_polynomial.

  • Functions to create tensor products of operators.

- Replace `set_anisotropy!` with `set_onsite!`. The new function expects
  a matrix built from `stevens_operators` or  `spin_operators`. Provide
  `print_stevens_expansion` to decompose polynomials of spin operators
  into a linear combination of Stevens operators.

- Make DynamicPolynomials an optional dependency. This provides symbolic
  functions `print_classical_stevens_expansion` and
  `print_classical_spin_polynomial`.

- Functions to create tensor products of operators.
@kbarros
Copy link
Member Author

kbarros commented Jul 13, 2023

There are various breaking changes in this commit, but the main one is the replacement set_anisotropy! with set_onsite! (name TBD). The new function takes an explicit $N \times N$ matrix which can be built using, e.g. spin_operators or stevens_operators. DynamicPolynomials.jl becomes an optional dependency, and can provide certain symbolic analysis relevant to the large $S$ classical limit.

Λ′ = rotate_operator(Λ, R)
@test Sunny.is_anisotropy_valid(cryst, i, Λ′)

latvecs = lattice_vectors(1.0, 1.1, 1.0, 90, 90, 90)
cryst = Crystal(latvecs, [[0., 0., 0.]])
# print_site(cryst, i)
Λ = randn()*(𝒪[6,0]-21𝒪[6,4]) + randn()*(𝒪[6,2]+(16/5)*𝒪[6,4]+(11/5)*𝒪[6,6])
Λ = randn()*(O[6,0]-21O[6,4]) + randn()*(O[6,2]+(16/5)*O[6,4]+(11/5)*O[6,6])
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Using O here (instead of 𝒪) doesn't look great when juxtaposed with coefficients. The tradeoff is that some people's terminals won't render 𝒪 properly, so I was thinking it might be better to use plain ASCII in the main examples.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Probably, users will make themselves clear by inserting * for clarity. Also consider that this form of juxtaposed coefficients is a special feature of julia, so people are already wary. This term: (O[6,2]+(16/5)*O[6,4]+(11/5)*O[6,6]) looks fine to me, and even more fine with spaces (O[6,2] + (16/5)*O[6,4] + (11/5)*O[6,6]).

Definitely Unicode-optional is the way to go.

@@ -7,7 +7,6 @@

using Sunny, GLMakie
using Statistics: mean
#md Makie.inline!(true); #hide
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Was this a no-op?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It was previously needed as a workaround for this bug MakieOrg/Makie.jl#2805.

@@ -0,0 +1,126 @@
# Produces a matrix representation of a tensor product of operators, C = A⊗B.
# Like built-in `kron` but with permutation. Returns C_{acbd} = A_{ab} B_{cd}.
function kron_operator(A::AbstractMatrix, B::AbstractMatrix)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this one of the kron-like matrix products defined by LinearMaps.jl? link. It may be worth investigating whether LinearMaps helps in anyway with these onsite operators, c.f.. Seems unlikely because they are always dense matrices.

Also, is it faster than Base.permutedims + Base.kron?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good catch. The kron from LinearMaps is semantically the same. It might be lazy, which would save work at construction time, but I suspect it wouldn't significantly reduce the total amount of work required (e.g. there will eventually be an SVD operation).

Eventually we should have a chat about the cost of constructing Hamiltonians in the context of inverse modeling. If optimization and LSWT becomes really fast, it could be that building the Hamiltonian is the dominant cost (e.g. symmetry analysis can sometimes be really slow). I have some thoughts to run by you.

@Lazersmoke
Copy link
Contributor

Looks great! Good to merge as-is

Copy link
Member

@ddahlbom ddahlbom left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This all looks great to me too.

@kbarros kbarros merged commit 94f8903 into main Jul 14, 2023
3 checks passed
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

Successfully merging this pull request may close these issues.

3 participants