-
Notifications
You must be signed in to change notification settings - Fork 0
/
TODO
193 lines (119 loc) · 10.1 KB
/
TODO
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
1. Split things up according to functionality and build separate libraries:
- nucleus
- pairs
- ...
2. Clean up
- Nucleus::makepairs() (nucleus.cpp)
- Nucleus::get_shell_max(...) (nucleus.cpp)
3. Make use of general 1d interpolator instead of
repeating heaps of code in speedy.cpp...
4. Reproduce the table with "norms" on page 97 of Maartens thesis.
Make this into a exec file.
5. Clean up
operator_virtual_ob::get_tensor_me(...)
do something more elegant and clearer than all those if/else if/else statements
6. Check if the signs in the threejs in density_ob3.cpp really don't matter
That is the ones that can be matched to corresponding threej of the form
(*,*,*,0,0,0)
7. Do checks for nucleus with Z>A, now code runs happily without complaining
===========================================================
Wim
===========================================================
+++MODIFICATIONS ALGORITHMS+++
18. can the links be stored somehow for any nucleus? Is it worth the effort/reusability?
->think too difficult...
+++MODIFICATIONS PROGRAMMING STYLE
5. replace pointer arguments by reference where applicable... -> done for a whole lot, Pair map in nucleus is
still problematic with the way recmosh is dealt with. Got strange things with constructors (copy) and destructors.
7. storage of moshinskys: make binary, one file
-the map for each nlnl, then the nlnl values + position in the file where map begins & length, total number of nlnl values
-care will have to be taken if an nlnl map has been updated -> file will need te be rewritten. Total size so far is ~100kb so should be ok.
20. create pointer to mosh object in pair and newcoef in the constructor itself instead of passing as a parameter...
21. streamline moshinsky inputdir/outputdir (the same), differentiate output mosh and other things
22. add copy and copy assignment constructors?
28. obmd in double loops move lookups of the first one after first forloop
29. make namespace for the correlation functions file
33. void params in the operators -> can this be replaced by template class?
43. Wavefunctionp grid sizes should be max+1!!
45. MapWavefunctionP checks for A and pstepset, if changed everything should be cleared etc.
++++CHECKS++++
44. check Eq C.6 PhD Vanhalst by comparing to explicit calculation, -> I get k+1 arguments instead of k+3/2 plus an overall factor of 2/sqrt(\pi).
Also make the computation of these integrals more dimensionless
++++COMMENTING+++++
+++DONE+++
10. Nucleus::makepaircoeffs
Check how links are dealt with in the operators, now link is stored bidirectionally, but matrix elements aren't necessarily?
-> This is ok, see for instance operator_virtual_ob::sum_me_corr (l75)
26. figure out factor /A-1 at the end in operator_virtual_ob::sum_me_pairs and operator_virtual_ob::sum_me_coefs, why not 2/A-1?? [because O(1)+O(2) is computed?]
for the norm there is a factor 2 in the relevant get_me function. -> YES // should i change this to make it more uniform??
1. check partially filled shells functionality: Pair::setfnorm(factor) is referred to in manual -> everything seems ok with how it is dealt in the links and operator_virtual_ob class
9. check what the sum is in the pair class [see nucleus.cpp::450], also [getSum in pair.h::100]. Is this close to 1 always?->check! -> seems that way
check what getRelPair returns [nucleus.cpp::675] -> done and annotated in manual
11. check in nucleus if getRelpairs gives the expected results... (A(A-1)/2 for all) etc
check print functions in nucleus, check if l451 the sumcheck for pairs is ever triggered.. -> yes, when a partially filled shell has only one nucleon in it
xx. RESTRICTION on n too strict in norm functions??? Not diagonal with correlation function?? I think there is a mistake there.. -> fixed
36. normalisations obmd::write at the end -> ok with master formula
40. dimensions integrals in density_ob_integrand3 ->done!
41. parameter passing between density_ob3 and the integral classes!!! -> looks ok
34. units momentum distribution and intermediate results there -> annotated 10/12/17
26. what is the comment statement in norm_ob.h: "Note that this does not correspond with an isospin projection of a particle or particle pair!" (isospin selection)
-> probably ok, replaced this by explicit projector but same result
48. add static builds, debug and profiling flag options in cmake -> done 13/12/17
23. replace those functions iterating over map elements by C++11 functionality (basically look up all the it++ loops)
Worst offenders are probably
Paircoef::get_links -> done [old one still used in some test programs, otherwise can be deleted] 13/12/17
Nucleus::getPaircoef -> done by makeing arrays of pointers workaround [old one still used in some test programs, otherwise can be deleted] 13/12/17
Nucleus::getTripletcoef
Tripletcoef::get_links
27. PRIORITY check isospin selection in the norm_ob class!!! (is the naive assumption ok, replace with alternative used in the obmd calculations)
-> this has consequences for how matrix elements of the correlations operator etc are handled (factors 4T-3) etc. How is this handled in the obmd claculations...
-> Looks ok, everything still remains diagonal in T and MT -> (NOOO, see LCA manual p31 or p11, not diagonal in T!!!!)
-> Asymmetry is there in mom distribution results, but norms seem symmetric (np(p), np(n))
-> explicitly changed in normob and everything is still ok. 13/12/17
28. Nucleus::makepaircoefs: I think normi is always equal to normj (same pair)
so we could just replace this by the normf of the pair and reduce the confusing norm business!
-> done 23/12/17
16. why double pointers in Pair::getCoeff, make norm pointer a ref -> done 23/12/17
12. shells class, remove pointers -> done 23/12/17. Replaced by static array. WS shit still uses it though, but haven't touched that part.
6. Nucleus::nucleus get rid of dynamic allocations ->done
2. take out char* arguments and make them strings (RecMosh and others) -> done for basic classes
48. isopaircoefs: symmetry between pp and nn, take abs(MT) in key. Due to MT dependence only 1 of the tree strenghts is non-zero now! check mem usage for large nuclei then...,
one could take mt dependence out keys even and account for it in matrix multiplication since we know the MT from each of the 3 values...
-> done 26/12
49. isopaircoef:addxx funcntions, change those erase things since it could get into trouble later -> done 26/12
47. random segfaults in the beginning.... valgrind, profiling -> checked nothing out of the ordinary so far... (norm)
3. PRIORITY modify nucleusall such that bookkeeping is done of which pairs (or links) originate from which isospin combination
Can be done I think by storing 4 links maps (all, nn, pp , np) -> for iteration purposes maybe better, 1 map with second an array of 4 doubles.
But might be more difficult to implement? Check on T1 for the different cases (all or specific isospin)
-> done with Nucleus_iso class 26/12
24. in the correlation functions in the operator_virtual_ob, why all the superfluous parameters,
and why passing the result by pointer (this is for if statements in child classes)
-> changed in the operator_virtual_iso_ob class 26/12
37. !!!!PRIORITY in density_ob3. Integrand->add, I think there might be mistakes with the relative l qn passed. They should be the kA,kB parameters!
-> No, LCA manual was wrong, code is ok!! mistake w radial part wf 26/12
31. PRIORITY normob in double corr matrix element, order of k,l1//k,l2 (l414) [also other corr functions]
-> this is ok for norm, when corr function is conjugated, order of arguments switches of course! 26/12
SIMILAR QUESTION/PROBLEM in the corr matrix elements of the obmd calculations!!!
-> crosscheck with the order in all the integrand_cc->add calls!!!
-> looks ok! 26/12
38. In density_ob3::get_me_corr_both why is there a prefactor *=2. The sums over coefficients run over all??
-> think this was a mistake, changed it. we odn't really care since the pair functionality isn't used, coefs are better
32. in double corr norm matrix element if statements on doubles! + l478 substitute by -N // same in the paircoeff version (+ result at the end can be shorter) -> done 27/12
4. PRIORITY modify calculation of matrix elements such that all isospin combinations are being calculated in one go.
Now it is very inefficient as basically the program has to start from scratch each time and does almost the same thing all over (but with different linear combinations)
-> we will have to change the way the outputs work (at least for the norm) -> see how it is handled for the obmd's
-> Make new abstract class, where the output is given as a struct or a vector or something with 8 doubles for all the different isospin combinations
-> done for norm 26/12
-> done for obmd 29/30
35. density_ob3::write -> get rid of all the news (and deletes) -> done for the iso version
51. check bug for coefs in rms (left/right/both separately -> fixed 11/1/18
45. Compare the calculations that iterate over pairs with the one over paircoefs. Should yield identical results! -> ok for norms, rms 11/1/18
49. fix LCA manual with error in kA,lA -> done 10/1/18
19. naming variables, Lambda is sometimes used for coupled l, or sometimes for com OAM -> make uniform!! -> done 12/1/18
14. add sanity check to see that the recmosh object in pair & newcoef is for the correct quantum numbers. -> done 12/1/18
30. correlation integrals in norm_ob -> write some small extra functions (everything seems so similar every time?) -> combined for loops 11/1/18
25. in operator_virtual_ob::sum_me_corr check (l67) if diagonal contribution left and right is always equal even with restrictions...
everything looks symmetric (correlation functions in the two l arguments...) -> order of matrix element is different, will make a diff with tensor if restrictions are asymmetric
39. in obmd:corrpair methods left/right/both-> isospin projection t==0 case seems missing?? -> added 12/1/18
50. power calls in norm and rms, make some small arrays for that -> done for norm/rms 11/1/18
42. make com integral computation dimensionless argument? add function should be changed, integral too -> done 12/1/18