Topics

46

Installation and License Questions / FAQ: lmgrd error on Ubuntu 64-bit

« on: August 21, 2009, 11:42 »

As reported in a different thread, there is a problem running the license daemon lmgrd on Ubuntu 64-bit (e.g. version 9.04).

We never got to the bottom of it there, but the user didn't have a floating license anyway. However, there is still a real problem.

The symptom of the error is, that when lmgrd is started it reports

license daemon: system error code: No such file or directory

It's related to permissions; lmgrd is trying to create a file which it's not allowed to. Fortunately, there is a simple work-around.

1) First of all, use the lmgrd (32-bit) provided in the ATK package. I'm not sure if the 64-bit lmgrd will work with a 32-bit "atomist" vendor
daemon.

2) Next, as always, decide which user will run the license daemon. Root is not allowed, so it must be a simple user. I will call him "user"; this can
be a new dedicated account, "guest", "nobody" (these are usually pre-defined), or just the local ATK user.

3) Run

Code

sudo mkdir /usr/tmp/.flexlm

4) Run     

Code

sudo chown user /usr/tmp/.flexlm"

(change "user" as needed)

5) Start lmgrd as normal, as user "user"; to test it, use

Code

./lmgrd -z -c licensefile.lic

to run properly (as a daemon) remove the "-z".

This should allow you to run the license server and then ATK on Ubuntu 64-bit.

There may however be other problems with running VNL, we'll get back to that separately.

47

Installation and License Questions / FAQ: Opening ports

« on: August 10, 2009, 16:22 »

On various Linux distributions, and most notably RedHat Enterprise Linux 5 and similar, the default iptables rules mean that all ports are closed. Therefore, lmgrd will not be able to start (or be seen to outside computers).

To fix this, i.e. to run a license server on a RHEL 5 machine or any similar distro with iptables, you must open the relevant ports. Detailed instructions can be found here: http://www.cyberciti.biz/faq/howto-rhel-linux-open-port-using-iptables/

For lmgrd, you need to open first 27000 (or 27001 or whatever you choose as the lmgrd port; you need to enter this number in the license file, and use the same port number from the client computer), plus a port for the vendor daemon. Now, this port is random, unless you specify it explicitly. To do this, add a port specification to the VENDOR line in the license file, like so:

Code

VENDOR atomist port=34564

Then, open this port too. The port number is quite arbitrary, just make sure it is not used by some standard services. Choosing it quite large, in the 30000 range, is quite safe, most services work in the 2000-7000 range.

48

Scripts, Tutorials and Applications / Relaxation under bias

« on: July 30, 2009, 13:13 »

As many have noticed, the latest version of ATK do not support geometry optimization of a two-probe system under bias. Here is a solution that enables this feature!

First of all, let us point out one thing. The reason the functionality to relax under bias was removed in the first place (or more specifically, the reason why two-probes are relaxed as equivalent bulk systems; that's why you cannot use bias, since a bulk system cannot be biased), was that we found out that there was an ambiguity regarding the configuration that minimized the forces vs. the configuration that minimized the total energy. That is, the force minimum and the energy minimum did not coincide.

Now, some experts maintain that this is to be expected. Since the two-probe boundary conditions are open, the total energy is not a well-defined quantity, one should rather probably use the free energy.

However, the forces as computed by ATK should still be correct. Therefore, it should be possible to use the force-based Steepest Descent method to relax a two-probe system, even under bias. Now, all we need to do to enable this feature, is to tweak ATK a little bit, and this is what the attached script does.

An example is provided to show you how to use it. It's just a simple Li-H2-Li system, with constraints applied so that only the hydrogen atoms can move. It should converge in 9 steps or so.

The following things need to be observed:

1) Only the Steepest Descent method is supported, for the reason mentioned above. The default in ATK is actually QuasiNewton, however if you forget to specify Steepest Descent the script will not complain, it will just silently use it anyway (and use the default "time_step").

For details on the relaxation method itself, and how to specify parameters to it, see http://quantumwise.com/documents/manuals/ATK-2008.10/ref.geometricoptimizationparameters.html and the example provided there.

2) Unlike the built-in method for relaxation, the new function calculateOptimizedTwoProbeGeometry() (note that the function has a different name, to separate it from the native one) returns BOTH the optimized geometry AND the final self-consistent object. This saves you the hassle of re-calculating the last step, as is otherwise necessary if you wish to follow up with some analysis in the same script.

3) A bug regarding verbosity level was fixed, so now the same verbosity level applies to the whole run (the native version reverts to zero after the first step).

4) This is not an officially released version of this functionality, so please use it a bit carefully, and at your own risk

5) There is also support for initializing the relaxation from an already converged density matrix (in the form of an SCF object). This can be used to boot-strap a finite bias relaxation from a converged calculation, e.g. for the same bias or a lower one.

6) Finally, I would recommend you place the module script CalculateOptimizedTwoProbeGeometry.py centrally in your ATK installation, i.e. in lib/python2.4/site-packages (on Linux, use lib/site-packages on Windows). That way it will work in parallel just as well as in serial, and you don't have to worry about setting the Python path etc.

Attached files are:

• The module script
• An example NanoLanguage script
• The VNL file needed by the example

Comments, feedback etc is always welcome!

Update, after the original post: Added support for "initial_calculation".

49

Scripts, Tutorials and Applications / Convert old atk files to NanoLanguage

« on: June 15, 2009, 10:43 »

The short story

Some users may still have a lot of .atk input files for ATK 2.0 and earlier. The script attached in this post makes it extremely simple to upgrade such files to NanoLanguage files. The script converts all kinds of ATK 2.0 input files, including two-probe systems, into NanoLanguage scripts, ready to be run!

Compatibility note
To run the conversion script requires ATK 2.3 or higher. The generated scripts are compatible with ATK 2.2 and later (and also ATK 2.1 and 2.2 with relatively small modifications). However, we recommend you to use the latest ATK for several reasons (calculation speed, bug fixes, etc, etc)!

Introduction

It is our hope and intention, that these generated scripts will make it easier to learn NanoLanguage, and to lower the barrier in learning the new input format. Once you can see how the old keywords translate into NanoLanguage, it will be a simple matter to use the converted scripts as templates for new calculations, with different geometries and/or different parameters.

The script is very simple to use: download it into the directory where you keep you keep your atk files. Then, download and install the latest ATK, and run

Code

atk convert_atk_to_nl.py input.atk > script.py

for each input file (here symbolically called input.atk) you wish to convert. Batch processing is also possible, along the lines of (in bash)

Code

for i in *.atk ; do
    atk convert_atk_to_nl.py $i > $i.py
done

Two-probe systems

To convert two-probe systems, the input file should be the two-probe file (containing the definition of the central region). The script will automatically attempt to locate, and convert, the electrode files, based on the keywords TwoProbe::LeftElectrode::ATKFile or TwoProbe::LeftElectrode::NetCDFFile (and correspondingly for the right electrode). If the NetCDF keyword is used, the script will look for an ATK input file by the same name, but with the extension .atk. If this file is not found, the conversion will fail. In this case, please edit the two-probe script to match the names of the electrode input files.

Two-probe systems will be considered as heterogeneous if the name of the input files for left and right electrode are different. In this case, separate configurations and parameters will be defined for the left and right electrode, respectively, and the multigrid method will be employed in the two-probe calculation.

Output control

The generated script will, when you run it in ATK, produce verbose output (if you prefer less output, you can modify the verbosity_level defined in the head of the conversion script) a VNL file containing the structure, and a NetCDF checkpoint file.

All these files are named after the original input file, but with an additional label "converted" in the name. At the top of the conversion script are a few parameters that furthermore effect the output script:

• include_defaults. If this variable is set to True, the NanoLanguage file will be very explicit, with all parameters specified. If it is False, only parameters which are different from default will be shown, giving simpler and more readable code. Keywords specified in the list explicit_defaults will however always be explicitly printed out in the NanoLanguage code, even if they are assigned default values.
• remove_default_factories. If this parameter is True, empty constructions like basisSetParameters() will be removed, giving much simpler code.
• round_dec. If this is zero, all atom positions are printed "as is", which can give some ugly things like 0.9999999991 instead of 1.0. Setting this parameter to a non-zero (positive) value introduces rounding to the specific number of decimals. 5 seems to work nicely, unless it is of importance that the coordinates are very exact, in which case 8 could be a good value to still avoid values like 4.800000000004. Note that Python is rather clever and does not print trailing zeros (unless specifically asked to). Thus, even if the rounding is set to 5 decimals, a value like 4.800000000004 will be printed simply as 4.8.
• lattice_tolerance. See below.

Specific details

The following additional things should be noted about the conversion:

• The script can handle input files for molecules, bulk, and two-probe systems. Electrode files are not converted on their own, but only as part of the two-probe.
• Very limited error checking is performed. The input file is assumed to run properly in ATK 2.0. If it does, the script should be able to convert it.
• Default values are assigned to unspecified parameters using the NanoLanguage standard. Thus, the ATK 2.0 default file is not read and not used.
• K-point keywords are assigned default values corresponding to ATK 2.0 if they are not specified in the input file.
• Note that spin is handled a bit differently in NanoLanguage, so take extra care when converting spin-dependent calculations. The converted script may not exactly correspond to the calculation as defined in ATK 2.0.
• The script fully supports element-specific basis set parameters.
• Relaxation/geometry optimization is supported. In this case, the final configuration will also be stored in the VNL file, with the additional "optimized_geometry" in the sample name.
• All comments in the input files are conserved, and collected at the end of the output script.
• All un-converted keywords are also included in the output script for reference.

In NanoLanguage, it is necessary to specify explicitly the Bravais lattice for bulk systems, while in ATK 2.0 the unit cell was given as just three vectors. The conversion script will attempt to recognize the simplest lattice types:

Code

simple cubic
fcc
bcc
simple tetragonal
simple orthorhombic
rhombohedral
hexagonal

All other lattice types will be represented as Triclinic. This actually has no effect on the calculations, as the lattice type is never used explicitly in NanoLanguage.

Note that a tolerance factor is employed in the recognition of the lattice type. This tolerance is used for comparison of angles and lattice constants to each other and known values. The default is 1e-5, which seems to work fine for orthogonal lattices. It might, however, be too low for hexagonal if the lattice vectors are given with
few decimals. In that case, it is safe to increase the value to, say, 1e-3. The parameter is easily accessible at the top of the script.

Unsupported keywords

• The use of fractional spin is not supported in NanoLanguage. If such keywords are discovered in the input file, the conversion will fail.
• Basis set keywords from the electrode files will be ignored; the same basis set size should anyway always be used for all element in the entire structure, also in ATK 2.0.

• The script cannot yet convert pure analysis scripts; more specifically, the script must contain an atom list (and a unit cell, if it's a bulk system), and so on.

• In fact, no analysis options are, so far, converted. This may be supported in an updated version later on.
• All keywords related to pseudopotentials and ion files are ignored.
• The keywords UnitCell::X0/Y0/Z0 are not supported (they are not used in ATK 2.1 and higher anyway).

• The keyword Relaxation::MaxDisplacement is not supported (it is not used in ATK 2.3 and higher anyway). If you specifically want to use it with ATK 2.2, you can insert it back manually in the generated script. Please refer to the ATK documentation for details.
• Constraints in relaxations are not supported, you need to manually add them by hand afterwards, see the manual.
• The keyword TwoProbe::UseMultigridForElectrostatics is not supported (or rather, it is ignored). In NanoLanguage, the choice between homogeneous and heterogeneous systems is implicit (also see above about multigrid).
• Gate voltage is not supported yet. The corresponding NanoLanguage construction is quite different in nature (see the manual page on gate voltage).

Compatibility notes

To make the converted scripts compatible with ATK 2.1 and 2.2 is generally very simple. In fact, most converted scripts will work fine with these versions, and require no changes, except this one: Remove the nlPrint() statements.

After that, the first step, if you have an older version of ATK that you wish to use, is to simply test the script! If it fails, try these things to make the script compatible:

• Remove all references to algorithm_parameters. These parameters were introduced in ATK 2.3.
• Change two_center_integral_parameters to two_center_integrals_parameters (an extra "s"). The name of this parameter was changed in ATK 2.3.
• Remove the named parameters optimizer and trust_radius for geometricOptimizationParameters(). The construction was modified in ATK 2.3.

In all cases, these changes should only be necessary if include_defaults was set to True.

Final notes

You should always inspect the converted file carefully to verify that the conversion was successful, before attempting any calculations.

The script has been tested on a large amount of input files, but there may be special situations that have not yet been considered. If the script fails to convert an input file, or the converted script does not correspond to the input, please report the problem in this thread so that we can fix the problem!

We hope you will enjoy working with NanoLanguage, and explore and discover the much enhanced flexibility and control that the new input format offers over the old keyword-based input files. This script should hopefully make the transition easier!

50

Scripts, Tutorials and Applications / Expanding electrode repetitions

« on: June 15, 2009, 09:42 »

The Atomic Manipulator contains a very handy functionality to cleave any crystal along an arbitrary direction, specified via the Miller indices. This makes it powerful to use VNL to set up structures for e.g. slab calculations, in addition to making it easy to construct two-probe systems from surfaces.

The Atomic Manipulator always creates "minimal electrodes", and then uses the "repetitions" keywords for the TwoProbeConfiguration() construction to expand the electrodes to their full configuration. This saves calculation time for the electrode part by converting a lot of atoms into a lot of k-points, but sometimes it is desirable to obtain the full, explicitly repeated configuration of the electrode cell instead.

For slab calculations, the best way to do this is to save the "Equivalent BulK" system (there is a ready button for this in the Atomic Manipulator), but if you want to keep the system as a two-probe system, then you can use the attached script instead. It converts a two-probe system with repetitions to one without. Up-front this may seem a bit useless, since it generates an identical configuration which just takes more time to calculation. It can however be used as a first step towards a more complex two-probe geometry, e.g. one where the electrodes are shifted in X or Y with respect to each other (after the electrode cell has been expanded accordingly).

Anyway, the script is attached, and hopefully someone will find it useful! To use it as-is, just type

Code

atk expand_numrep.py file.vnl

to expand the first two-probe configuration in file.vnl. The expanded two-probe configuration will be put back in the VNL file with "_expanded_reps" appended to the sample name. (The name "numrep" comes from the original name for this keyword in ATK 2.0 and TranSIESTA-C.)

51

Gallery / Periodic table of VNL colors

« on: April 29, 2009, 21:23 »

VNL uses the JMol color map to assign a unique color to each element. There is a reference in the manual too, but I find the attached pictures to be quite useful.

In addition to the color, they also indicate the van der Waals and covalent radii in a nice way.

I have also attached the input file I created to generate the figures. It's a simple XYZ file of the periodic table; just import it in VNL and drop it on the Nanoscope!

52

News and Announcements / LaTeX on the Forum!

« on: April 23, 2009, 09:21 »

You can now use [tex]\LaTeX[/tex] equations on this Forum! The syntax is simple, just enclose the LaTeX formula in

Code

[ tex ]...[ /tex ]

(without the spaces, they are inserted to prevent the tags from actually rendering TeX code!)

Some examples:

[tex]\blue\Large      e^x=\sum_{n=0}^\infty\frac{x^n}{n!}[/tex]

There is even an interactive editor for equations! Click the last icon in the second button row (the blue one, to the right of the "list" icon)!

More examples to come (for now, see http://www.yourmathstutor.info/forum/index.php?topic=4.0, which uses the same technique as we do)!

53

Future Releases / NanoLanguage editor

« on: April 6, 2009, 23:01 »

Which editor do you primarily use to develop NanoLanguage (or general Python) code? There are many, many editors out there, so if yours is not listed in the poll, please post it in a comment!

We could try to develop some syntax highlighting and/or completion files for the most popular ones, if possible!

54

Scripts, Tutorials and Applications / New tutorial: Work function of metal surfaces

« on: March 16, 2009, 18:04 »

Thanks to its ability to treat large-scale systems without demanding a huge premium in calculation time, ATK is an ideal tool to study the work function of surfaces. To demonstrate this ability, Cybernet Systems Co., our highly valued distributor in Japan, have authored a very detailed and instructive tutorial on this topic.

The systems used for the demonstration are various metal surfaces, and as the tutorial will show, ATK provides accurate values for the work function for a wide range of metals.

55

Scripts, Tutorials and Applications / Spin Bloch states in graphene nanoribbons

« on: March 16, 2009, 13:53 »

Did you know that you can visualize Bloch states with ATK/VNL?!

We have used this functionality in a new tutorial to demonstrate how spin creates a band gap in a zigzag graphene nanowire, which is gapless/metallic without spin included. By plotting the Bloch states we see that the two spin components localize on opposite edges of the ribbon.

An example of a Bloch state plot is attached.

56

Links to Resources and Publications / Papers from 2009

« on: March 2, 2009, 13:08 »

Some publications with ATK have already appeared in 2009! Very interesting reading, on

• Tunnel currents across silane diamines/dithiols and alkane diamines/dithiols
• CrAs(001)/AlAs(001) heterogeneous junction as a spin current diode
• Half-metallic Au-V(Cr) quantum wires as spin filters
• Transport properties of T-shaped and crossed junctions based on graphene nanoribbons
• Switching characteristics of the phenoxynaphthacenequinone-based optical molecular switch with carbon nanotube electrodes

For more details and links to full text, see http://quantumwise.com/documents/ATK_Publication_List.html.

57

Scripts, Tutorials and Applications / Why not to use arange - and the alternative!

« on: February 24, 2009, 11:44 »

As useful as it may seem, numpy.arange() is not a reliable function. I recommend everyone to consider using numpy.linspace() instead, when possible.

From the documentation, it is pretty clear what arange() should deliver:

Code

arange(start,stop,step)

should give an array with values [start,start+step,start+2*step,...] until start+N*step > stop. "stop" is not part of the interval, the manual says.

So, let's try:

Code

arange(0.4, 1.1, 0.1)

Ok, this is what you expect: you get [0.4, 0.5, 0.6, 0.7, 0.8, 0.9, 1.0], and as the documentation says the endpoint, 1.1, is not included.

But, now try

Code

arange(0.4, 1.1, 0.1)

This time you get [0.5, 0.6, 0.7, 0.8, 0.9, 1.0, 1.1] - the end-point is suddenly included!!! 

The problem lies deeply buried in the bit representation of floating numbers. Due to the rule used to determine the number of points in the array, the last element in the output array may be larger than "stop". Actually, the manual is honest enough to mention this, but it makes it a bit hard to trust the output from this function!

It should be said, that the implementation of arange() has been under a lot of debate, regarding this point; see e.g. http://osdir.com/ml/python.numeric.general/2006-02/threads.html, and search for "arange" on that page. However, no result has come of this, and as a result I recommend that arange() not be used if it can be avoided.

Fortunately, there is an alternative, which actually is even better (ok, it depends a bit on what you are trying to achieve). The function numpy.linspace() is a bit unknown but very useful, and above all more predictable!

The syntax is very simple (I just paste the result of "help linspace" here, for convenience):

linspace(start, stop, num=50, endpoint=True, retstep=False)
    Return evenly spaced numbers over a specified interval.

    Returns `num` evenly spaced samples, calculated over the
    interval [`start`, `stop` ].

    The endpoint of the interval can optionally be excluded.

    Parameters
    ----------
    start : {float, int}
        The starting value of the sequence.
    stop : {float, int}
        The end value of the sequence, unless `endpoint` is set to False.
        In that case, the sequence consists of all but the last of ``num + 1``
        evenly spaced samples, so that `stop` is excluded.  Note that the step
        size changes when `endpoint` is False.
    num : int, optional
        Number of samples to generate. Default is 50.
    endpoint : bool, optional
        If True, `stop` is the last sample. Otherwise, it is not included.
        Default is True.
    retstep : bool, optional
        If True, return (`samples`, `step`), where `step` is the spacing
        between samples.

    Returns
    -------
    samples : ndarray
        There are `num` equally spaced samples in the closed interval
        ``[start, stop]`` or the half-open interval ``[start, stop)``
        (depending on whether `endpoint` is True or False).
    step : float (only if `retstep` is True)
        Size of spacing between samples.

Use this function whenever you want to create a sequence of real numbers between a start and an end point, with a specified number of points. This is often more handy than specifying the point spacing, as you must do for arange() anyway.

58

General Questions and Answers / Why so many k-points in the Z direction?

« on: February 19, 2009, 23:28 »

A question popped up on CCL (mailing list for computational chemistry), which has a strong relevance for ATK. The question was (rephrased a bit):

For a calculation of a systems like [metalic electrode]-[molecule]-[metalic electrode] with molecule along the z axis, some literature references mention k-point parameters like 1x1x100 or 3x3x100 for the Brillouin zone integration. It is surprising, because in interface system like SAM in periodic condition, reasonable k-point parameters are like 8x8x1. Can you explain this difference?

The key point of Atomistix ToolKit (or the TranSIESTA method, which ATK is based on) is that the boundary conditions are not periodic in the z direction. Instead, open boundary conditions are used, in order to apply a voltage across the structure, so that one can compute the electron current under finite bias.

To understand why one needs many Kz-points in this case, assume that you have an ideal system, i.e. the electrodes are identical to the central region. Let HL, HC, HR be the Hamiltonians of the left electrode, central region, and right electrode, respectively. HL, HR are calculated under periodic boundary conditions, while HC is evaluated with open boundary conditions using self-energies obtained from HL and HR.

Now, clearly you will only get integer transmission in this system if HL=HR=HC. To obtain this, the same k-point sampling should be used in
the Kx and Ky directions for the electrode and two-probe calculation. This point is quite trivial.

In the z-direction, however, the two-probe calculation corresponds to an infinite number of Kz points, thus you need a lot of k-points in the
z-direction for the electrode calculation to ensure the same level of accuracy.

Generally, the literature values for Kz (and the VNL default) may be a little conservative, but it is relatively inexpensive since these k-points are only required for the electrode calculation which is the smaller and faster part of the whole computation.

59

Scripts, Tutorials and Applications / Script for setting up Z-shaped graphene armchair-zigzag-armchair junctions

« on: February 13, 2009, 13:11 »

A junction between metallic and semiconducting graphene nanoribbons is often proposed as a potential novel transistor structure (see e.g. Ren et al., Chinese Journal of Chemical Physics 20, 489 (2007)). We also used this structure in the ATK tutorial on graphene, where the structure was built by piecing together two armchair segments (electrodes) and the zigzag central region by hand. This involved quite a few complex steps, so I decided to make a simple script that constructs the complete geometry in one shot!

So, here it is - I hope it will be useful!

To use it, just load it into any editor, set the relevant parameters in the top of the script. The following aspects of the geometry can be easily controlled this way:

• Width across (number of atomic layers) of the armchair segments
• Number of armchair unit cell repetitions in both electrodes, as well as in the central region (screening surface layers)
• Number of zigzag unit cell repetitions in the central region
• C-H and C-C bond length
• XY unit cell padding

Then just drop the script on the Nanoscope in VNL to visualized the geometry, and then, if you are happy with it, on the NanoLanguage scripter to set up the calculation. An example is included as a picture.

60

General Questions and Answers / MOVED: how to install VNL 2008.10 tried on linux(foroda6)

« on: January 13, 2009, 14:10 »

This topic has been moved to Installation Questions since it deals with installation issues.

http://quantumwise.com/forum/index.php?topic=67.0