Error about runtime_parameters

[Anders Blom]

Wow, what a geometry! Beautiful 

It will not be easy to troubleshoot it, however...

[Anders Blom]

The problem is, as usual in these cases, the alignment atoms. It's clear that the system was built with VNL, but whether or not this indicates that the geometry produced by VNL is wrong or not is hard to say at this point... Perhaps you modified it by hand after it came out of the Atomic Manipulator? Anyway, by changing the equivalent atoms from

Code

equivalent_atoms=([0,0],[2,220])

to

Code

equivalent_atoms=([0,0],[2,195])

I hope you will be able to run the simulation. It will require a lot of memory, and may be difficult to converge, but at least I think the error you obtained should not appear any more. How did I find this out? It can be useful to know a bit more about how to troubleshoot a system like this... What I did was to convert the two-probe to its equivalent bulk system. Not by using the functionality in VNL, in the Atomic Manipulator, but by using the NanoLanguage function, which is a method on the two-probe configuration object. Viewing this in VNL clearly showed that the system was misaligned. After thinking a bit, and trying a lot of different things, what worked was 195 = 220-3*9+2, that is the alignment atom did not, somehow, account for the repetitions. (Here, 3 and 9 are the repetition factors, and 2 is the index for the electrode atoms, seen in the code above.)

[phylyh]

Thanks, but  the old geometry work well when I use  ElectrodeConstraints.RealSpaceDensity,  the following error come out when I re-calculate the system  using ElectrodeConstraints.Off  from the *.nc file generated by ElectrodeConstraints.RealSpaceDensity.

# Pulay mixing inversion failed. Using only last step.
# Pulay mixing inversion failed. Using only last step.
Traceback (most recent call last):
  File "Au_Z7_Au_1.py", line 502, in ?
    runtime_parameters = runtime_parameters
ATKError: inverse(DZMatrix const &) : Could not LU factorize!

[Nordland]

Hey phylyh.

I think Anders is right, the geometry of yours is not correct, and you shoud be very aware of the results you get from the calculations.

Best regards,
   Nordland.

[phylyh]

The same error  come again when I use unconstrained method(the RealSpaceDensity method works well)after  I change the geometry according to what Anders Blom said. 


# Pulay mixing inversion failed. Using only last step.
# Pulay mixing inversion failed. Using only last step.
Traceback (most recent call last):
  File "Au_Z7_Au_1.py", line 503, in ?
    runtime_parameters = runtime_parameters
ATKError: inverse(DZMatrix const &) : Could not LU factorize!



Should I tune the Pulay mixing parameter to fix the error?

[Anders Blom]

Does the error occur very soon in the calculation, or after many iterations?

[phylyh]

the error occur after many iterations

[Nordland]

Without having seen the log, I am pretty sure your charge has been oscillating rapidly prior to this error message
or else you have set the tolerance to 1e-18 and the calculation gets into numerical unstable troubles.

But my guess could be that it is rapid oscillating being the problem here, and therefore I would/could tune the iteration mixing parameters in order to try to avoid this issue. Alternative you could try using the constraint DensityMatrix instead Off.
I think the problem might be that at the egde of your central cell, atoms are perhaps not aligned perfectly, and this causes the electrons in the first layer of the electrode to expelled to deep inside the electrodes, and this breaks down the basic assumption of the algoritms.

When using the real space density constraint ( and the density matrix ) you are guaranteed that this will not happend, but you can try to increase the number of layers in the central region.....

[zdhlover]

What I did was to convert the two-probe to its equivalent bulk system. Not by using the functionality in VNL, in the Atomic Manipulator, but by using the NanoLanguage function, which is a method on the two-probe configuration object. Viewing this in VNL clearly showed that the system was misaligned. I am very interesting in how to realize the function that convert the two-probe to its equivalent bulk system by using the NanoLanguage function ? Could you teach me  the important trick?
 

 anyway,
Thanks a lot!

[Anders Blom]

Pardon the short answer, I hope it speaks for itself

Code

equiv_bulk = two_probe_configuration.equivalentBulkSystem()

http://quantumwise.com/documents/manuals/ATK-2008.10/ref.twoprobeconfiguration.html

[zdhlover]

Pardon the short answer, I hope it speaks for itself

Code

equiv_bulk = two_probe_configuration.equivalentBulkSystem()

http://quantumwise.com/documents/manuals/ATK-2008.10/ref.twoprobeconfiguration.html

I am sorry . I can modify the

Code

equiv_bulk = two_probe_configuration.equivalentBulkSystem()

but after that I didn't know how to modify the code that contralling the  disaplay of the configuration correctly

Code

if processIsMaster(): nlPrint(eqiva-bulk)
if processIsMaster(): file.addToSample(two_probe_configuration, 'Au_Z7_Au')

how could i do that can  display the wrong configuration  in the Nanocope?   

[Anders Blom]

Code

if processIsMaster(): file.addToSample(equiv_bulk, 'Au_Z7_Au equivalent bulk system')

[zdhlover]

I am so gormless that I try many ways but I dind't can export the wrong configuration  by using the NanoLanguage function .
I have modified the script in different ways , the Au_Z7_Au-equ1.py script displays the same configuration as the one that didn't modify,and the  Au_Z7_Au-equ2.py one displays some strange configuration .

How could I get the wrong configuration ,and  how I can  judge the configuration is wrong exept the stack fault?

Then ,I am so interested in the important trick ,could you help me ?

I am applogize to bother you so much.

any way
Thanks a lot for your enthusiastic reply

[Anders Blom]

The code should be a little bit different compared to what I wrote first:

Code

equiv_bulk = twoprobe_configuration.equivalentBulkSystem()
if processIsMaster(): nlPrint(equiv_bulk)
if processIsMaster(): file.addToSample(equiv_bulk, 'Au_Z7_Au equivalent bulk system')
if processIsMaster(): file.addToSample(twoprobe_configuration, 'Au_Z7_Au')

Sorry to confuse you (but I didn't have your original script, so it was hard to know the name of the variable). There should be no parameter inside the (), the commands should be exactly as above. When you have run the script, drop the VNL file on the Result Browser. Then you will see two configuration, and you can drop either one to the Nanoscope to see which is wrong etc.

[Tom]

The problem is, as usual in these cases, the alignment atoms. It's clear that the system was built with VNL, but whether or not this indicates that the geometry produced by VNL is wrong or not is hard to say at this point... Perhaps you modified it by hand after it came out of the Atomic Manipulator? Anyway, by changing the equivalent atoms from

Code

equivalent_atoms=([0,0],[2,220])

to

Code

equivalent_atoms=([0,0],[2,195])

I hope you will be able to run the simulation. It will require a lot of memory, and may be difficult to converge, but at least I think the error you obtained should not appear any more. How did I find this out? It can be useful to know a bit more about how to troubleshoot a system like this... What I did was to convert the two-probe to its equivalent bulk system. Not by using the functionality in VNL, in the Atomic Manipulator, but by using the NanoLanguage function, which is a method on the two-probe configuration object. Viewing this in VNL clearly showed that the system was misaligned. After thinking a bit, and trying a lot of different things, what worked was 195 = 220-3*9+2, that is the alignment atom did not, somehow, account for the repetitions. (Here, 3 and 9 are the repetition factors, and 2 is the index for the electrode atoms, seen in the code above.)

Hello  Anders Blom  When I calculate 2probe system ,I count the same question . Could you help me to inspect this script,thank you for your help.