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

Examining S<:AbstractStructure and our approach to basis manipulation #19

Open
jrevels opened this issue Mar 24, 2015 · 1 comment
Open

Comments

@jrevels
Copy link
Contributor

jrevels commented Mar 24, 2015

Currently, S<:AbstractStructure is pretty vaguely defined (my own fault), and I think in light of upcoming development goals (e.g. GSoC proposal) we should give it a review. To close this issue, I would like to either:

  • clearly define its purpose, and give it a better name if we can think of one, or
  • get rid of it, and use a type hierarchal structure for bases instead of parameterization to define the properties we want.

To begin, I'll describe what I was initially thinking when I proposed the S<:AbstractStructure type family.

My idea was that we could use type parameterization + dispatch to "easily" define the behavior of the wave functions that form the basis for a given QuArray, without having to implement new concrete subtypes of AbstractBasis/QuArray. What do I mean by this? I think an example might work best. Using the hydrogen atom, a potential use case would be defining types like this:

abstract Orthonormal <: AbstractStructure
abstract HydrogenSphPos <: Orthonormal

wavefunc(::Type{HydrogenSphPos}, i) = # ψ_nlm(r, θ, ϕ) 

Here, wavefunc is overloaded to return the basis wave function for hydrogen atom in spherical coordinates corresponding to the ith position in a QuVector. In other words, each index i maps to a unique quantum number tuple (n,l,m) which specifies the basis wave function for the ith coefficient in the QuVector.

What does this buy us?

First, since HydrogenSphPos <: Orthonormal, we know we can skip actually processing the basis wave functions when evaluating products of objects like QuArray{FiniteBasis{HydrogenSphPos}}.

Second, we could provide a method like the below, which would allow evaluation of the superposed state given by the QuArray at the given args:

waveeval{S}(qv::QuVector{FiniteBasis{S}}, args...) = sum([qv[i] * wavefunc(S, i)(args...) for i=1:length(qv)]  

Obviously, more optimization could be done so as to not use a temporary array, but you get my drift. When we move forward to v.04, we could overload call and have beautiful syntax for evaluating states:

Base.call(qv::QuVector, args...) = waveeval(qv, args...)

#now, we can say the following:

Ψ = # some QuVector{FiniteBasis{HydrogenSphPos}}
r, θ, ϕ = # positional parameters
Ψ(r, θ, ϕ) # evaluate entire state at positional parameters

Since the above example doesn't cover it, let's say a user defines a structural type that is not S<:Orthonormal. Then, we could a provide a function like the following that could be overloaded for arbitrary type S<:AbstractStructure:

inner_rule{S}(::Type{S}, i, j) = # provides an evaluation of the inner product of wavefunc(::Type{S}, i) and wavefunc(::Type{S}, j)

...which could then be used in the evaluation of products of non-orthonormal objects.

In conclusion, the above proposal exposes a couple of functions to the user (wavefunc and inner_rule) that allows them to define/extend the behavior of QuArrays without having to dig into the internals.

Key points for this issue:

  1. The main problem I see with the above approach is that the amount of closures/functionals involved would probably result in poor performance for certain operations, specifically what I called waveeval above.
  2. Does anybody here know how other libraries handle this kind of functionality? I'm not familiar with the methods used for simulation of this sort, and always kind of assumed that the basis functions were either hard-coded or were able to be abstracted away for the systems people are interested in simulating. If anybody can point me to documentation I could learn from, I'd be grateful.
  3. If we do continue to use S<:AbstractStructure, what would be a better name for it? "AbstractStructure" is terribly vague, but I haven't been able to think of any better. "BasisFunction", maybe? I'd be worried it might get confused for a subtype of Function, then...
@jrevels
Copy link
Contributor Author

jrevels commented Apr 30, 2015

@JuliaQuantum/owners

Any thoughts with regard to this? I'd like to settle this issue (either by addressing the key points, or figuring out an alternative) before we go too far down the road.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant