You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hi I'm walking through the primer and found something worth mentioning.
Everytime makeLevels function is called, it appends the lists of labels. If one calls the function again, it will append another entries, possibly allowing duplicated ones. I found this feature to be useful yet requires some caution.
If it goes through another run, levelLabel will have [[5, 0, 0.5], [5, 1, 0.5], [5, 1, 1.5], [5, 0, 0.5], [5, 1, 0.5], [5, 1, 1.5]]
I believe this behavior is intended and nothing wrong. Actually it can be utilized to include multiple levels which cannot be handled my a single execution of makeLevels. Say one wants to see energy levels above the ground state Rb 5s_{1/2}, including 4d. Although 4d is more energetic, it will be not covered by makeLevels if one specifies nmin=5. Putting nmin=4 will force the code to draw 4s_{1/2}, leading to non-physical result. Therefore workaround I use is
This will give levels [[4, 2, 1.5], [4, 2, 2.5], [5, 0, 0.5], [5, 1, 0.5], [5, 1, 1.5], [5, 2, 1.5], [5, 2, 2.5]] and it is what I intended to get.
In the future it might be more failsafe to add an initializing function, which empties existing labels. I had to restart kernel in order to draw new level plots.
The text was updated successfully, but these errors were encountered:
There were several bugs in implementation. I will add an update that should resolve this. The behaviour after the update should be the following:
When you call a new LevelPlot(), initialization functions returns a new, clear level plot.
In your example putting nmin=4 for Rubidium should not force the printing of unphysical levels, but only levels like n=4 l=2, that have higher energies.
With this updates, you can obtain the indented level plot with:
Hi I'm walking through the primer and found something worth mentioning.
Everytime makeLevels function is called, it appends the lists of labels. If one calls the function again, it will append another entries, possibly allowing duplicated ones. I found this feature to be useful yet requires some caution.
Say we have a code
This yields
[[5, 0, 0.5], [5, 1, 0.5], [5, 1, 1.5]].
If it goes through another run, levelLabel will have
[[5, 0, 0.5], [5, 1, 0.5], [5, 1, 1.5], [5, 0, 0.5], [5, 1, 0.5], [5, 1, 1.5]]
I believe this behavior is intended and nothing wrong. Actually it can be utilized to include multiple levels which cannot be handled my a single execution of makeLevels. Say one wants to see energy levels above the ground state Rb 5s_{1/2}, including 4d. Although 4d is more energetic, it will be not covered by makeLevels if one specifies nmin=5. Putting nmin=4 will force the code to draw 4s_{1/2}, leading to non-physical result. Therefore workaround I use is
This will give levels
[[4, 2, 1.5], [4, 2, 2.5], [5, 0, 0.5], [5, 1, 0.5], [5, 1, 1.5], [5, 2, 1.5], [5, 2, 2.5]]
and it is what I intended to get.In the future it might be more failsafe to add an initializing function, which empties existing labels. I had to restart kernel in order to draw new level plots.
The text was updated successfully, but these errors were encountered: