Basically, the Mulliken populations are related to the basis set, while the analysis in the paper goes more to the real-space density. Although there is naturally a correlation, precisely which charge you choose to assign to an atomic site is always a bit arbitrary (and, if you wish, not even physical, just numerical). In the paper they have a particular way of saying how much charge belongs to each atom (they take as the separation point the minimum of the charge on the bond-line), which certainly is not how the Mulliken populations are defined. So some difference should be expected.

Thus the Mulliken populations are a rather blunt instrument. If you really want to compare to the experimental results, I suggest you try to make similar contour plots as in Figs 2 and 3 in the article, of the electron density. Although VNL will not give you exactly such contour, but rather a bit more colorful ones, one should be able to compare the pictures, and hopefully find some agreement. In principle you could also try to reproduce Fig 4 but it's a bit trickier.

One thing you will note when checking the literature on this topic is that the definition of the "cross section area" is rather arbitrary for a nanotube, leading to results that differ quite a lot.

That depends on what coloring model you have chosen. Probably you have selected "color by sign", thus the two colors indicate positive and negative values. Insert the colormap and you will see!

PS: PNG is a much better image format than BMP Smaller filesize and viewable directly in the browser (like JPG), but no loss of quality (unlike JPG, which is designed for photographs, not drawings).

No.

That's the most likely reason. The error is actually thrown by MPICH2, not ATK, and means that one of the nodes stopped working, basically. Look in the log files (the .o or .e files if you run via qsub) for additional error messages that actually tell you why the node shut down ATK.

Not help.

Such things are not really controlled by the applications any more, but rather the OS. You need a 64-bit OS to use all the RAM in such a machine.

Also, you cannot really tell how much VNL "uses". It USED 3 Gb before it reached the point where it asked for more than was available. But in modern applications RAM is allocated dynamically; there isn't a predefined size reserved for VNL.

However, the problem I know you are facing unfortunately isn't really solved by having a lot more memory, but is related to poor memory handling in VNL itself. The data you need to manage is much smaller than 1 Gb, but VNL 2008.10 makes several internal copies, ramping up the total RAM usage way too much. These things will be taken care properly of in the new version. And, we're working on getting GGA into that! ;-)

And here it is!

The trick to getting it to work, is to give the tool enough information to work with. It needs to find a clear repetition pattern so assign as "electrode". Therefore, adding a few layers make it work.

However, you should at least double the electrode, which fortunately is extremely easy (just enter 2 for electrode repetition), or your system will either not converge or show artifacts. The electrode is too short, which will certainly introduce non-physical scattering.

Found it! Enjoy!

This works with 2008.10. Would be neat to make it into a Custom Builder for 2010.xx...

I have some experience with setting this system up. I'm not at this point sure exactly what goes wrong, but I would advise you first of all to consider if you really want AA stacking in the graphene. Normally, graphene has ABABAB stacking, but in that case you need a bit bigger unitcell in the XY plane, as in the attached example.

I also recall that this is a very hard system to converge. Maybe the parameters used in the attached script helps you a bit!

I had a neat little tool for setting the geometry up, based on some simple parameters (number of screening layers, etc), but I can't find it... I will look for it!

Try with at 3 (or more) gold layers on both sides. It's the left electrode which is problematic.

It's not possible. However, it is possible in 10.8, release pending any day now (in a beta-version).

Although, you can't control the shape, it will still be a sphere

Not really. But we're more and more getting a feeling that MultiGrid works better. Some examples have been seen where FFT doesn't give correct results. This is the subject of current investigations, so that we can make a proper decision for the future.

Like this?

I also corrected a minor mistake in the original version; the keyword "text" for configurations is new, it is not supported in the publicly available version 2010.02, but it will be supported in the next release.