Author Topic: geometry optimization as device leads to unreasonable results  (Read 3645 times)

0 Members and 1 Guest are viewing this topic.

Offline baizq

  • QuantumATK Guru
  • ****
  • Posts: 100
  • Country: us
  • Reputation: 3
    • View Profile
Dear colleagues,

Recently I am conducting geometry relaxation of CoFe-MgO-CoFe (Fe-O interface) MTJ when encoutered a problem: when the MTJ is relaxed as device with constraint on c-axis of the cell removed, the result seems unreasonable. The interfacial Fe-O distance, which is set to be 2.23 A as initial value, keeps increasing to more than 3.7 A. Convergence is also hard to reach so I have no choice but to stop it.

I would like to know whether it is due to my inappropriate parameter settings. 

Attached is the script for geometry relaxation. I cannot attach the trajectory.nc file due to attachment size limitation.

Thanks!

baizq


Offline kstokbro

  • Supreme QuantumATK Wizard
  • *****
  • Posts: 392
  • Reputation: 13
    • View Profile
    • QuantumWise
Re: geometry optimization as device leads to unreasonable results
« Reply #1 on: September 28, 2011, 06:58 »
could you also attach the log file, this will speed up our handling of this case

Offline Anders Blom

  • QuantumATK Staff
  • Supreme QuantumATK Wizard
  • *****
  • Posts: 5411
  • Country: dk
  • Reputation: 89
    • View Profile
    • QuantumATK at Synopsys
Re: geometry optimization as device leads to unreasonable results
« Reply #2 on: September 28, 2011, 09:28 »
You may want to try to relax it using the NonSelfConsistent option (set under Iteration Control Parameters in the Scripter). It actually runs a self-consistent equivalent bulk relaxation of the device. Sometimes, in device mode, if the atoms move too far in one step, the algorithm can become unstable. The relaxed geometry obtained from the equivalent bulk should be ok, or at least a better starting guess for the relaxation under open boundary conditions.

Offline baizq

  • QuantumATK Guru
  • ****
  • Posts: 100
  • Country: us
  • Reputation: 3
    • View Profile
Re: geometry optimization as device leads to unreasonable results
« Reply #3 on: September 28, 2011, 10:57 »
could you also attach the log file, this will speed up our handling of this case

Hi kstokbro,

I have tried to attach the log file, but the one I got is as large as 8 Mb which far exceeds the limitation....

The program runs for 117 iterations but the force and stress still can not reach to convergence.


baizq

Offline Anders Blom

  • QuantumATK Staff
  • Supreme QuantumATK Wizard
  • *****
  • Posts: 5411
  • Country: dk
  • Reputation: 89
    • View Profile
    • QuantumATK at Synopsys
Re: geometry optimization as device leads to unreasonable results
« Reply #4 on: September 28, 2011, 10:58 »
If you compress (zip, gz, bzip2, rar, whichever you prefer) the log file, it probably fits the limit. Otherwise email it to us (still compressed!).

Offline Anders Blom

  • QuantumATK Staff
  • Supreme QuantumATK Wizard
  • *****
  • Posts: 5411
  • Country: dk
  • Reputation: 89
    • View Profile
    • QuantumATK at Synopsys
Re: geometry optimization as device leads to unreasonable results
« Reply #5 on: September 29, 2011, 13:05 »
Having seen the log file, it seems the problem is just that you have a slightly (very slightly, however!) unrealistic expectation of how far you can converge the strain. To reach very low strain like 0.004 eV/Ang**3 is in general very difficult, and requires careful tuning of the tolerance of the scf loop, and perhaps also of the force tolerance.

However, if you read the log file you can see that at some point you have a strain of 0.004797 eV/Ang**3! So, by setting your tolerance to just 0.005 eV/Ang**3 instead, you would be perfectly ok!

I do have some additional comments. You electrode, and the FeCo layers in the central region, are very short. I would increase to at least 6 layers (instead of 4) in the electrode, and perhaps have 8 in the central region. This will of course increase the calculation time somewhat, but I cannot guarantee that your calculations are not inaccurate with the current setup, the results may become wrong.

(I post this here, on the Forum, as well as by email to you, in case someone else has similar problems, and finds these comments useful.)