Messages

61

General Questions and Answers / optimization of magnetic tunneling junction

« on: April 26, 2016, 08:16 »

Dear all,

I searched all the forum of how to do the opimization of a magnetic tunneling junction. For the magnetic electrodes, there are usually two configurations to considered: (1) parallel configuration--P; (2)antiparallel configuration (AP).

So, as I guess, one should do the geometric optimization for P and AP configuration, respectively.

At the same time, the electronic convergence of a magnetic tunneling junction usually harder than a non-magnetic one.

Therefore, is there a feasible way to solve this? Or how does one usually do for this?

With best regards,

Guangping

62

General Questions and Answers / Re: Back Engine Exception : Diagonalization error

« on: April 24, 2016, 11:26 »

This error is in 99.99% of all cases caused by atoms overlapping. Besides, the other case is only for the extended Huckel model, not DFT. I have never seen a case where changing the interaction range is needed, or a good idea.

Dear Anders,

Thanks for your reminding.

With best regards,

Guangping

63

General Questions and Answers / Re: Back Engine Exception : Diagonalization error

« on: April 23, 2016, 17:05 »

Did you read the error message? A simple check in the Builder (using Select>Close Neighbors) shows that all (or most at least) the Cu atoms are duplicated, so you have - as the message suggests - atoms on top of each other.

Your advising function is useful. Ineed, when using move-fuse function, one sometime forget to click fuse, then there would be two atoms superposing and resulting this error.

By the way, in this thread http://quantumwise.com/forum/index.php?topic=1904.msg9335#msg9335, you suggest to increase the interaction max range,

So, I wonder if this error is not caused by two atoms too close but from the interaction max range, can you please tell the relationship between the interaction max range and the basis set oribtal range which we can see from the basis setting (the radial part).
If say, the max range value of basis set for all the atoms in the calcualtion is r1, we can safely set the interaction max range to be r2 > 2*r1 to eleminte this kind of error?

With best regards,

Guangping
With best regards,

Guangping

64

General Questions and Answers / Re: how can we set the "initial_scaled_spin" reasonably for our calculation.

« on: April 23, 2016, 15:14 »

You may consider the random setup of antiferromagnetic spin configuration.

Dear Zh,

I do not think a random setup is a good inital for antiferromagnetic or ferromagnetic. I do tests for a Ni(111) 5*5*3 super cell, and get a ferromagnetic configuration if I choose Nospin inital, while get a nonmagnatic configuration if I choose Random.

This indicates Nospin would possible give an energy lowest configuration, while one can not expect the results from a Random initial: maybe a ferromagnetic, antiferromagnetic, or nonmagnatic result. This will depend on what the "random" is. Also (I guess, because different random for differnt runs), differnet runs for the same input file using random initial would give different results. From this points, it is more useful for an antiferromagnetic calcualtion if there is an antiferromagnetic initial function. Of course, if the antiferromagnetic is not a stable configuration at all, then an antiferromagnetic, ferromagnetic or nonmagnatic would certainly do go to an antiferromagnetic results.

Please comment on my above understanding.

With best regards,

Guangping

65

General Questions and Answers / Re: how can we set the "initial_scaled_spin" reasonably for our calculation.

« on: April 22, 2016, 11:38 »

You may consider the random setup of antiferromagnetic spin configuration.

Thanks for your reply.

With best.

Guangping

66

General Questions and Answers / Re: how can we set the "initial_scaled_spin" reasonably for our calculation.

« on: April 22, 2016, 09:47 »

Dear all,

Is there a method to quick set the initial spin for a antiferromagnetic calculation if there are large number of atom in the unit cell? It is time consuming if one has to set the spin for each atom to have spin up and spin down alternately.

With best regards,

Guangping

67

General Questions and Answers / Re: Qestion on MPSH of two probe system

« on: April 22, 2016, 08:24 »

Dear Anders,

Thanks very much for your reply.

So, for my example, it is really hard to image that the C6H4S2 has 42 electrons because there is no such large electron numbers transfered from Au electrodes to the molecule. I have to think, there are 21 eigenenergy levels under Fermi level due to the shift of the eigenenergy levels arising from the interaction of molecule and Au electrode.

With best regards,

Guangping

68

General Questions and Answers / Re: Qestion on MPSH of two probe system

« on: April 22, 2016, 05:30 »

Dear Anders,

As I understand, to do MPSH, one just use the Hamilitonian subspace subject to the selection atoms. And directly diagionalized the subspace Hamilitonian obtaining the MPSH eigenvalues.

If as you have mentioned, two electrons have to be borrowed from the electrodes, then what the subspace Hamilitonian looks like? Or maybe the same subspace Hamilitonian is used as the above procedure. Just fill two extra electrons to the obtained MPSH eigenlevels. So, does this two electrons shift the Fermi level of the projecting atoms?

Ah, I find the

Code

Fermi level = -2.163589e+00 

which is lower than the hightes occupied energy level

Code

20  -1.869709e+00   2.000000e+00

Therefore, the LUMO and HOMO energy levels for C6H4S2 benzenethiolate in the two probe system is energy level  of index 20 (although its occupation is 2.0) and 19. That is to say, to dertermine which energy level in MPSH anaylsis is HOMO and LUMO, do not use the occupation number but the Fermi level.

Am I right?

Guangping

69

General Questions and Answers / Qestion on MPSH of two probe system

« on: April 21, 2016, 17:30 »

Dear all,

I now use MolecularEnergySpectrum class to do MPSH anaylsis in two probe system.

The system is a benchmark model that contains a C6H4S2 molecule. And the projection of MPSH analysis is to the bare molecule, that is, C6H4S2 (strictly speaking, it is not a molecule but a benzenethiolate). According to the manual http://www.quantumwise.com/documents/manuals/latest/ReferenceManual/index.html/chap.atomicdata.html#sect1.atomicdata.periodictable, there are 40 electrons (4*6+1*4+6*2=40) for this projection part. So, I would expect the HOMO orbital would has an index of 19 since ATK count from 0, and LUMO 20. But the MolecularEnergySpectrum reports that there are 42 electrons in the projection region.

Please refer to the attached input file for more details if possible. The output for molecular eigenstates are as follows.

Code

+----------------------------------------------------------+
+------------------------------------------------------------------------------+
| Molecular Energy Spectrum Report                                             |
| ---------------------------------------------------------------------------- |
| Fermi level = -2.163589e+00                                                  |
| Number of electrons = 42.000000                                              |
| Unit = eV                                                                    |
| Eigenenergies given relative to the Fermi Level                              |
+------------------------------------------------------------------------------+

    0  -1.799324e+01   2.000000e+00
    1  -1.650674e+01   2.000000e+00
    2  -1.487298e+01   2.000000e+00
    3  -1.480179e+01   2.000000e+00
    4  -1.295187e+01   2.000000e+00
    5  -1.146399e+01   2.000000e+00
    6  -1.065004e+01   2.000000e+00
    7  -9.021545e+00   2.000000e+00
    8  -7.843826e+00   2.000000e+00
    9  -7.693816e+00   2.000000e+00
   10  -6.878082e+00   2.000000e+00
   11  -6.599574e+00   2.000000e+00
   12  -5.959106e+00   2.000000e+00
   13  -5.247004e+00   2.000000e+00
   14  -4.881207e+00   2.000000e+00
   15  -4.745161e+00   2.000000e+00
   16  -3.415383e+00   2.000000e+00
   17  -3.410642e+00   2.000000e+00
   18  -3.266553e+00   2.000000e+00
   19  -2.651504e+00   2.000000e+00
   20  -1.869709e+00   2.000000e+00
   21   2.357217e+00   5.029450e-40
   22   2.567025e+00   1.502792e-43
   23   2.927772e+00   7.440152e-44
 ....
 ....

So, what is wrong?

With my best regards,

Guangping

70

General Questions and Answers / Re: Qestion about the two probe system optimization

« on: April 21, 2016, 11:23 »

Dear Umberto and Daniele,

So much thanks for your kind reply. They are of great help in clear my puzzles.

I have already read the total energy and forces in the manual
http://www.quantumwise.com/documents/manuals/latest/ReferenceManual/index.html/chap.negf.html#sect1.negf.totalEnergy

According to what the manual says, one can calcualtion the force under bias and do the geometry optimzation under a bias voltage for a two probe system?

How to consider the force from the current on atom?

With best regards,

Guangping

71

General Questions and Answers / Re: Clarification for the restart/restore or post analysis based on a converged *.nc

« on: April 20, 2016, 15:39 »

Just to clarify: force_restart=True does force the calculation to restart from scratch. But since you use the state from the checkpoint file as initial state, "from scratch" here means from that initial guess rather than from a superposition of atomic densities

Dear Jess,

Thanks for your reply. I understand the way to start a calculation using an initial guess. And I have tested it, it works.

Indeed, I tested using following script,

Code

device_configuration = nlread("checkpoint-0.4.nc")[0]
device_configuration.setCalculator(device_configuration.calculator(), initial_state=device_configuration)
device_configuration.update()
nlsave("Au-C6H4S2-Au-restart.nc", device_configuration)

So what is the difference here between using device_configuration.update() and device_configuration.update(force_restart=True), which is the question raised in 8th floor.

(2) And I am puzzling about the force_restart=True in device_configuration.update(), that is what is the difference between device_configuration.update() and device_configuration.update(force_restart=True) since they both trigger a calculation?

My test has shown that there is exactly not any difference between the following two calculations.

Code

device_configuration = nlread("checkpoint-0.4.nc")[0]
device_configuration.setCalculator(device_configuration.calculator(), initial_state=device_configuration)
device_configuration.update()
nlsave("Au-C6H4S2-Au-restart.nc", device_configuration)

and

Code

device_configuration = nlread("checkpoint-0.4.nc")[0]
device_configuration.setCalculator(device_configuration.calculator(), initial_state=device_configuration)
device_configuration.update(force_restart=True)
nlsave("Au-C6H4S2-Au-restart.nc", device_configuration)

With best regards,

Guangping

72

General Questions and Answers / Re: Clarification for the restart/restore or post analysis based on a converged *.nc

« on: April 20, 2016, 13:32 »

Dear Jess,

Thanks for your kind reply.

Please find the atttached the full *py input file. I just test the restart feature as I learnt from this tutorial http://www.quantumwise.com/publications/tutorials/item/502-restarting-stopped-calculations.
In this tutorial, it said that force_restart=True can be used to do the calculation from where it stoped not from the scratch.

As I have tested, if I use force_restart=True, I always to start the calculation from the scratch. And this is my puzzling.

So, there is something wrong in the tutorial, Right?

With best regards,

/Guangping

73

General Questions and Answers / Re: Clarification for the restart/restore or post analysis based on a converged *.nc

« on: April 20, 2016, 10:46 »

Dear Anders.

About the restart feature, I have been puzzled according to my test on this feature.
http://www.quantumwise.com/publications/tutorials/item/502-restarting-stopped-calculations
As the tutorial mentioned, I reivsed my script of input file to

Code

#----------------------------------------
# Device Calculator
#----------------------------------------
calculator = DeviceLCAOCalculator(
    basis_set=basis_set,
    exchange_correlation=exchange_correlation,
    numerical_accuracy_parameters=device_numerical_accuracy_parameters,
    iteration_control_parameters=device_iteration_control_parameters,
    contour_parameters=contour_parameters,
    electrode_calculators=
        [left_electrode_calculator, right_electrode_calculator],
    )

device_configuration.setCalculator(calculator)

device_configuration = nlread("checkpoint-0.4.nc")[0]

device_configuration.update(force_restart=True)

nlsave("Au-C6H4S2-Au-restart.nc", device_configuration)

transmission_spectrum = TransmissionSpectrum(
    configuration=device_configuration,
    energies=numpy.linspace(-2,2,100)*eV,
    kpoints=MonkhorstPackGrid(6,6),
    energy_zero_parameter=AverageFermiLevel,
    infinitesimal=1.36057e-05*eV,
    self_energy_calculator=RecursionSelfEnergy(),
    )
nlsave("Au-C6H4S2-Au-restart.nc", transmission_spectrum)
nlprint(transmission_spectrum)
transmission_spectrum.current()

The file checkpoint-0.4.nc is generated by CheckpointHandler in a previous run (and this job terminated normally, that is the SCF convergence has been done).
Here, whether I use a checkpoint *nc file or a *nc file generated by nlsave, the calculation always does from the scratch.

What wrong with my use of force_restart=True ?

In constrast, for the following script,

Code

#----------------------------------------
# Device Calculator
#----------------------------------------
calculator = DeviceLCAOCalculator(
    basis_set=basis_set,
    exchange_correlation=exchange_correlation,
    numerical_accuracy_parameters=device_numerical_accuracy_parameters,
    iteration_control_parameters=device_iteration_control_parameters,
    contour_parameters=contour_parameters,
    electrode_calculators=
        [left_electrode_calculator, right_electrode_calculator],
    )

device_configuration.setCalculator(calculator)

old_calculation = nlread("Au-C6H4S2-Au-0.4.nc", DeviceConfiguration)[0]

device_configuration.setCalculator(
    calculator(electrode_voltages=(0.2*Volt, -0.2*Volt)),
    initial_state=old_calculation,
)
device_configuration.update()

nlsave("Au-C6H4S2-Au-initial2.nc", device_configuration)

transmission_spectrum = TransmissionSpectrum(
    configuration=device_configuration,
    energies=numpy.linspace(-2,2,400)*eV,
    kpoints=MonkhorstPackGrid(6,6),
    energy_zero_parameter=AverageFermiLevel,
    infinitesimal=1.36057e-05*eV,
    self_energy_calculator=RecursionSelfEnergy(),
    )
nlsave("Au-C6H4S2-Au-initial2.nc", transmission_spectrum)
nlprint(transmission_spectrum)
transmission_spectrum.current()

The sentance

Code

old_calculation = nlread("Au-C6H4S2-Au-0.4.nc", DeviceConfiguration)[0]

also can be written as

Code

old_calculation = nlread("Au-C6H4S2-Au-0.4.nc")[0]

and Au-C6H4S2-Au-0.4.nc file can be either the one generated by CheckpointHandler or nlsave, the continue calculation is OK.

So, what is the story for the restart calculation by using force_restart=True? And what is the difference beween the *nc files generated by CheckpointHandler and nlsave for a continue scf calcualtion?

With best regards,

/Guangping

74

General Questions and Answers / Re: Bias loop question

« on: April 20, 2016, 07:38 »

Dear Anders,

Thanks for your reply.

I used TranSIESTA before, and I have to do the transmission spectrum and the current under each bias point. Now I have turned to ATK. And till now I never use ATK to do a current calculation. I just ask this question beacause the IVCurve() class do a implicit loop over bias and store the current in a *nc file. So, I think it would be sometime inconvenient to manipulate the data.

Now, I use the following script to do a tranmission spectrum and current calculation

Code

device_configuration.setCalculator(calculator)

device_configuration = nlread("Au-C6H4S2-Au.nc")[1]

Voltage = [0.0, 0.2, 0.4]*Volt

for bias in Voltage:
    calculator=calculator(
            electrode_voltages=(bias/2, -bias/2))

    device_configuration.setCalculator(
          calculator(),
          initial_state=device_configuration)
    device_configuration.update()
    nlsave("Au-C6H4S2-Au-%.1f.nc" % bias.inUnitsOf(Volt), device_configuration)

    transmission_spectrum = TransmissionSpectrum(
        configuration=device_configuration,
        energies=numpy.linspace(-2,2,400)*eV,
        kpoints=MonkhorstPackGrid(6,6),
        energy_zero_parameter=AverageFermiLevel,
        infinitesimal=1.36057e-05*eV,
        self_energy_calculator=RecursionSelfEnergy(),
        )
    nlsave("Au-C6H4S2-Au-%.1f.nc" % bias.inUnitsOf(Volt), transmission_spectrum)
    nlprint(transmission_spectrum)
    transmission_spectrum.current()

I think this would be very convenient.

Again, I have tested the Au-C6H4S2-Au-*.nc can be used to be the initial guess for the next bias step calculation, and also can be used to do a post analysis calcualtion, such as MPSH, Total Energy, DOS analysis.

With best regards,

/Guangping

75

General Questions and Answers / Re: Clarification for the restart/restore or post analysis based on a converged *.nc

« on: April 20, 2016, 03:34 »

Dear Anders,

Thanks very much for your kind reply.

For example the following script,

Code

old_calculation = nlread('Au-C6H4S2-Au-0.0.nc', DeviceConfiguration)[0]
device_configuration.setCalculator(
    calculator,
    initial_state=old_calculation,
)
device_configuration.update()
nlsave('Au-C6H4S2-Au-1.0.nc', device_configuration)
nlprint(device_configuration)

the Au-C6H4S2-Au-0.0.nc file read by nlread must be a checkpoint file generated by CheckpointHandler not written by nlsave?

And the sentance nlsave('Au-C6H4S2-Au-1.0.nc', device_configuration) above does not write the converged density matrix into Au-C6H4S2-Au-0.0.nc even if it follows the self-consistent scf calculation device_configuration.update() and can not used as an initial guess for another calculation ?

As I tested, it is not the above case, that is  Au-C6H4S2-Au-0.0.nc written by nlsave can be used as a checkpoint file to at least restart the same calculation. So in this case, it can also used as an initial guess for another calcualtion.

The test script is,

Code

#----------------------------------------
# Device Calculator
#----------------------------------------
calculator = DeviceLCAOCalculator(
    basis_set=basis_set,
    exchange_correlation=exchange_correlation,
    numerical_accuracy_parameters=device_numerical_accuracy_parameters,
    iteration_control_parameters=device_iteration_control_parameters,
    contour_parameters=contour_parameters,
    electrode_calculators=
        [left_electrode_calculator, right_electrode_calculator],
    )

device_configuration.setCalculator(calculator)

device_configuration = nlread("Au-C6H4S2-Au.nc")[1]

calculator=calculator(
        electrode_voltages=(0.0*Volt, 0.0*Volt))

device_configuration.setCalculator(
      calculator(),
      initial_state=device_configuration)
device_configuration.update()
nlsave("Au-C6H4S2-Au-0.0.nc", device_configuration)

Here, the device_configuration.update() only take 2 steps to converge since it based on an already converged *nc file Au-C6H4S2-Au.nc that is generated by nlsave as

Code

device_configuration.update()
nlsave('Au-C6H4S2-Au.nc', device_configuration)

From this test, I guess the *nc file generated by nlsave  can be used as an initial guess and a restart checkpoint for the new calculation.
 
With best regards,

Guangping