I don't know if it is a mistake in the documentation, since online and shipped with the source code only the documentation for elk-3-3.15 is available, but at least there the default for lmaxmat = 6 is not the one that is used in elk-3-3.17, which is lmaxmat = 7.
This issue rises two questions:
1) Is there somewhere a corrected version of the documentation for 3-3-17?
2) Is there any way of determining the input parameters not set in elk.in? It doesn't seem like such a list is printed in any of the output files (if not I think this is a helpful feature)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
your comment is correct concerning the changed lmaxmat value, however, elk is a very good documented code if you go through the manual especially regarding other commercial available pseudopotential codes which are widely used.
Anyway for me the best way to check the defaul flags is by looking into
readinput.f90 which contains all defaults variables of the code.
best regards
Michael
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
thank you for your comment. The intention of my comment whas not to critizise the documentation or the developers, rather to ask for a more up to date documentation in case I have overlooked it. Usually, I contact the manual first instead of the code itself as a new user. (Besides I always think printing the actual Input values at startup is usually a nice feature to have, since things can go wrong (typo, unexcpected syntax issue) but this is only a suggestion)
Regards,
Julian
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I guess I should just stop looking into the manual...
Concerning this parameter I would have a question: The way it is implemented I think less symmetric cases are unreasonably punished, since every contribution has to be much better converged due to the summation, or is there any weighting in the case of highly symmetric cases I have overlooked? In other words, I think the more components there are, the larger one can/should choose epsstress?
I am asking because I have a case were the optimizer keeps oscillating around the correct volume. I increased the energy criterion to get more reliable energies (for better forces or in this case stress) and after a while the step size. Nevertheless, the lattice optimization won't converge (or eventually by luck). Is their a reliable way to tune the lattice optimization or is it, at present, just better to compute single-points vaying the lattice manually because the optimizer is not robust enough?
Thanks for pointing various places in which manual is lacking. We will correct it in near future.
I want to take this opportunity to point out a few things about the ELK project. Neither of the main developers of the code are paid in anyway to maintain or run the code/forum. Hence the idea behind the forum is that the users of the code can help each other when they encounter similar problems. By now many of the users are much better at running the code than Kay or myself and forum helps us use their expertise. We try to keep the environment in the forum friendly and recommend that people pose questions and help each other and us by pointing potential bugs. We highly recommend not using it as a "frustration outlet".
As for the code, it is a constantly changing and developing code. The idea behind it is to be able to put in some of the latest ideas and cutting edge physics. This means manual is and probably will stay lagging behind. It is important to note that such an on going and fast developing projects are not for everyone. Some people prefer static codes with well laid out manual, which elk certainly is not. In such a situation one of the commercial package is much more suited.
I hope soon one of the expert users will be able to help you resolve the issues.
Best
Sangeeta
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi everyone,
I don't know if it is a mistake in the documentation, since online and shipped with the source code only the documentation for elk-3-3.15 is available, but at least there the default for lmaxmat = 6 is not the one that is used in elk-3-3.17, which is lmaxmat = 7.
This issue rises two questions:
1) Is there somewhere a corrected version of the documentation for 3-3-17?
2) Is there any way of determining the input parameters not set in elk.in? It doesn't seem like such a list is printed in any of the output files (if not I think this is a helpful feature)
Dear Full Name ?,
your comment is correct concerning the changed lmaxmat value, however, elk is a very good documented code if you go through the manual especially regarding other commercial available pseudopotential codes which are widely used.
Anyway for me the best way to check the defaul flags is by looking into
readinput.f90 which contains all defaults variables of the code.
best regards
Michael
Dear Michael,
thank you for your comment. The intention of my comment whas not to critizise the documentation or the developers, rather to ask for a more up to date documentation in case I have overlooked it. Usually, I contact the manual first instead of the code itself as a new user. (Besides I always think printing the actual Input values at startup is usually a nice feature to have, since things can go wrong (typo, unexcpected syntax issue) but this is only a suggestion)
Regards,
Julian
epsstress=1.d-3 vs. the 5.d-4 in the manual
I guess I should just stop looking into the manual...
Concerning this parameter I would have a question: The way it is implemented I think less symmetric cases are unreasonably punished, since every contribution has to be much better converged due to the summation, or is there any weighting in the case of highly symmetric cases I have overlooked? In other words, I think the more components there are, the larger one can/should choose epsstress?
I am asking because I have a case were the optimizer keeps oscillating around the correct volume. I increased the energy criterion to get more reliable energies (for better forces or in this case stress) and after a while the step size. Nevertheless, the lattice optimization won't converge (or eventually by luck). Is their a reliable way to tune the lattice optimization or is it, at present, just better to compute single-points vaying the lattice manually because the optimizer is not robust enough?
Attatched find step, volume, and energy of the optimization:
1 78.95624702 -1272.81045476
2 78.76195705 -1272.81045562
3 78.41810890 -1272.81049903
4 77.75995338 -1272.81067923
5 76.25456230 -1272.81105735
6 74.43341670 -1272.81136621
7 73.67268518 -1272.81115429
8 73.73955675 -1272.81094813
9 74.04579388 -1272.81099870
10 74.57551949 -1272.81114554
11 75.20424270 -1272.81130712
12 75.75801729 -1272.81138582
13 76.14654521 -1272.81138632
14 76.32867240 -1272.81138582
15 76.40775138 -1272.81139120
16 76.38586069 -1272.81140596
17 76.26725668 -1272.81143010
18 76.06088707 -1272.81146727
19 75.79056199 -1272.81151064
20 75.42486712 -1272.81154412
21 75.76091593 -1272.81154414
22 75.64239815 -1272.81154365
23 75.51171510 -1272.81154076
24 75.47261064 -1272.81153602
25 75.46772440 -1272.81154163
26 75.49190729 -1272.81155143
27 75.52218936 -1272.81155799
28 75.45922763 -1272.81156099
29 75.31667471 -1272.81155966
30 75.17563529 -1272.81155170
31 75.17833399 -1272.81154728
32 75.23436588 -1272.81154694
33 75.31396566 -1272.81155306
34 75.39857472 -1272.81154800
35 75.50186271 -1272.81155428
36 75.57446842 -1272.81155843
37 75.57017389 -1272.81155999
38 75.49233908 -1272.81156012
39 75.38649942 -1272.81155879
40 75.32688705 -1272.81155498
41 75.38964147 -1272.81155499
42 75.40500690 -1272.81155521
43 75.43241077 -1272.81155612
44 75.46306816 -1272.81155802
45 75.48911801 -1272.81155957
46 75.47076663 -1272.81156074
47 75.41230385 -1272.81155972
48 75.35721745 -1272.81155718
49 75.36386595 -1272.81155419
50 75.41909558 -1272.81155470
51 75.47325412 -1272.81155731
52 75.47203069 -1272.81155829
53 75.37669355 -1272.81155904
54 75.25365431 -1272.81155620
55 75.22745829 -1272.81154708
56 75.21380949 -1272.81155804
57 75.15228884 -1272.81155674
58 75.13265701 -1272.81155080
59 75.15037516 -1272.81154625
60 75.19578132 -1272.81154780
61 75.15599526 -1272.81154780
62 75.18285790 -1272.81154910
63 75.24582276 -1272.81155422
64 75.27407603 -1272.81156144
65 75.28340242 -1272.81155059
66 75.29223570 -1272.81155007
67 75.28145318 -1272.81155112
68 75.23556220 -1272.81155040
69 75.17613213 -1272.81156011
70 75.07921376 -1272.81155401
71 75.05134717 -1272.81154475
72 75.08663883 -1272.81154282
73 75.17718234 -1272.81154703
74 75.24568559 -1272.81155583
75 75.28115132 -1272.81155015
76 75.34886682 -1272.81155185
77 75.39096272 -1272.81155478
78 75.39358367 -1272.81155711
79 75.37111610 -1272.81155783
80 75.36782123 -1272.81155625
81 75.37144150 -1272.81155626
82 75.37302254 -1272.81155633
83 75.37602023 -1272.81155642
84 75.38142757 -1272.81155561
85 75.39010776 -1272.81155615
86 75.40170116 -1272.81155621
87 75.41414417 -1272.81155778
88 75.42531080 -1272.81155849
89 75.43569399 -1272.81155896
90 75.43290616 -1272.81155827
91 75.41592394 -1272.81155840
92 75.38981214 -1272.81155817
93 75.36572239 -1272.81155708
94 75.35154453 -1272.81155602
95 75.34921296 -1272.81155592
96 75.35548637 -1272.81155561
97 75.36567439 -1272.81155585
98 75.38031426 -1272.81155608
99 75.39875653 -1272.81155723
100 75.40768542 -1272.81155803
101 75.39660505 -1272.81155804
102 75.38575693 -1272.81155802
103 75.37272392 -1272.81155768
104 75.36897514 -1272.81155693
105 75.37505490 -1272.81155658
106 75.38436604 -1272.81155674
107 75.39632182 -1272.81155727
108 75.40925228 -1272.81155792
109 75.42205109 -1272.81155830
110 75.42741725 -1272.81155858
111 75.42467327 -1272.81155853
112 75.41956608 -1272.81155843
113 75.42201936 -1272.81155817
114 75.42456765 -1272.81155765
115 75.42728674 -1272.81155819
116 75.43346353 -1272.81155830
117 75.43662221 -1272.81155847
118 75.43045006 -1272.81155878
119 75.41319827 -1272.81155824
120 75.39408418 -1272.81155749
121 75.41249635 -1272.81155759
122 75.40903522 -1272.81155754
123 75.40633014 -1272.81155774
124 75.40893321 -1272.81155779
125 75.41472073 -1272.81155843
126 75.42297239 -1272.81155856
127 75.42366863 -1272.81155880
128 75.41524276 -1272.81155874
129 75.40355406 -1272.81155860
130 75.40016129 -1272.81155767
131 75.40560560 -1272.81155742
132 75.41422416 -1272.81155782
133 75.42601378 -1272.81155832
134 75.44000218 -1272.81155862
135 75.44801935 -1272.81155872
136 75.43771973 -1272.81155998
137 75.40973692 -1272.81155868
138 75.38252818 -1272.81155756
139 75.37459024 -1272.81155686
140 75.38139424 -1272.81155656
141 75.37517510 -1272.81155656
142 75.37806665 -1272.81155659
143 75.38361302 -1272.81155674
144 75.39161690 -1272.81155691
145 75.40252686 -1272.81155724
146 75.41745828 -1272.81155745
147 75.43546269 -1272.81155843
148 75.44193185 -1272.81155890
149 75.43144673 -1272.81155987
150 75.41183695 -1272.81155858
151 75.39977944 -1272.81155770
152 75.39963140 -1272.81155741
153 75.40506415 -1272.81155751
154 75.41346387 -1272.81155785
155 75.42451241 -1272.81155841
156 75.42979187 -1272.81155871
157 75.42644526 -1272.81155869
158 75.42056720 -1272.81155866
159 75.42299649 -1272.81155843
160 75.42779063 -1272.81155795
tasks
2
maxlatvstp
20
bfieldc
0.0 0.0 0.5
spinpol
.true.
latvopt
1
epsengy
3.5e-8
epspot
1.e-7
epsstress
1.e-3
!decreased this after a while from the default, didn't help
tau0latv
0.05
stype
1
swidth
0.005
!Broyden mixing
mixtype
3
!PBE
xctype
20
nempty
8
lmaxmat
10
lmaxvr
7
lmaxapw
10
rgkmax
10.0
isgkmax
-2
gmaxvr
16.5
trimvg
.true.
!11 11 11
ngridk
4 4 4
species
26
'Fe' 'iron'
55.845
1.90
10
1 0 1 2
2 0 1 2
2 1 1 2
2 1 2 4
3 0 1 2
3 1 1 2
3 1 2 4
3 2 2 4
3 2 3 2
4 0 1 2
avec
4.6818627718132975 0.0 0.0
-1.560621023337564 4.41410251767245 0.0
-1.560621023337564 -2.207049599180853 3.822725873285856
atoms
1 : nspecies
'Fe.in' : spfname
1 : natoms; atpos, bfcmt below
0.0 0.0 0.0 0.0 0.0 0.0
Last edit: julian 2016-04-16
Dear Julian,
Thanks for pointing various places in which manual is lacking. We will correct it in near future.
I want to take this opportunity to point out a few things about the ELK project. Neither of the main developers of the code are paid in anyway to maintain or run the code/forum. Hence the idea behind the forum is that the users of the code can help each other when they encounter similar problems. By now many of the users are much better at running the code than Kay or myself and forum helps us use their expertise. We try to keep the environment in the forum friendly and recommend that people pose questions and help each other and us by pointing potential bugs. We highly recommend not using it as a "frustration outlet".
As for the code, it is a constantly changing and developing code. The idea behind it is to be able to put in some of the latest ideas and cutting edge physics. This means manual is and probably will stay lagging behind. It is important to note that such an on going and fast developing projects are not for everyone. Some people prefer static codes with well laid out manual, which elk certainly is not. In such a situation one of the commercial package is much more suited.
I hope soon one of the expert users will be able to help you resolve the issues.
Best
Sangeeta