Unable to construct CSFs with non-seniority disambiguating quantum numbers

[mortenpi]

An MWE is

julia> using AtomicLevels
CSF(rc"1s", [IntermediateTerm(0,0)], [0])
[ Info: Precompiling AtomicLevels [10933b4c-d60f-11e8-1fc6-bd9035a249a1]

julia> CSF(rc"1s", [IntermediateTerm(0,0)], [0])
ERROR: MethodError: no method matching assert_unique_classification(::RelativisticOrbital{Int64}, ::Int64, ::HalfIntegers.Half{Int64}, ::Int64)
Closest candidates are:
  assert_unique_classification(::RelativisticOrbital, ::Any, ::HalfIntegers.HalfInteger, ::Seniority) at /home/mortenpi/Projects/atomicjulia/dev/AtomicLevels/src/intermediate_terms.jl:49
  assert_unique_classification(::Any, ::Any, ::IntermediateTerm) at /home/mortenpi/Projects/atomicjulia/dev/AtomicLevels/src/intermediate_terms.jl:216
  assert_unique_classification(::Orbital, ::Any, ::Term, ::Seniority) at /home/mortenpi/Projects/atomicjulia/dev/AtomicLevels/src/intermediate_terms.jl:45
Stacktrace:
 [1] assert_unique_classification(orb::RelativisticOrbital{Int64}, occupation::Int64, it::IntermediateTerm{HalfIntegers.Half{Int64}, Int64})
   @ AtomicLevels ~/Projects/atomicjulia/dev/AtomicLevels/src/intermediate_terms.jl:216
 [2] CSF(config::Configuration{RelativisticOrbital{Int64}}, subshell_terms::Vector{IntermediateTerm{HalfIntegers.Half{Int64}, Int64}}, terms::Vector{HalfIntegers.Half{Int64}})
   @ AtomicLevels ~/Projects/atomicjulia/dev/AtomicLevels/src/csfs.jl:48
 [3] CSF(config::Configuration{RelativisticOrbital{Int64}}, subshell_terms::Vector{IntermediateTerm{HalfIntegers.Half{Int64}, Int64}}, terms::Vector{Int64})
   @ AtomicLevels ~/Projects/atomicjulia/dev/AtomicLevels/src/csfs.jl:55
 [4] top-level scope
   @ REPL[2]:1

If I understand correctly, assert_unique_classification makes sure that the disambiguating quantum number makes sense for a given orbital, occupation and subshell term. We don't handle it when it's an integer.

Of course, if we do not specify the meaning of the quantum number, we can't determine if the value makes sense. I feel that we have the following options for the generic integer case:

1. Require it to be in 1:N, where N is the number of unique values it can have.
2. Allow any N and just hope that the users check for that themselves.
3. Keep that status quo and require the user to implement their own types. In this case we should probably remove the possibility for a generic case altogether.

I would like 1, but I don't remember if we had a way to determine N fast. So 2 could be the next best thing. Not a big fan of 3.

I might also be missing something -- I haven't used the CSF functionality here in a long while. But I ran into this as I was updating GRASP.jl to the new AtomicLevels version.