Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Topics - ziand

Pages: [1] 2
1
General Questions and Answers / Initial densty NeutralAtom
« on: March 18, 2014, 18:26 »
I use ATK 12.8.2 and the Hückel method to calculate a CNT-Device with metal electrodes.
Electrode calculation finishes in 1 step (bulk 5x5x3 metal atoms). This is okay.
Now, to save some time, I thought with Hückel we can choose
DeviceAlgorithmParameters(initial_density_type = NeutralAtom()).

What comes out at first step is (I deleted large portions of the output, but important stuff is there).
Quote
+------------------------------------------------------------------------------+
| Density Matrix Report                          DM        DD                  |
+------------------------------------------------------------------------------+
|   0  Al   [   0.716 ,  -0.827 ,   1.169 ]    3.95611   0.95611               |
|   1  Al   [   2.148 ,  -3.306 ,   1.169 ]    3.95619   0.95619               |
|   2  Al   [   3.579 ,  -5.786 ,   1.169 ]    3.95611   0.95611               |
|   3  Al   [   5.011 ,  -8.266 ,   1.169 ]    3.95653   0.95653               |
|   4  Al   [   6.443 , -10.746 ,   1.169 ]    3.95653   0.95653               |
|   5  Al   [   2.148 ,   1.653 ,   1.169 ]    3.95653   0.95653               |
|   6  Al   [   3.579 ,  -0.827 ,   1.169 ]    3.95601   0.95601               |
|   7  Al   [   5.011 ,  -3.306 ,   1.169 ]    3.95601   0.95601               |
|   8  Al   [   6.443 ,  -5.786 ,   1.169 ]    3.95653   0.95653               |
|   9  Al   [   7.875 ,  -8.266 ,   1.169 ]    3.95684   0.95684               |
|  10  Al   [   3.579 ,   4.133 ,   1.169 ]    3.95653   0.95653               |
|  11  Al   [   5.011 ,   1.653 ,   1.169 ]    3.95616   0.95616               |
|  12  Al   [   6.443 ,  -0.827 ,   1.169 ]    3.95722   0.95722               |
|  13  Al   [   7.875 ,  -3.306 ,   1.169 ]    3.95616   0.95616               |
|  14  Al   [   9.306 ,  -5.786 ,   1.169 ]    3.95653   0.95653               |
|  15  Al   [   5.011 ,   6.613 ,   1.169 ]    3.95611   0.95611               |
|  16  Al   [   6.443 ,   4.133 ,   1.169 ]    3.95601   0.95601               |
|  17  Al   [   7.875 ,   1.653 ,   1.169 ]    3.95722   0.95722               |
|  18  Al   [   9.306 ,  -0.827 ,   1.169 ]    3.95722   0.95722               |
|  19  Al   [  10.738 ,  -3.306 ,   1.169 ]    3.95601   0.95601               |
|  20  Al   [   6.443 ,   9.093 ,   1.169 ]    3.95619   0.95619               |
|  21  Al   [   7.875 ,   6.613 ,   1.169 ]    3.95619   0.95619               |
|  22  Al   [   9.306 ,   4.133 ,   1.169 ]    3.95601   0.95601               |
|  23  Al   [  10.738 ,   1.653 ,   1.169 ]    3.95616   0.95616               |
|  24  Al   [  12.170 ,  -0.827 ,   1.169 ]    3.95601   0.95601               |
|  25  Al   [   2.148 ,   0.000 ,   3.507 ]    7.27705   4.27705               |
|  26  Al   [   3.579 ,  -2.480 ,   3.507 ]    7.27734   4.27734               |
|  27  Al   [   5.011 ,  -4.960 ,   3.507 ]    7.27705   4.27705               |
|  28  Al   [   6.443 ,  -7.440 ,   3.507 ]    7.27609   4.27609               |
|  29  Al   [   7.875 ,  -9.919 ,   3.507 ]    7.27609   4.27609               |
|  30  Al   [   3.579 ,   2.480 ,   3.507 ]    7.27728   4.27728               |
...
|  70  Al   [   6.443 ,  10.746 ,   5.845 ]   10.84910   7.84910               |
|  71  Al   [   7.875 ,   8.266 ,   5.845 ]   10.85587   7.85587               |
|  72  Al   [   9.306 ,   5.786 ,   5.845 ]   10.84910   7.84910               |
|  73  Al   [  10.738 ,   3.306 ,   5.845 ]   10.85313   7.85313               |
|  74  Al   [  12.170 ,   0.827 ,   5.845 ]   10.85313   7.85313               |
|  75  Al   [   0.716 ,  -0.827 ,   8.183 ]   13.62751  10.62751               |
|  76  Al   [   2.148 ,  -3.306 ,   8.183 ]   13.63058  10.63058               |
|  77  Al   [   3.579 ,  -5.786 ,   8.183 ]   13.62751  10.62751               |
|  78  Al   [   5.011 ,  -8.266 ,   8.183 ]   13.62573  10.62573               |
|  79  Al   [   6.443 , -10.746 ,   8.183 ]   13.62573  10.62573               |
|  80  Al   [   2.148 ,   1.653 ,   8.183 ]   13.62573  10.62573               |
...
|  120  Al   [   7.875 ,   9.919 ,  10.521 ]   15.65670  12.65670              |
|  121  Al   [   9.306 ,   7.440 ,  10.521 ]   15.65670  12.65670              |
|  122  Al   [  10.738 ,   4.960 ,  10.521 ]   15.62076  12.62076              |
|  123  Al   [  12.170 ,   2.480 ,  10.521 ]   15.61755  12.61755              |
|  124  Al   [  13.602 ,   0.000 ,  10.521 ]   15.62076  12.62076              |
|  125   C   [  10.225 ,   0.000 ,  12.435 ]   15.38028  11.38028              |
|  126   C   [   5.525 ,   0.000 ,  12.435 ]   15.38028  11.38028              |
|  127   C   [   6.700 ,  -2.035 ,  12.435 ]   15.38028  11.38028              |
|  128   C   [   9.050 ,  -2.035 ,  12.435 ]   15.38028  11.38028              |
|  129   C   [   6.700 ,   2.035 ,  12.435 ]   15.38028  11.38028              |
|  130   C   [   9.050 ,   2.035 ,  12.435 ]   15.38028  11.38028              |
|  131   C   [   9.910 ,  -1.175 ,  13.146 ]   14.72651  10.72651              |
|  132   C   [   5.839 ,   1.175 ,  13.146 ]   14.72929  10.72929              |
|  133   C   [   5.839 ,  -1.175 ,  13.146 ]   14.72651  10.72651              |
|  134   C   [   7.875 ,  -2.350 ,  13.146 ]   14.72929  10.72929              |
|  135   C   [   9.910 ,   1.175 ,  13.146 ]   14.72929  10.72929              |
|  136   C   [   7.875 ,   2.350 ,  13.146 ]   14.72651  10.72651              |
|  137   C   [   7.875 ,  -2.350 ,  14.566 ]   14.72651  10.72651              |
|  138   C   [   9.910 ,  -1.175 ,  14.566 ]   14.72929  10.72929              |
|  139   C   [   9.910 ,   1.175 ,  14.566 ]   14.72651  10.72651              |
|  140   C   [   7.875 ,   2.350 ,  14.566 ]   14.72929  10.72929              |
...
|  270  Al   [   7.875 ,   8.266 ,  26.543 ]    3.95684   0.95684              |
|  271  Al   [   9.306 ,   5.786 ,  26.543 ]    3.95653   0.95653              |
|  272  Al   [  10.738 ,   3.306 ,  26.543 ]    3.95601   0.95601              |
|  273  Al   [  12.170 ,   0.827 ,  26.543 ]    3.95601   0.95601              |
+------------------------------------------------------------------------------+
|   0 E = -759.204 dE =  1.113262e+00 dM =  7.343037e+00 dH =  3.330028e+02    |
+------------------------------------------------------------------------------+

This looks like a very bad first guess and clearly far away from neutral atoms.
(The electrode copy are the first and last 75 atoms.)

Why is the starting guess so far off?

It still convergeres towards a reasonable result (--> Density matrix of Al about 3 and for C about 4) but it takes more steps than expected/necessary.
Quote
|  250  Al   [   2.148 ,  -1.653 ,  26.543 ]    2.99953  -0.00047              |
|  251  Al   [   3.579 ,  -4.133 ,  26.543 ]    2.99953  -0.00047              |
|  252  Al   [   5.011 ,  -6.613 ,  26.543 ]    3.00118   0.00118              |
|  253  Al   [   6.443 ,  -9.093 ,  26.543 ]    2.99914  -0.00086              |
|  254  Al   [   2.148 ,   3.306 ,  26.543 ]    2.99913  -0.00087              |
|  255  Al   [   3.579 ,   0.827 ,  26.543 ]    3.00023   0.00023              |
|  256  Al   [   5.011 ,  -1.653 ,  26.543 ]    3.00036   0.00036              |
|  257  Al   [   6.443 ,  -4.133 ,  26.543 ]    3.00023   0.00023              |
|  258  Al   [   7.875 ,  -6.613 ,  26.543 ]    2.99914  -0.00086              |
|  259  Al   [   3.579 ,   5.786 ,  26.543 ]    3.00118   0.00118              |
|  260  Al   [   5.011 ,   3.306 ,  26.543 ]    3.00023   0.00023              |
|  261  Al   [   6.443 ,   0.827 ,  26.543 ]    3.00006   0.00006              |
|  262  Al   [   7.875 ,  -1.653 ,  26.543 ]    3.00006   0.00006              |
|  263  Al   [   9.306 ,  -4.133 ,  26.543 ]    3.00023   0.00023              |
|  264  Al   [   5.011 ,   8.266 ,  26.543 ]    2.99953  -0.00047              |
|  265  Al   [   6.443 ,   5.786 ,  26.543 ]    2.99953  -0.00047              |
|  266  Al   [   7.875 ,   3.306 ,  26.543 ]    3.00036   0.00036              |
|  267  Al   [   9.306 ,   0.827 ,  26.543 ]    3.00006   0.00006              |
|  268  Al   [  10.738 ,  -1.653 ,  26.543 ]    3.00036   0.00036              |
|  269  Al   [   6.443 ,  10.746 ,  26.543 ]    2.99953  -0.00047              |
|  270  Al   [   7.875 ,   8.266 ,  26.543 ]    3.00052   0.00052              |
|  271  Al   [   9.306 ,   5.786 ,  26.543 ]    2.99953  -0.00047              |
|  272  Al   [  10.738 ,   3.306 ,  26.543 ]    3.00023   0.00023              |
|  273  Al   [  12.170 ,   0.827 ,  26.543 ]    3.00023   0.00023              |
+------------------------------------------------------------------------------+
|  27 E = -275.907 dE =  4.153771e-06 dM =  1.982099e-05 dH =  1.505746e-05    |
+------------------------------------------------------------------------------+
| Calculation Converged in 27 steps                                            |
+------------------------------------------------------------------------------+

If I increases the length of the central CNT it takes more and more steps to converge and at more than 10 CNT unit cells it refuses to converge at all.

If I do an equivalent bulk calculation, the output of step 0 looks much better.
(Ans this is what I do from now on.)

2
Future Releases / Structureless Electrodes
« on: November 18, 2013, 16:04 »
Hello,

I have a feature request, which (I think) might be quite easy to implement but useful and interesting, too.

That is: An option to have structureless electrodes (i.e. electrodes without atoms, very similar to the dielaectric/metallic regions that are already there).

Why would it be useful: Because often you want to study transport properties of some molecular structure, with as little impact from the contacts as possible. Of course this is a somewhat crude approximation. But nevertheless you do not have to worry too much about what effect comes from the electrodes and what comes from the molecule itself. Furthermore, real atomistic electrode contain very many atoms. This pushes calculations times, but sometimes, you just want to have a simple electrode, where you don't have to worry about details of the interface and so on...

How does it work (I used it before, in a self-written TB-code; and it is described for example here: DOI: 10.1103/PhysRevB.77.125420):
We describe the electrode as some sort of metallic region without any atoms. Every atom of the molecule that is inside the electrode region couples to the electrode. We assume that this coupling is very simple, governed by a hopping constant, say gamma_xy (may be element-specific, orbital-specific, and of course user defined). Then, the self energy of such an electrode takes a very simple form: It is diagonal and has the matrix elements -i*(gamma_xy)**2 on that diagonal ( i is the imaginary number; the size of that matrix depends on which and how many atoms couple to the electrodes; the gamma_xy describe the strength of the coupling between the orbitals of different atoms and the artificial electrode). Of course, this all gets most simple if one assumes, a non-selfconsistent single orbital orthogonal tight binding approach.

It can be summarized as follows: I want to set my own, user-defined lead self energy matrix, but without too much tedious hand-work (for me okay, but not for a commercial product, so I proposed the idea of the metallic electrode regions, to define that matrix in a visual and semi-automatic way).

This request is absolutely not urgent.
And there may be some more details to care about, if one wants to really implement that: e.g. non-orthogonal basis, selfconsistency possible/meaningful?, ...

3
General Questions and Answers / A question about Hückel parameters
« on: October 23, 2012, 10:49 »
The Cerdá Hückel parameters are double-zeta (two STOs per atomic orbital). Thus, in general, I need three parameters to describe an orbital: two Slater coefficients eta1, eta2 and one weighting factor C1. The other weight C2 is given by normalization.
As Cerdá wrote in his original paper, single-zeta is sometimes enough and in that case, one of the two STOs is chosen very localized: eta2 > 20. ATK takes only eta1 and C1 in that case.
Now I want to publish something about an improved set of Hückel parameters and therefore I'd like to know the value of eta2 (for example in case of the carbon 2s orbital; but should be same for all such orbitals).

Thanks.

4
General Questions and Answers / Vacuum_level of Huckel parameter sets
« on: August 8, 2012, 19:16 »
How are the vacuum_level parameters of the Cerda Huckel basis sets determined?
I know about their meaning, but how did your find the exact numbers?

5
General Questions and Answers / Electron configuration of palladium and platinum
« on: July 11, 2012, 16:23 »
The electron configuations of palladium and platinum from the manual are
[Kr]4d105s0 and [Xe]4f145d106s0.

The valence configurations from the manual are
4d105s0 and 6s15d9.

However, doing
print LDABasis.Palladium_DoubleZetaPolarized._serialize() and
print LDABasis.Platinum_DoubleZetaPolarized._serialize() gives
4d95s1 and 6s05d10

What is right? Does it matter (should only have an impact at the beginning of an SCF-cycle)?

6
General Questions and Answers / Error after installing ATK-12.2.0
« on: May 29, 2012, 19:11 »
After ATK-12.2.0 has been installed on a cluster, the following error appears. The script is a very minimum one. It contains just print "Test"
(Which is printed. Any additional ATK-code throws exceptions.)

Quote
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "./zipdir/NL/__init__.py", line 4, in <module>
  File "./zipdir/NLEngine.py", line 35, in <module>
  File "./zipdir/NLEngine.py", line 17, in swig_import_helper
ImportError: libpng12.so.0: cannot open shared object file: No such file or directory
Test

Before that, version 11.2.3 worked fine. I'm not aware of any changes on that cluster. ATK was not installed by myself but by some Admin. I do not have root access. I read the QuantumWise FAQ: The "missing library" is not missing on that cluster, I found it in /usr/lib/

I can however start an atkpython-shell (tested on the headnode). This works and I can run serious calculation from inside that shell. The error appears when I submit the job via qsub. (No matter how many nodes or mpi-jobs.)

We are using a PBS job scheduling system here, together with mvapich2.
The command "mpich2version" gives:

Quote
MPICH2 Version:         1.8a1
MPICH2 Release date:    Mon Nov 14 18:25:45 EST 2011
MPICH2 Device:          ch3:mrail
MPICH2 configure:       --prefix=/lustrefs/mpi/gcc-4.6.2/mvapich2-1.8a1p1 --with-rdma=gen2 --with-ib-include=/usr/local/ofed/include --with-ib-libpath=/usr/local/ofed/lib64 --enable-romio --with-file-system=lustre --enable-shared --enable-g=dbg --enable-debuginfo --enable-totalview --without-mpe
MPICH2 CC:      gcc    -g -DNDEBUG -DNVALGRIND -O2
MPICH2 CXX:     c++   -g -DNDEBUG -DNVALGRIND -O2
MPICH2 F77:     gfortran   -g -O2 -L/usr/local/ofed/lib64
MPICH2 FC:      gfortran   -g -O2

Any suggestions?
(I can send you my PBS-script if neccessary, but as I said, it worked with ATK-11.2.3.)
(And I will inform the cluster admin.)

7
General Questions and Answers / A question about pseudopotentials and basis sets
« on: May 23, 2012, 19:20 »
ATK comes with an extensive set of pseudopotentials (PPs). Those are norm-conserving PPs as parameterized by Troullier and Martins in the nonlocal form of Kleinman and Bylander, right? Are those PPs generated taking relativistic effects into account and what about nonlinear partial-core corrections?

Now, about basis sets: ATK uses the well established SIESTA-type pseudo-atomic orbitals. They are closely related to the famous Sankey-Fireballs (but with a more soft confinement), right? ATK provides parameters for the orbitals for many basis sets (SZ, SZP, ...  for LDA, GGA) of all elements. Those parameters include conf. strength (V_0), conf. start (r_inn), conf. cutoff (r_c), split norm (r_split).

o  r_split is found impirically to be 0.15. OK.
o  V_0 is 20 Hartree. Why?
o  How is r_c determined? (For the Fireballs it is the position of the first node of the PP eigenstate at a slightly excited energy (energy shift dE ~ +0.1 eV). The same here?)
o  How is r_inn determined or optimized?

Is there a paper where those things are described?
(I know for example:
Soler et al. [J. Phys.: Condens. Matter 14 (2002) 2745–2779] where it is mentioned that that it is usually better to fix a common energy shift, rather than a common radius r_c.
Artacho et al. [phys. stat. sol. (b) 215, 809 (1999)] again enegry shift as single parameter.
Anglada et al. [PRB 66, 205101 (2002)] mention the soft confinement, discuss r_c but seem to miss any comment on r_inn.
Junquera et al. [PRB 64, 235111 (2001)] discuss an optimization precedure for V_0, r_c and r_inn.
)

I noticed that the definition of the confining potential in [PRB 66, 205101 (2002)] and [PRB 64, 235111 (2001)] (SIESTA) differs from the one in the ATK manual. Is the one in the manual indeed the one used in ATK?


Thanks for your help.

8
General Questions and Answers / Peaks in the average effective potential at device boundaries
« on: April 5, 2012, 17:41 »
I calculate the effective potential of a strange "device". It has two metal electrodes, separated by a large vacuum. The Veff is then averaged along x and y (z is transport direction) and plotted as a function of z (see attached figure). By looking carfully at the right boundary of the graph, we see a sharp (1 data point) peak. What may be the reason for that and is this something to worry about?

9
General Questions and Answers / Strange behavior of current calculation
« on: April 4, 2012, 17:31 »
We are calculating I-V curves non-selfconsistently form one single transmission spectrum. Details are not interesting. For simplicity: suppose the spectrum is from -1eV to +1eV and constant (e.g. T(E)=1 for all E). Now we calculate the current from zero bias up to 2 Volt (!) at finite temperature (e.g. 300 K). Clearly the bias window coverage gets worse when approaching 2 Volt and the situation is better for lower temperatures.

Now the point I want to know is: What does ATK assume for the part of the transmission spectrum that is outside the window (the "missing data points" for E < -1eV and E > +1eV). Does it just drop it and assume T(E)=0 there or may it be that it uses T(E<-1eV) = T(-1eV) and T(E>+1eV) = T(+1eV) or something else?

The reason why I ask is the following. We did such a calculation (but for a real transmission spectrum which is not constant of course) and got an unrealistically strong increase in the current when approaching the boundaries of the transmission. We repeated the calculation "by hand", doing a simple manual integration. The ATK-current curve and the manual calculated one coincide for small and medium bias but there is a STRONG at higher values (first picture). I have to admit that our simple integeration scheme takes T(E)=0 outside the given energy range which is surely a bit unrealistic, but the results of ATK seem much to large. The ATK-curve is clipped but goes up by around an order of magnitude.

We repeated the procedure for much lower temperature and results get better (the point where both curves split shifts to higher voltages). Could you comment on what ATK is doing here?

By the way: Conductance calculations look odd, too (see second picture).

We can provide a minimal test script if needed.

10
General Questions and Answers / Why does the total energy increase during iterations?
« on: February 16, 2012, 11:49 »
Hallo,

by looking at some log-files, I found that the total energy of an equivalent bulk calculation of some device may increase.

Example:
|   0 E = -904.874 dE =  1.000000e+00 dH =  9.362434e+00                       |
|   1 E = -903.713 dE =  1.161121e+00 dH =  3.644521e+01                       |
|   2 E = -898.428 dE =  5.284778e+00 dH =  3.990358e+01                       |
|   3 E = -896.109 dE =  2.318983e+00 dH =  1.527096e+01                       |
|   4 E = -893.962 dE =  2.147338e+00 dH =  8.132774e+00                       |
|   5 E =  -890.87 dE =  3.091237e+00 dH =  5.594138e+00                       |
|   6 E = -889.498 dE =  1.372694e+00 dH =  6.958408e+00                       |
|   7 E = -883.724 dE =  5.773526e+00 dH =  3.347557e+00                       |
|   8 E =  -879.77 dE =  3.954026e+00 dH =  1.352267e+00                       |
|   9 E = -878.238 dE =  1.532401e+00 dH =  4.426615e-01                       |
|  10 E = -877.531 dE =  7.072604e-01 dH =  3.419547e-01                       |
|  11 E = -876.972 dE =  5.589668e-01 dH =  4.139195e-01                       |
|  12 E = -877.276 dE =  3.039722e-01 dH =  1.714145e-01                       |
|  13 E = -876.732 dE =  5.437031e-01 dH =  3.740001e-01                       |
|  14 E =  -876.32 dE =  4.116571e-01 dH =  2.179601e-01                       |
|  15 E = -876.591 dE =  2.711817e-01 dH =  2.163622e-01                       |
|  16 E = -875.904 dE =  6.871625e-01 dH =  1.749267e-01                       |
|  17 E = -875.692 dE =  2.124245e-01 dH =  3.310757e-01                       |
|  18 E = -875.051 dE =  6.406186e-01 dH =  3.007363e-01                       |
|  19 E = -874.876 dE =  1.756545e-01 dH =  8.158286e-02                       |
|  20 E =  -874.92 dE =  4.485747e-02 dH =  6.167444e-02                       |
...

Convergence is fine, but why does the energy increase? Is this physically meaningful? To my knowledge we search for the ground state energy that should be a global minimum. I know that there may be iteration steps when the energy goes up, but in the above example it looks rather systematic.

11
General Questions and Answers / Maybe a bug in BlochState
« on: February 10, 2012, 16:52 »
It is not very serious but I still report it:

The following code
Code
cnt=NanoTube(6,0)
cnt.setCalculator(HuckelCalculator())
bloch=BlochState(cnt)
Does a Huckel calculation for the CNT and throws an error
Code
---------------------------------------------------------------------------
TypeError                                 Traceback (most recent call last)
...\<ipython console> in <module>()
...\atkpython\bin\python26.zip\NL\Analysis\BlochState.pyc in __init__(self, configuration, quantum_number, spin, k_point)
...\atkpython\bin\python26.zip\NL\Analysis\BlochState.pyc in calculateBlochState(self, analysis, quantum_number, configuration, spin, k_point)
...\atkpython\bin\python26.zip\NLEngine.pyc in extractColumn(self, *args)
TypeError: in method 'ComplexMatrix_extractColumn', argument 2 of type 'int'
the same happens for
Code
bloch=BlochState(cnt,k_point=[0,0,0])
but not for
Code
bloch=BlochState(cnt,quantum_number=0)

12
Future Releases / LDOS
« on: January 20, 2012, 17:25 »
It seems there is no way to obtain the LDOS in ATK.
We have DOS, DDOS, and LDDOS.

Of course, one can create an ideal device and use the LDDOS but wouldn't it be easier to use normal BulkConfiguration and have a LDOS?

13
Future Releases / A tutorial on convergence of large (metallic) systems would be nice.
« on: January 19, 2012, 20:51 »
When dealing with large systems, especially large (maybe only in one dimensions) metallic systems, one often encounters convergence problems.

An eEffective ways to improve convergence is to increase the electron temperature. However, this affects the accuracy of the results at some point (very high T_el).
The other approch is called mixing. Right now ATK implements a Pulay mixer for the Hamiltonian. This is okay. What I'm asking for (maybe it is too complicated and only experience on the user side can help) is some sort of tutorial or guidlines how to twist the various parameters in order to systematically find a way out of a non-converging situation.

One has the parameters:
damping_factor, number_of_history_steps, start_mixing_after_step, linear_dependence_threshold and preconditioner.
The last one (preconditioner Kerker) itself has parameters: energy_q0, energy_qmax, maximum_damping

I doubt I'm the only user who is sometimes a bit puzzled which knobs are the most effective ones to twist or in which order one should change them to improve convergence (may it be slower (more tiny steps), but it should stop oscillating and the error should go down down down!!!)

Thanks.

14
Future Releases / Different smearing methods
« on: January 10, 2012, 12:25 »
Hello,

I know that when dealing with metallic systems, so called smearing is very importend.
ATK uses Fermi-Dirac smearing. Thus an electron temperature is introduced, which softenes the step in the occupation of states at the Fermi level.
The advantage of this method (as I understand) is the fact, that the electron temperature in Fermi-Dirac smearing can be interpreted as the real physical temperature of the system.

However, by looking on other codes and some publications I noticed that there exist other smearing methods. The most prominent are:
- (No smearing (not recommended for metals!))
- Fermi-Dirac
- Gaussian
- Methfessel-Paxton
- Marzari-Vanderbilt
- Tetrahedron method (with Blügel correction)

Different codes (I looked at siesta, quantum espresso and castep) use different smearing methods as their default. A new siesta-manual praises the Methfessel-Paxton method (can use high electron temp. and low numer of k-points).
Anyway, if you have the time ;-) or don't know what to put in a future release you could consider implementing one or the other of the above methods.

15
General Questions and Answers / Restart a broken device calculation
« on: December 5, 2011, 19:27 »
Hello,

I have read the Mini-Tutorial about restarting a calculation from a checkpoint file, but I have some minor questions. First: I still use ATK-11.2.3, and there is no force_restart keyword available. What does this force_restart=True in the new version really do?

Second question: My calculation broke after the equivalent bulk part of the device calculation and now the checkpoint file only contains a bulk-configuration and not a device-configuration. Furthermore I saved the electrodes to a separte file.

Is the following restart procedure correct (or do I loose something at step 4):
1.) read Electrode
2.) read checkpoint-file  (== equiv. bulk)
3.) create Device from equiv. Bulk and electrodes
4.) attach a new device calculator
5.) update

(By the way, I now use mvapich2 version 1.8a1. It has the nice side-effect, that this new version does not MPD anymore. Sadly I still get the initially mentioned seg.-fault errors from time to time after the equiv.-bulk has finished)

Pages: [1] 2