Are you supposed to have a license server? If so, it means you have a purchased license most likely, so please contact us via email with the relevant customer details so we can help out more directly than via the Forum.

If the system truly is 1D, and for the sake of argument periodic along Z, then the only band structure that makes sense is from k=(0,0,0) to k=(0,0,pi/c) where c is the cell length in Z. The first point is Gamma, I usually call the other point Z for obvious reasons.

Now, you indicate that you are using the SimpleTetragonal class for your wire, and I assume it's aligned then such that it's periodic in Z with the C-vector = (0,0,c). In that case, the standard notation is such that the band structure should indeed be computed along G-Z.

You mention, however, K and X. The only crystal class where both these appear as symmetry points in the standard notation is FaceCenteredCubic, and that doesn't make sense for your 1D wire. In fact, ATK would only appear these points as input for the FCC lattice.

Please note that an update for 12.8 was published a few days ago, version 1.1 of the TubeWrapper. You can install it via the AddOn Manager in VNL 12.8. It doesn't contain any new functionality but has a few minor bug fixes.

Correct. The electrodes get the initial spin from the electrode copies.

Can't assist without knowing more. Device from Bulk can handle this, at least in 12.2 and 12.8.

Probably you are making a mistake in the script, so the Python code for generating the DeviceConfiguration fails. I would recommend building the central cell in the Builder and using the usual way to convert it to a device, instead of attempting the manual edit.

The script requires ATK 12.8.

In ATK 12.8 (and earlier), when you run scripts from the Job Manager in VNL, the scripts are not executed in the folder they reside, but in TEMP. Therefore this kind of script needs to be run from the command line. In 13.8, things will improve, I hope.

So you should run

Code:

atkpython dos1d_use.py

in the directory where your NC file is and where dos1d.py is.

Not really, no, this is what the two-probe or device model is for. No cheating!

You cannot calculate the transmission spectrum for a bulk configuration like this. See http://quantumwise.com/publications/tutorials/mini-tutorials/167 for the proper way to do it.

Sure. Just run it as

Code:

mpiexec -n 16 atkpython script.py > logfile.log

where of course 16 needs to be adjusted to your cluster configuration.

Do take care not to assign too many MPI processes to the same node, however. For general tips about running ATK in parallel, see http://quantumwise.com/documents/tutorials/latest/ParallelGuide/

This is a bit difficult, however in your case which is one-dimensional you can compute the DOS from the E-k relationship.

I actually had an old script for that, so I dusted it off and adapted it for band projection. Attached is the module script as well as an example of how to use it, and with an example of a CNT (4,4) band structure projected onto bands 31 and 32 (the two bands closest to the Fermi level).

(For those keeping track, this is very similar to the code in http://quantumwise.com/forum/index.php?topic=261.msg1512.)

UPDATED with a slightly modified script for better energy range selection.

Rippling and buckling is the same thing.

This can be a bit tricky, depending on which files you have right now.

One option which is always possible is to locate the checkpoint file. The name of this is written in the log file. At least the geometry in that is the last guess, although one should be careful to trust the "scf" state in it, since this may have been saved at some early step in the scf cycle (triggered by the 30 minute automatic interval).

The other possibility is if you have used a trajectory file, then this will for sure contain the last geometry, but does not contain the scf state.

Finally, if all else fails, you can in theory restore the geometry by reading the coordinates from the log file.

Some graphics drivers have these issues. Check that you are using the latest driver from the vendor of your graphics card, and not the generic Windows or Linux Mesa driver. Upgrading will additionally give a lot better 3D graphical performance.