It's really not as weird as it might seem once you understand how two-probe systems are constructed. I suggest you carefully study slides 8-11 in the basic ATK 2008.10 tutorial. And then it's probably a good idea to read all the other slides too, plus the one on analysis!

Also note that in ATK 2010.xx, two-probe systems are set up a bit differently.

Our posted solution is for getting VNL to run, not compile. There's a big difference, and it also matters very much if you have a 32- or 64-bit application. Seems you're on a 64-bit platform, but then you should also use 32-bit compilers if you want to use 32-bit libg2c. However, if this is the case, probably a better path for you is to install a real 64-bit g2c and compile with that.

Your 64-bit compiler will not look in lib32, for natural reasons

Beyond that, I can't help, we only offer support for our own software.

A bug in the FFT routines for two-probe (device) calculation has been found in ATK 2010.02.4185. We recommend all users to switch to the multi-grid method until the problem is resolved.

We wish to point out that ATK 2010.02 is an alpha version, and contains known bugs (besides the one mentioned above). A new major, stable release is expected by summer 2010, which will replace the 2008.10 and 2010.xx packages.

Not sure if it immediately solves the LU error, but: the electrodes are still too short. Make 3-4 repetitions of the electrodes too in the Z direction. Otherwise your results will be wrong anyway.

Also, perhaps it's a good idea to converge the non-spinpolarized system first, just to make the sure the geometry itself is ok.

The original script is correct, except that the electrodes are way too short; you should at least make them 3 periods, probably 4. And it wouldn't hurt to make the central region longer too, to include more perfect ribbon close to the electrodes, before the "impurity region".

The Atomic Manipulator somehow gets confused about the equivalent atoms; another good reason why this concept has been removed altogether in the new ATK/VNL (2010.xx). To check if the script is correct, visualize it in the Nanoscope instead; if you drag your initial script there, you will see that indeed it renders correctly (just too small, as noted above and also by zh).

ATK 2010.02 uses slightly different keywords, so there's no "TwoProbe" module anymore. Instead, use

Code:

from NanoLanguage import *

Do note, however, that you will need to modify other parts of the code as well; the scripts are not compatible. Your best option is actually to rebuild it from scratch in VNL or by hand. You can find the Li-H2-Li example still in the manual.

I'm sorry, the previous message is incorrect, this bug was not fixed in the latest release. You will still have to rely on the work-around. Do let us know if you feel we need to add something to that solution right now, e.g. related to plotting or some functionality that's missing.

Yes, with numbering starting at 0!

It looks to me as if the script isn't the issue here, but rather you are trying to initialize a spin-polarized calculation from the converged results of one that isn't spin-polarized. That doesn't work, whether in relaxation or not.

But to check: Does this error appear almost immediately, or after it's been running a while? Can you perhaps post the complete input and output, then it's easier to determine (you can mask the coordinates, in case your system geometry is sensitive).

I'm guessing that you see the error quite immediately, and in that case the problem is that the "initial_calculation" that you are providing is not spin-polarized, while your present system is (or opposite).

Well, there isn't any faster way than to compute them, it takes the time it takes

However, depending on exactly how you set up the script, you may be introducing various amounts of overhead. To determine that, however, you would have to post the script.

Generally speaking, your approach should be

1. Converge the self-consistent two-probe calculation. Never mind any "analysis", just make sure to store the NetCDF (checkpoint) file.

2. Perform all analysis from the checkpoint file, using the function restoreSelfConsistentCalculation() to restore the SCF object, then calculate what you want from that, just as if it were at the end of the main script

3. You don't have to give the k-points one by one to calculateTransmissionEigenvalues(). As you can see from its manual entry, you can in fact give it your entire list of k-points in one single call. Then just loop over the results instead, to print them for instance.

You will still have to loop over energies in my point 3, but you can skip the loop in your point 2.1.

zh's answer is very good.

I just want to add, for completeness, that for molecular systems, as referenced several times on this forum already, the absolute zero energy is the vacuum level meaning the effective potential very far away from the molecule.

Moreover, referring to your question about the "algorithm", as zh so correctly points out, the Fermi level is determined in such a way, that when you use the corresponding Fermi-Dirac occupations for all the molecular levels, the total charge sums up to the total number of electrons in the system. The value of the Fermi level, thus determined is numerically unique for a given set of molecular levels. (Note, however, that we have a slightly different set of such levels in each iteration of the SCF cycle, and thus the Fermi level is one of those quantities that needs to be determined self-consistently.)

From a more physical point of view, the Fermi level can be seen as an energy that lies between the occupied and unoccupied states, and thus can lie anywhere in the HOMO-LUMO gap (this is the same for semiconductors, so it's not special for molecules).

There is an extensive database of fullerenes in VNL 2010.02. Now, since the scripts for molecular geometries for ATK 2010.xx are almost compatible with 2008.xx, you should be able to easily copy/paste the code from there. The only modification needed is actually to replace

Code:

from NanoLanguage import *

with

Code:

from ATK.KohnSham import *

So, open the Database in 2010.02, select the desired fullerene, send it to an Editor, modify as indicated above, and copy/paste the code into the 2008.xx editor, from where you can drop the structure onto other instruments.

There is now also a VASP exporter for VNL

["Custom"]

As a follow-up to my VASP importer, I would like to share with the community a VASP exporter.

Update: Scroll down to the last post in this thread to download the latest version of the script.
It's really simple to use: drop the attached file on the "Custom" builder icon in VNL2010.02, then drop your geometry (must be a bulk configuration) on the drop zone, and the resulting POSCAR data will be written in the Log panel.

The first line (the comment line) contains the element ordering; use this to create your POTCAR file (which for obvious reasons VNL cannot generate).

Thus, now you can build a very complex system, using the nice GUI tools in VNL, and then export the geometry to run it with VASP! (Of course, we'd prefer that you would run the system with ATK, but we understand why VASP is useful too )

As always, feedback is very welcome! Would you like an option to write Cartesian coordinates (right now it writes only "direct")? Other features?

We should also note that a 1D system like this might not be the best one for testing the voltage drop, since the 1D chain screens the potential very poorly. I also think, when looking more closely at it, that the XY unit cell should be expanded in this example; there seems to be some interaction with the repeated chains in these directions. I would also sharpen the tolerance, not sure how much it helps, but the default 1e-5 is a bit on the liberal side for certain quantities (probably not current, but maybe more "intrinsic" quantities.

I would also like to point you to the beautiful voltage drop pictures posted by "nori", that really show that ATK can compute this accurately and "correct", if the system is correspondingly set up.

The 1D Li-H2-Li should in general not be seen a very suitable two-probe test system; many of its properties are quite artificial, in fact. Its primary appeal is that it's fast to compute, and so it serves as a good example to teach people how to compute various things, but it's less suitable for analyzing the results!

Finally, if you are interested in computing the voltage drop, you might find my new post on extracting the effective potential from a VNL file useful!