Messages

5401

Installation and License Questions / RHEL 5 x86_64

« on: December 11, 2008, 16:29 »

On the 64-bit edition of RedHat Enterprise Linux 5, there are sometimes no 32-bit Xmu libraries installed. In that case, the above will not help (you still get the Xmu error), and to solve it you need to download and install a compatibility library containing libXmu.so in a 32-bit version.

• Download the library compat-libs-5.2-2.i386.rpm from http://rpm.pbone.net/index.php3/stat/4/idpl/2396107/com/compat-libs-5.2-2.i386.rpm.html
• Install it with the command:

Code

rpm --install compat-libs-5.2-2.i386.rpm

• Search for the library libXmu.so (as root in /):

Code

find -iname libXmu.so*

This should return something like

./usr/lib64/libXmu.so.6
./usr/lib64/libXmu.so.6.2.0
./usr/i386-glibc20-linux/lib/libXmu.so.6
./usr/i386-glibc20-linux/lib/libXmu.so.6.0
./usr/i386-glibc20-linux/lib/libXmu.so

• Go to the folder lib in the VNL installation directory
• Create a symbolic link to the identified libXmu.so.6.0 library (if a libXmu.so file exist in the lib folder, remove it first):
  

Code

ln -s /usr/i386-glibc20-linux/lib/libXmu.so.6.0 libXmu.so.6

• Create an additional symbolic link libXmu.so (as both libXmu.so and libXmu.so.6 is needed):
  

Code

ln -s /usr/i386-glibc20-linux/lib/libXmu.so.6.0 libXmu.so

5402

Installation and License Questions / Re: FAQ: libg2c.so.0: cannot open shared object file: No such file or directory

« on: December 11, 2008, 16:21 »

Sometimes, after installing the library, you need to link VNL to it:

Go to the VNL lib directory and give the command

Code

ln -s /usr/lib/libg2c.so.0.0.0 libg2c.so.0

(or the appropriate location of the lib2c.so.* files).

5403

Installation and License Questions / SUSE Linux Enterprise Desktop

« on: December 11, 2008, 16:19 »

Install the GNU Fortran Compiler Runtime Library (containing libg2c.so) to fix the issue.

The library is not located on the installation CDs, so instead use http://rpm.pbone.net to locate a 32-bit version of the library.

• Download the library from
  ftp://ftp.pbone.net/mirror/ftp5.gwdg.de/pub/opensuse/repositories/home:/algraf/openSUSE_10.3/i586/libg2c33-3.3.3-42.5.i586.rpm (or a later version). Note that you need the 32-bit library, even on a 64-bit platform, since VNL is a 32-bit application.
• Install it with the command (as root):

Code

rpm --install libg2c33-3.3.3-42.5.i586.rpm

5404

Installation and License Questions / Novell Linux Desktop 9 SP3 x86

« on: December 11, 2008, 16:10 »

In Software Management mark the package "gcc-g77" for install (need Install CD1).

This will install the following 3 packages:

• glibc-devel-2.3.3-98.32.i686.rpm
• gcc-3.3.3-43.41.i586.rpm
• gcc-g77-3.3.3-43.41.i586.rpm

and the problem should be resolved.

5405

Installation and License Questions / CentOS 4.0/5.1 and RHEL 5

« on: December 11, 2008, 15:59 »

Either you can use the software manager to locate and install the needed package (search for libg2c.so), or you can download the needed packages manually:

• Download the package libf2c-3.4.6-11.i386.rpm from http://rpm.pbone.net/index.php3/stat/4/idpl/8964536/com/libf2c-3.4.6-11.i386.rpm.html (or a later version). Note that you need the 32-bit library, even on a 64-bit platform, since VNL is a 32-bit application.
• Install the package with the following command (as root):

Code

rpm --install libf2c-3.4.6-11.i386.rpm 

5406

Installation and License Questions / FAQ: libg2c.so.0: cannot open shared object file: No such file or directory

« on: December 11, 2008, 15:56 »

One of the most common error messages when trying to start VNL/ATK is

'Not available', 'libg2c.so.0: cannot open shared object file: No such file or directory'

Quite obviously, this is because the library libg2c is missing. In many cases it is straightforward to install this library from the relevant package/software/update manager (look for libg2c, libf2c or g77), but one needs to pay some attention to which version to install, especially on 64-bit platforms, since VNL is a 32-bit application and therefore needs the corresponding 32-bit g2c library.

Some more detailed advice on specific platform will appear in further posts on this thread!

In general, a good resource for locating missing libraries to download is http://rpm.pbone.net/ (click "Search", then go to "Advanced Search" to be able to select distribution, otherwise you usually get way too many results in the search).

5407

Installation and License Questions / FAQ: Cannot restore segment prot after reloc: Permission denied

« on: December 11, 2008, 15:41 »

When launching VNL after installing it, you may experience the following kind of error message:

QT ('Not available', '/home/user/vnl-2008.10.0/lib/python2.4/site-packages/qtext.so: cannot restore segment prot after reloc: Permission denied')

This can also occur for ATK, in which case the error message will point to the file lib/python2.4/_PyATK.so.

The cause of this error are the new kernel security extensions from the SELinux project which are enabled in some newer Linux distributions, to allow finer-grained control over system security and shared library loading. The solution is to register the relevant libraries in the security module to allow them to be relocated in memory.

For VNL:

Code

chcon -t texrel_shlib_t lib/python2.4/site-packages/qtext.so

For ATK:

Code

chcon -t texrel_shlib_t lib/python2.4/_PyATK.so

Don't forget that there is a local ATK installation inside the VNL installation too, which needs to be registered separately.

5408

Installation and License Questions / FAQ: Unable to resolve GL/GLX symbols (and/or Xmu symbols)

« on: December 11, 2008, 15:24 »

It is quite common, on several different different Linux distributions, to encounter the following error message when you launch VNL after installing it:

Unable to resolve GL/GLX symbols - please check your GL library installation.

The solution is relatively simple.

Locate the library libGL.so. To do this, give the command (as root, in /)

Code

find -iname libGL.so*

Most likely this returns something like

./usr/lib64/libGL.so.1
./usr/lib64/libGL.so.1.2
./usr/lib/libGL.so.1
./usr/lib/libGL.so.1.2

What we need to do, is link VNL to the 32-bit libGL.so.1 library.

Go to the lib directory in the VNL installation, and give the command

Code

ln -s /usr/lib/libGL.so.1 libGL.so

In many cases, this will not be sufficient to resolve the problem entirely, however. When you again try to launch VNL, you may now instead get the error message

Unable to resolve Xmu symbols - please check your Xmu library installation.

The solution is similar. Locate the library libXmu.so by giving the command (as root, in /)

Code

find -iname libXmu.so*

Most likely this returns something like

./usr/lib64/libXmu.so.6.2.0
./usr/lib64/libXmu.so.6
./usr/lib/libXmu.so.6.2.0
./usr/lib/libXmu.so.6

What we need to do, is link VNL to the 32-bit libXmu.so.6 library.

Go to the lib directory in the VNL installation, and give the command (if a link/file libXmu.so already exists in this folder, remove it first)

Code

ln -s /usr/lib/libXmu.so.6 libXmu.so

5409

Links to Resources and Publications / Papers from 2008

« on: December 11, 2008, 12:40 »

We are currently collecting article references from 2008 for inclusion on the QuantumWise web site. A few are already up - showing really exciting applications of ATK on topics which look not only like superb basic research, but even device-oriented in many cases:

• Molecular rectification in porphyrin dimer
• Spin-dependent electron transport in metallic carbon nanotubes
• Current-induced forces in conducting and semiconducting carbon nanotubes
• Ferrocene dimers for molecular wire applications
• Designing nanogadgets by interconnecting carbon nanotubes with zinc layers
• Electron transport through carbon nanotube in intramolecular heterojunctions with peptide linkages
• Conductance of benzene clusters in the Pi-stack direction
• Excess-silver-induced brigde formation in a silver sulfide atomic switch
• Interface electronic structures of zinc oxide and metals

Check them out at http://quantumwise.com/publications/scientific-publications!

If you have published an article with ATK, please make it known in the Forum (we would love it if you also included the abstract in the post!) or send us an email (contact details on the web site).

5410

General Questions and Answers / Re: script for making equivalent bulk from two-probe

« on: December 10, 2008, 12:40 »

There are a couple of different ways.

Simplest is perhaps to load the system into the Atomic Manipulator in VNL. Then, you click the button "Save Equivalent Bulk...".

There is also a NanoLanguage command; once you have created a two-probe system, the returned object has a method called equivalentBulkSystem(). Here's a very sketchy example of how to use it:

Code

from ATK.TwoProbe import *
...
twoprobe = TwoProbeConfiguration (...)
equiv_bulk = twoprobe.equivalentBulkSystem()

For reference: The equivalent bulk system contains the electrodes plus the central region, represented as a PeriodicAtomConfiguration. This is the system calculated by ATK in the "equivalent bulk run" that precedes the two-probe calculation when using the (default) keyword InitialDensity.EquivalentBulk in twoProbeAlgorithmParameters().

Hope that helps!

5411

General Questions and Answers / Re: Mesh-Cutoff

« on: December 8, 2008, 08:54 »

You should not expect the total energy to be a smooth curve that converges to a lot of decimals with increasing the mesh cut-off (or some other parameters like k-point sampling, for that matter). The nature of the problem, and the complexity of the non-linear self-consistent cycle means that there will always be small fluctuations. Therefore, look rather for a general trend of convergence when you plot the energy vs the mesh cut-off.

At the same time, I would not use the total energy as the criterion in a two-probe system, but rather something like the transmission spectrum (even just at the Fermi level).

If you plot this against the mesh cut-off there should be convergence before 400 Ry, hopefully!

5412

General Questions and Answers / Re: Mesh-Cutoff

« on: December 8, 2008, 01:01 »

Another point, in case somebody is wondering:

Since ATK is a numerical-orbital code, it's easy to think that the real-space mesh determined by the mesh cut-off also controls the basis set functions of the atomic orbitals. This is, however, not the case (which is one of the reasons you cannot compare the value of the cut-off in ATK with plane-wave codes).

The basis set orbitals are expanded on a radial equidistant grid where the point spacing is determined by the keyword radial_sampling_dr (in basisSetParameters()). The default value of this parameter was lowered quite substantially in ATK 2008.02 to improve the default accuracy, which in particular was very helpful in relaxations. The new value should give a sufficiently smooth representation of the basis functions in all normal cases.

For more information on the basis set functions, see the manual section on basisSetParameters().

5413

General Questions and Answers / Re: Mesh-Cutoff

« on: December 7, 2008, 22:44 »

The mesh cut-off is given as input by the user. It's an energy (default 150 Ry) which corresponds to the fineness of the real-space grid on which the Poisson equation is solved. (Or, grids, there are a couple of different grids, including the real-space electron density and the effective potential.) A higher value of the mesh cut-off gives a finer real-space grid and hence better accuracy.

The fineness or grid point spacing dx is calculated according to the formulas (hmm, isn't there a way to type math prettier...?)

E = hbar² k² / 2m

dx = pi/k (no factor 2 here!)

which if E is in Rydberg and dx is in Bohr becomes

dx = pi/sqrt(E)

k is the equivalent plane-wave cut-off component, but one can not really compare the values used in a plane-wave code and ATK, for several reasons.

This is perhaps obvious to you, but it's best to have a full explanation at hand.

Now, regarding how to choose the mesh cut-off, the only really proper way is to try with one value, then change it and see if the results (say, the current, or band structure) changes. If it does, you keep increasing it until the results converge.

The default (150 Ry) is often sufficient in most cases, in particular for electronic structure and transport calculations. In fact, for carbon nanotubes and other systems you can often decrease it and still get quality results (but not necessarily very fine plots of the density...). For geometry optimizations, a higher value is sometimes needed, in particular for elements with complex d-shells like iron.

So, the number of atoms is not really a determining factor a priori, and in most cases the real-space grids are not a limiting factor in the sense that the calculation uses too much memory. The main impact of increasing the mesh-cut off is rather on calculation time.

5414

General Questions and Answers / Re: Current calculation somparison with Smeagol

« on: December 7, 2008, 20:42 »

I can have a closer look at this, but it is immediately obvious from the input that the electrode is much too short. I'll write a bit more later about why, because this is a very important, and perhaps not entirely well document aspect.

But the short story is that you should probably put 4 or 6 gold atoms in the electrode, at minimum, perhaps 8 even. It's quite cheap for such a small system.

I would also increase the central region to 12 or 16 atoms, and again this would not be very expensive. The reason is that 1D chains are especially poor at screening the electrostatic interactions "spilling over" from the repeated copies of the system in the x-y plane. Such interactions, which are not "physical" in this system, even if the system itself is not entirely physical, break degeneracies and thus can disrupt the simple integer transmission plateaus you would expect in a system like this.

While a 1D chain is a nice toy-model, it is really not very physical. So, it might be easy to solve using simplified models, but when you a apply a more general 3D tool like full DFT as in ATK, it's not that simple any more... The system is susceptible to Peierls distortions and as noted above the poor screening often becomes a problem. Thus, while such systems appear like a simple check of a program, they will quickly bring out some quite subtle and complex issues that are not necessarily noticeable for more realistic systems. On the other hand, they are quite useful for debugging and, truth be told, to learn about the aforementioned subtleties :-)

So, perhaps you can rerun with more atoms and noticed, and I think there should be a difference in the results. It is also a good idea to compute and plot the transmission spectrum T(E) at both 0 V and 1 V, to get a more complete picture of where the value of the current comes from.

5415

General Questions and Answers / Re: Current calculation somparison with Smeagol

« on: December 6, 2008, 20:59 »

Generally speaking, if the system is set up correctly, a perfect 1D system should give integer values of the conductance at each energy, but there are many pitfalls so one needs to check the parameters and geometry carefully.

I could however not find any input file, seems somehow it wasn't attached to the post?