Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - Kaspar

Pages: [1] 2
1
Hi!

You can find the slides here http://quantumwise.com/download/webinars/2016-01-24-QuantumWiseWebinar-IntroductionToMolecularDynamics.pdf

and the webinar will be uploaded to QuantumWise's YouTube channel by the end of the month/beginning of Feb: https://www.youtube.com/user/QuantumWiseTV

2
I am trying to do a test of how large my unit cell has to be in the direction normal to the surface for the surfaces not to "see" each other when the periodic calculations are performed. In my calculations I also have a molecule some distance from the surface, so what I actually want to avoid is that the molecule sees the surface from the periodic image.

I got some (to me) curious results, which make me doubt my procedure.
I varied the normal direction vector (vector_c) between 20 and 38 A. When it is 20 A, there is only 2.35 A between the molecule and the periodic image, but when I am comparing the total energy of the system for different sizes of the unit cell, I get basically the same for all sizes of unit cell. I had expected a difference!
Is it possible that 2.35 A distance to the periodic image is far enough that they do not "see" each other?

The following is the output of the attached script. The last point did not converge in the standard 99 iterations, which is why the energy is different from the trend.

20 vector_c, energy = -26623.0088858
22 vector_c, energy = -26622.5073079
24 vector_c, energy = -26622.5012136
26 vector_c, energy = -26622.5004979
28 vector_c, energy = -26622.5001226
30 vector_c, energy = -26622.499761
32 vector_c, energy = -26622.4996665
34 vector_c, energy = -26622.4994036
36 vector_c, energy = -26622.499307
38 vector_c, energy = -26618.9210823

Did I misunderstand something about this type of convergence test or about how the calculation is actually performed?

Thank you for any comments.

3
Thanks for the pointer, I did not realize that the electrode discussion was relevant to bulk configurations.
So is it the same as the electrodes when doing devices -  that the length in c-direction should be at least 6A?

And is it material dependent for these bulk structures, or is it a general thing, that they should be longer than 6A ?
I'm asking because I'm also doing bulk Cu along the same directions - would they also need to be increased in c-direction?

And with regards to k-point spacing, I assume that I can use the one which I showed converged with respect to band gap for bulk Si (8x8x8), which in the longer cases would be something like (8x8x4) or similar.. , correct?

EDIT. Did the above for Si.
One more question: I get a transmission gap and DOS gap (band gap) now for all the directions as there should be, but I'm curious why the width of the gaps (both of them) is only ~0.7eV and not 1.3 as MGGA (which I'm using) usually estimates for Si band gap?

4
Sure, the script is below. The script was identical for the (110) surface, except, of course, for the different unit cell, and the k-points (which were 8 6 8 in that case)

Code
# Set up lattice
vector_a = [3.84001408591, 0.0, 0.0]*Angstrom
vector_b = [0.0, 3.84001408591, 0.0]*Angstrom
vector_c = [0.0, 0.0, 5.4306]*Angstrom
lattice = UnitCell(vector_a, vector_b, vector_c)

# Define elements
elements = [Silicon, Silicon, Silicon, Silicon]

# Define coordinates
fractional_coordinates = [[  5.00000000e-01,  -3.33066907e-16,   2.50000000e-01],
                          [  5.00000000e-01,   5.00000000e-01,   5.00000000e-01],
                          [ -1.11022302e-16,   5.00000000e-01,   7.50000000e-01],
                          [  2.22044605e-16,  -2.46519033e-32,   1.00000000e+00]]

# Set up configuration
bulk_configuration = BulkConfiguration(
    bravais_lattice=lattice,
    elements=elements,
    fractional_coordinates=fractional_coordinates
    )

#----------------------------------------
# Exchange-Correlation
#----------------------------------------
exchange_correlation = MGGA.TB09LDA

# -------------------------------------------------------------
# Calculator
# -------------------------------------------------------------
numerical_accuracy_parameters = NumericalAccuracyParameters(
    k_point_sampling=(8, 8, 6),
    )

calculator = LCAOCalculator(
    numerical_accuracy_parameters=numerical_accuracy_parameters,
    )

bulk_configuration.setCalculator(calculator)
nlprint(bulk_configuration)
bulk_configuration.update()
nlsave('analysis.nc', bulk_configuration)

# -------------------------------------------------------------
# Density of states
# -------------------------------------------------------------
density_of_states = DensityOfStates(
    configuration=bulk_configuration,
    kpoints=MonkhorstPackGrid(8,8,6),
    energy_zero_parameter=AbsoluteEnergy,
    bands_above_fermi_level=None,
    )
nlsave('analysis.nc', density_of_states)
nlprint(density_of_states)

# -------------------------------------------------------------
# Transmission spectrum
# -------------------------------------------------------------
transmission_spectrum = TransmissionSpectrum(
    configuration=bulk_configuration,
    energies=numpy.linspace(-5,5,501)*eV,
    kpoints=MonkhorstPackGrid(8,8),
    energy_zero_parameter=AbsoluteEnergy,
    infinitesimal=1e-06*eV,
    self_energy_calculator=RecursionSelfEnergy(),
    )
nlsave('analysis.nc', transmission_spectrum)
nlprint(transmission_spectrum)

# -------------------------------------------------------------
# Chemical potential
# -------------------------------------------------------------
chemical_potential = ChemicalPotential(bulk_configuration)
nlsave('analysis.nc', chemical_potential)
nlprint(chemical_potential)

# -------------------------------------------------------------
# Bandstructure
# -------------------------------------------------------------
bandstructure = Bandstructure(
    configuration=bulk_configuration,
    route=None,
    points_per_segment=20,
    bands_above_fermi_level=All
    )
nlsave('analysis.nc', bandstructure)


5
I am doing the simulation with 8,8,6 k-points. I did a convergence test on bulk Si which showed that 8,8,8 was fine, but since the unit cell in the (100) surface has a slightly longer c-vector, I use only 6 points in that direction.

The band gap is also only shown as 0.7 eV even though I use MGGA. I tried to do the calculation with very high k-point sampling (50,50,50), but that actually made the band gap estimate worse.
I forgot how the transmission looked in that case, and I deleted the files :(  Could it be a problem to use that many k-points?

The strange thing is that for the (110) direction, the same k-point sampling shows a clear DOS and Transmission gap. (though they are both 0.7 eV.. too small..)

6
Hi all,

I have done DOS and Transmission calculations on bulk Si in different directions (100) and (110). The results show that Si has a transmission gap and DOS gap for (110) as expected (though only 0.7 eV, even though I am using MGGA functional ??), but for (100) there is no transmission gap even though there is a DOS gap.
How can I have finite transmission for bulk Si for energies around the Fermi level?

7
Hi all,
I have a question regarding some transmission+DOS calculations I have done on a couple of different structures.

First, I am working with a Cu/Si interface. Deep inside the Si, there should naturally be a band gap. As far as my intuition goes, that should create a transmission gap in the whole structure because states in that energy range in the Cu cannot propagate once they reach the Si, correct?
The transmission gap is significantly smaller than the bulk Si band gap, but I guess that it is because of the systematic error with DFT calculations and band gaps.

Nevertheless I see a finite DOS for all energies. I am guessing that this is because of induced states from the Cu (metal induced gap states) that reach several atomic layers into the Si part. So the DOS is calculated by adding up all states in the whole structure for each energy, but because there is bulk Si in the structure, some states will not propagate because of the band gap. Any thoughts?

Now a more serious problem. I also calculate transmission+DOS for Bulk Si along different directions.
I do see a band gap, but no transmission gap ! How can that be possible? I can see how some states would not conduct, but not how I can have transmission without states. Especially for bulk Si where there should definitely be a band gap and transmission gap?

Thanks for any thoughts!

8
I just thought, that probably the spin is what makes the difference, although it doesn't say in the log file that it is specifically for spin up or down.

9
I have read the post about using 25, 50 or even 100 k-points in the z-direction when doing transmission and DOS calculations on devices.
But what about when doing calculations on a bulk structure?

I am calculating DOS and Transmission on Si for different surfaces (100, 110, and 111) for simple unit cells.
I want to compare this with the DOS and transmission for a block of silicon with one dopant in (Eg. 100 Si atoms with one B or P atom)

I have done a convergence test on a bulk Si unit cell which showed that 8,8,8 k-points was fine. Now since the unit cell of the cleaved structures is not cubic but eg. 3.8 x 3.8 x 5.3, I use 8x8x6 k-points. (please tell me if this is wrong)
For the block of Si with a dopant in, the dimensions are 7.7 x 7.7 x 27, so I believe that I could use 4x4x2 and have same resolution.
(By mistake I actually used 8x8x6 also for the block calculations, but I don't think results could be wrong, right? I showed convergence already at 8x8x8 for the unit cell and this is higher resolution)

The question is that, the DOS plot for the undoped unit cell, cleaved in any surface orientation, looks way less detailed, and the band gap is severely off ( ~ 0.7 eV band gap) even though I use MGGA. There are some peaks spaced 1.3 eV apart around Ef, which makes me  believe that they are the real band edges.
Do I need 25 - 100 k-points in the c ( or z ) direction also for bulk/unit cell calculations?

10
Hi all,

Because I use gnuplot to plot my DOS and transmission plots, I use the log file to access these quantities automatically with a bash script. I therefore almost never use the VNL plotting tool where the .nc file is used. Just now, however, I noticed that the DOS plotted by the VNL plotter is exactly twice the values reported in the log file. The shape is exactly the same, only all values are twice as high plotted from the .nc file.

Is this well known? If so, what is the reason, and which one is right?

11
Hi all,

I was wondering if someone could tell me what the default exchange_correlation is? When I look at this page http://www.quantumwise.com/documents/manuals/latest/ReferenceManual/index.html/ref.exchangecorrelation.html is looks like an XC must be specified, but I noticed (by coincidence!) that in some of my scripts, no exchange_correlation is explicitly set in the .py script.

When I go to the Scripter, I can see that LDA is the one that is selected by default, and if I change that to eg. MGGA, then the appropriate line shows up in the .py script. Does this mean that LDA is the default XC when nothing is specified ?

Thank you for any thoughts.

12
That sounds like it could have been what happened. It just stopped doing anything, no error messages or anything. Usually I get an error message if I run out of licenses, stating exactly that, but not this time.

I haven't seen the command '-npernode=M' before, I should check it out. I was looking for a way to do more than one process per node while still having multiple nodes.

If anyone is interested, I recently compiled a guide on PBS divided into basic and advanced topics. It contains topics like running jobs depending on each other and running array jobs, for example, something most people don't learn.
Its freely available here (basic) https://nanohub.org/resources/7496 and (advanced) https://nanohub.org/resources/7498

13
Thanks for your reply.

I have an idea about what it could be, maybe you can confirm if this can be the reason.
Could it be that the max number of simultaneous calculations for my research group's license was reached? Normally the simulation is killed with an error message in that case, but could this behavior be related?
The reason I am suspecting this is that I tried to start a new calculation at the same time, which gave me the license error. Adding to the suspicion is that the script later ran fine, probably when new simulation slots were freed up.


About the running parameters, I always use the PBS flag
Code
#PBS -n -l nodes=M

where M is the number of nodes I request, and then I run the job with
Code
mpiexec -np M

For those not familiar with this option, it asks for M nodes which then run with 1 mpi process per node, and exclusive acces to the whole node.

14
Hello again,

I just wanted to tell that it was indeed the MPICH2 that solved my problem.
The simulations are running in parallel now scaling very well with the number of nodes that I have tried (up to 8 nodes). And the output is printed to the log file just once, as it should.

Thank you for your help !

15
Hi all,

I am having a strange problem with a series of calculations I am doing.
I have a couple of different systems for which I only vary a few things in the geometry between each simulation. I have not had any problems, but suddenly this one simulation freezes just after the message (in the log file)
Code
 Left Electrode Calculation [Started .... 2013] 

I have looked very carefully and compared with it's "sister" calculations but I can see nothing that should cause this. The geometry is essentially identical (except for the variations that I am investigating in the first place) and all the calculators are set up identically. But I guess it doesn't even make it to the calculator part.
When I compare with the successful calculations, the next line in the log file should output
 
Code
Checkpoint Handler
Filename : ...... .nc
Interval : ... h
and then begin with calculating eigenvalues.

Also, it does not give any errors, it just stops there. I have tried to restart it with the same result.

I can supply the log file and .py script if necessary.
I am using 12.8.2, running in parallel on 8 nodes. But again, that too is the same for all the successfully running calculations.


Thank you for any suggestions/ideas

Best regards, Kaspar

Pages: [1] 2