Greetings,
I am beginning to work with Abinit, and yes I have seen the other posts by those already doing calculations on nanotubes (but hopefully I did not miss a pertinent one, or one that explains explicitly acell).
Suppose that I use the online TubeGen software to get the coordinates for a (2,2) tube (in bohrs)
1.402181 -0.000000 -1.233916
0.682146 1.225067 -1.233916
0.000000 1.402181 0.000000
-1.225067 0.682146 0.000000
-1.402181 0.000000 -1.233916
-0.682146 -1.225067 -1.233916
0.000000 -1.402181 0.000000
1.225067 -0.682146 0.000000
TubeGen's output also gives me the length = 4.66353(bohrs) and the diameter= 5.29948(bohrs). Now, if I visualize this (using Xcrysden) I see that the tube is aligned along the z-axis. Clearly if it is aligned along the z, looking at the z coordinates, my length is around 1.23Angstroms (2.32bohr). Visualizing with Xcrysden confirms TubeGens diameter of ~4.66bohrs. So I should use my directly visualized dimensions...
My guess, acell = 4.66353 4.66353 2.32
Is this acceptable for acell? I have negative coordinates for x,y, and not sure exactly how Abinit handles this. My understanding is that acell defines my unit cell. My end goal is that I want to calculate the band structure, do a GW calculation, etc, for a long tube. My logic tells me then if this unit cell is correct, then I can simply do for long tubes:
acell = 4.66353 4.66353 20*2.32 (for a tube 20*2.32 bohrs long)
I was reading a paper " Quasiparticle energies, excitonic effects and optical absorption spectra of small-diameter single-walled carbon nanotubes" and they talk about have an 'array' of tubes with an intertube distance of ~9.47angstroms. Am I incorrect in thinking about the acell above, in that it would simply be single tube replicated in the z-direction? I mention this paper because I have no idea why one would need to include tubes so far away...
thanks
nanotube input file - acell - explanation request
Moderator: bguster
-
- Posts: 20
- Joined: Thu Dec 10, 2009 5:58 pm
Re: nanotube input file - acell - explanation request
Dear Joe,
ABINIT can handle only periodic systems in the X,Y, and Z directions, so you can only calculate for a rope of nanotubes.
The values of acell are the periods in each of these directions ( = dimensions of unit cell).
So acell_1 and acell_2 must definitely be larger than the diameter of the CNT. In fact, if you are trying to calculate for a single CNT,
you should do a convergence study, increasing acell_1 and acell_2, to find when you have enough vacuum between the tubes
so that the system represents an isolated CNT. If you are trying to calculate for a rope, you need to note that your unit cell geometry (rprim) will
be hexagonal, and calculate the total energy at several sizes of the unit cell, plot the energy curve, and choose that size of unit cell
which corresponds to the minimum of energy.
As far as I know, negative coordinates are fine in ABINIT. Make sure to visualize after a DEN calculation
using cut3d to make an XCrysDen file.
I hope this answers some questions,
Mamikon
ABINIT can handle only periodic systems in the X,Y, and Z directions, so you can only calculate for a rope of nanotubes.
The values of acell are the periods in each of these directions ( = dimensions of unit cell).
So acell_1 and acell_2 must definitely be larger than the diameter of the CNT. In fact, if you are trying to calculate for a single CNT,
you should do a convergence study, increasing acell_1 and acell_2, to find when you have enough vacuum between the tubes
so that the system represents an isolated CNT. If you are trying to calculate for a rope, you need to note that your unit cell geometry (rprim) will
be hexagonal, and calculate the total energy at several sizes of the unit cell, plot the energy curve, and choose that size of unit cell
which corresponds to the minimum of energy.
As far as I know, negative coordinates are fine in ABINIT. Make sure to visualize after a DEN calculation
using cut3d to make an XCrysDen file.
I hope this answers some questions,
Mamikon
Re: nanotube input file - acell - explanation request
Thanks for your reply Mamikon, I greatly appreciated your input.
Does anyone know of a good pseudopotential for nanotubes? I have been using the LDA Troullier-Martins psp and have had trouble converging. I have tried also tried the Trouiller-Martins-type, LDA Ceperley/Alder Perdew/Wang (both from the Abinit site). I have optimized the unit cell in gamess in attempt to have a different starting geometry, which had no effect. Following the manuals advice (to optimize nuclear positions with optcell=0, then start the cell shape and size optimization from the cell with relaxed nuclear positions) , I was starting with an optimization of just the atoms with:
nstep 300
optcell 0 # modify nuclear positions
ionmov 3 # conduct structural optimization using the Broyden-Fletcher minimization
ntime 10
dilatmx 1.1
ecutsm 0.5
I could increase nstep, but this optimization already goes on for quite some time. The magnitude of the convergence at the 300th step is generally as follows:
scprqt: WARNING -
nstep= 300 was not enough SCF cycles to converge;
maximum energy difference= 4.522E+00 exceeds toldfe= 1.000E-06
Thanks in advance
Does anyone know of a good pseudopotential for nanotubes? I have been using the LDA Troullier-Martins psp and have had trouble converging. I have tried also tried the Trouiller-Martins-type, LDA Ceperley/Alder Perdew/Wang (both from the Abinit site). I have optimized the unit cell in gamess in attempt to have a different starting geometry, which had no effect. Following the manuals advice (to optimize nuclear positions with optcell=0, then start the cell shape and size optimization from the cell with relaxed nuclear positions) , I was starting with an optimization of just the atoms with:
nstep 300
optcell 0 # modify nuclear positions
ionmov 3 # conduct structural optimization using the Broyden-Fletcher minimization
ntime 10
dilatmx 1.1
ecutsm 0.5
I could increase nstep, but this optimization already goes on for quite some time. The magnitude of the convergence at the 300th step is generally as follows:
scprqt: WARNING -
nstep= 300 was not enough SCF cycles to converge;
maximum energy difference= 4.522E+00 exceeds toldfe= 1.000E-06
Thanks in advance
-
- Posts: 138
- Joined: Sat Aug 15, 2009 12:45 am
Re: nanotube input file - acell - explanation request
Hello,
If the SCF cycles do not converge, you might have a problem with your system. Which kind of occupation did you choose ? If you did not put anything for occopt, abinit assumes your system is a semiconductor. But your system might be metallic then you should use occopt >= 3 with a convenient tsmear (as low as possible to describe your system but high enough so that you do not need too much k-points.... see tutorial 4 on FCC aluminium).
David
If the SCF cycles do not converge, you might have a problem with your system. Which kind of occupation did you choose ? If you did not put anything for occopt, abinit assumes your system is a semiconductor. But your system might be metallic then you should use occopt >= 3 with a convenient tsmear (as low as possible to describe your system but high enough so that you do not need too much k-points.... see tutorial 4 on FCC aluminium).
David
return to nanotube symmetry
Thanks David,
I definitely should have been more conscious of the fact that the (2,2) tube is metallic. I have now returned to trying to optimize (n,0) tubes (semiconducting), to get the simplest calculation running first (avoid having to change tsmear and occopt from defaults for now) . I saw on another post (space group of 2,2 Carbon Nanotube) that someone also had trouble getting the correct symmetry to come out, but that the solution/further discussion was not provided, so I hope it is okay to readdress that here.
As mentioned above by Mamikon (and mentioned in other posts) the hexagonal geometry should be noted in rprim, ie we should use
angdeg = 90 90 120
which is equivalent to
rprim = 0.86602540378 0.5 0.0
-0.86602540378 0.5 0.0
0.0 0.0 1.0
I just realized that nanotubes in an 'array' follow hexagonal-close-packing, so indeed the primitive vectors would be identical to graphene (yes I was very slow at realizing this). Now I see in my log file:
ingeo : use angdeg to generate rprim.
symlatt : the Bravais lattice is hP (primitive hexagonal)
xcart is defined in input file
ingeo : takes atomic coordinates from input array xcart
symlatt : the Bravais lattice is hP (primitive hexagonal)
symlatt : the Bravais lattice is hP (primitive hexagonal)
symbrav : COMMENT -
The Bravais lattice determined only from the primitive
vectors, bravais(1)= 6, is more symmetric
than the real one, iholohedry= 3, obtained by taking into
account the atomic positions. Start deforming the primitive vector set.
symbrav : found invariant axis, jaxis= 7
symlatt : the Bravais lattice is oC (one-face-centered orthorhombic)
(...sym planes and axes)
symspgr : spgroup= 35 Cm m 2 (=C2v^11)
...
Symmetries : space group Cm m 2 (# 35); Bravais oC (1-face-center ortho.)
It seems that the correct primitve hexagonal Bravais lattice was recognized initally, but the last symlatt seems to have chosen one-face-centered orthorhombic. This is possibly what folks(in the other post) saw in their output because they also observed Cmm2 #35 space group, which corresponds to:
a C2v(superscript 11) 'Schoenflies notation'.
Since my tubes are aligned along the z-axis, if I take a slice of the tube array down the xy plane, I will see a hexagon with tube ends on each corner, and one in the middle (ie hexangonal packing). I am used to assigning point groups to molecules, so I can only reason for the crystal that the initial TubeGen coordinates are not precisely equidistant (otherwise I would have a C4 rotation around the zaxis). If you look at the structure for the (8,0) tube from TubeGen coordinates, there is not a plane of inversion perpendicular to the zaxis (hence the v in C2v).
I am trying to visualize if the 1-face-center orthorhombic is reasonable, which you can see here
http://chemistry.about.com/od/crystallo ... hombic.htm . If we were dealing with atoms this is easy to visualize. But here, where ever you see an atom in the picture, this is the center of a tube. If you start drawing tubes it seems to make sense, you have basically a hexagonal-close packing, but is called face-centered-orthorhombic because of variations in the bond lengths (I think).
Does this seem correct? I stress over this because I have not come up with a good way to visualize the whole crystal (because we never see the coordinates of the images produced), and once Abinit recognizes a symmetry it runs with it. Particularly, when I give Abinit my tube surrounding the origin what am I giving it? If you look at the primitive cell for a face-centered orthorhombic it is a cube within the orthorhombic unit cell (the primitive cell only makes sense for atoms, so I don't know how to think about this here). Am I giving Abinit a unit cell, and if so shouldn't I be giving it a quarter of a tube in the corners of the unit cell?
I could trust Abinit for now in that it knows how to take my structure and replicate it accordingly, but it would be great for someone to confirm / invalidate this discussion / symmetry found.
thanks much
I definitely should have been more conscious of the fact that the (2,2) tube is metallic. I have now returned to trying to optimize (n,0) tubes (semiconducting), to get the simplest calculation running first (avoid having to change tsmear and occopt from defaults for now) . I saw on another post (space group of 2,2 Carbon Nanotube) that someone also had trouble getting the correct symmetry to come out, but that the solution/further discussion was not provided, so I hope it is okay to readdress that here.
As mentioned above by Mamikon (and mentioned in other posts) the hexagonal geometry should be noted in rprim, ie we should use
angdeg = 90 90 120
which is equivalent to
rprim = 0.86602540378 0.5 0.0
-0.86602540378 0.5 0.0
0.0 0.0 1.0
I just realized that nanotubes in an 'array' follow hexagonal-close-packing, so indeed the primitive vectors would be identical to graphene (yes I was very slow at realizing this). Now I see in my log file:
ingeo : use angdeg to generate rprim.
symlatt : the Bravais lattice is hP (primitive hexagonal)
xcart is defined in input file
ingeo : takes atomic coordinates from input array xcart
symlatt : the Bravais lattice is hP (primitive hexagonal)
symlatt : the Bravais lattice is hP (primitive hexagonal)
symbrav : COMMENT -
The Bravais lattice determined only from the primitive
vectors, bravais(1)= 6, is more symmetric
than the real one, iholohedry= 3, obtained by taking into
account the atomic positions. Start deforming the primitive vector set.
symbrav : found invariant axis, jaxis= 7
symlatt : the Bravais lattice is oC (one-face-centered orthorhombic)
(...sym planes and axes)
symspgr : spgroup= 35 Cm m 2 (=C2v^11)
...
Symmetries : space group Cm m 2 (# 35); Bravais oC (1-face-center ortho.)
It seems that the correct primitve hexagonal Bravais lattice was recognized initally, but the last symlatt seems to have chosen one-face-centered orthorhombic. This is possibly what folks(in the other post) saw in their output because they also observed Cmm2 #35 space group, which corresponds to:
a C2v(superscript 11) 'Schoenflies notation'.
Since my tubes are aligned along the z-axis, if I take a slice of the tube array down the xy plane, I will see a hexagon with tube ends on each corner, and one in the middle (ie hexangonal packing). I am used to assigning point groups to molecules, so I can only reason for the crystal that the initial TubeGen coordinates are not precisely equidistant (otherwise I would have a C4 rotation around the zaxis). If you look at the structure for the (8,0) tube from TubeGen coordinates, there is not a plane of inversion perpendicular to the zaxis (hence the v in C2v).
I am trying to visualize if the 1-face-center orthorhombic is reasonable, which you can see here
http://chemistry.about.com/od/crystallo ... hombic.htm . If we were dealing with atoms this is easy to visualize. But here, where ever you see an atom in the picture, this is the center of a tube. If you start drawing tubes it seems to make sense, you have basically a hexagonal-close packing, but is called face-centered-orthorhombic because of variations in the bond lengths (I think).
Does this seem correct? I stress over this because I have not come up with a good way to visualize the whole crystal (because we never see the coordinates of the images produced), and once Abinit recognizes a symmetry it runs with it. Particularly, when I give Abinit my tube surrounding the origin what am I giving it? If you look at the primitive cell for a face-centered orthorhombic it is a cube within the orthorhombic unit cell (the primitive cell only makes sense for atoms, so I don't know how to think about this here). Am I giving Abinit a unit cell, and if so shouldn't I be giving it a quarter of a tube in the corners of the unit cell?
I could trust Abinit for now in that it knows how to take my structure and replicate it accordingly, but it would be great for someone to confirm / invalidate this discussion / symmetry found.
thanks much
return to acell
Getting back to my original confusion of acell. I have been trying to do an atomic optimization using optcell=0 and ionmov=2. When I supply the coordinates from TubeGen, there are 4 planes of atoms (2 ends and 2 in the middle). Since I have enlarged my acell in the x,y directions larger than my tube, when I visualize the converged geometry those 2planes of atoms in the middle have moved away from the tube, so my unit cell tube looks fat in the middle and 'normal' diameter on the ends. I have also tried optcell=9 which leaves the third vector(z-direction) unchanged, but I still get out a weird geometry. My guess is that any optimization will cause this weird fat tube if the unit cell is any larger than the tube itself. Do I need to then do a crystal (no space between tubes) for the atomic optimization, and then do a unit cell optimization seperately, fixing the atoms?