Li-Al-O potential

anr418 · October 7, 2021, 10:52pm

Hello,
I am using GULP to create a lammps useable potential for Li-Al-O system.

I started with making the LiAlO.gin file where I put in the Buckingham parameters for 5 out of the 6 interactions Li-O, Al-O, O-O, Li-Li and Al-Al parameters. I collected these parameters from 3 different papers. I do not currently have the Li-Al Buckingham parameters.

I used the “output lammps” and “output lammps_pot” command to produce the tabulation of 2 body potential. My input looks like this

opti conp comp

Created by GDIS version 0.90.0

name LiAlO2_Crystal_Str

cell
5.168700 5.168700 6.267900 90.000000 90.000000 90.000000
cartesian
Li core 4.200086 4.200086 0.000000 1.0000000
Al core 0.909174 0.909174 0.000000 1.0000000
O core 1.741335 1.502024 4.840699 1.0000000
O shell 1.741335 1.502024 4.840699 1.0000000
space
P 41 21 2
species
Li core 1.00
Al core 3.00
O core 0.800
O shel -2.800
buckingham
Li core O shel 632.1018 0.2906 0.0 0.0 12.0

buckingham
O shel O shel 12420.5 0.2215 29.07 0.0 25.0

buckingham
Li core Li core 120.2 0.285710 0.16

buckingham
Al core Al core 0 0.1 0.0

buckingham
Al core O shel 1109.92381 0.31540 0.0 0.0 10.0

spring
O 31.0

output lammps_pots
dump every LiAlO2.grs
~

The error that I get is

At line 827 of file …/outlammps.F90 (unit = 27, file = ‘fort.27’)
Fortran runtime error: Expected INTEGER for item 7 in formatted transfer, got REAL
('pair_coeff ‘,i3,1x,i3,’ buck/mdf ',f12.10,1x,f13.10,1x,f8.4,1x,f8.4)
^

Error termination. Backtrace:
#0 0x7f6fd49f41aa
#1 0x7f6fd49f4d19
#2 0x7f6fd49f5521
#3 0x7f6fd4bee511
#4 0x7f6fd4bfae6f
#5 0x7f6fd4bfdd50
#6 0x7f6fd4bfe184
#7 0xc0788e
#8 0xbf2e06
#9 0x88b3d3
#10 0x137b404
#11 0x401b7a
#12 0x7f6fd3e5a7b2
#13 0x401bbd
#14 0xffffffffffffffff

The files being created are fort.25 fort.26 and fort.27

My questions are:

Which part of the output can I use in lammps?
The fort.25 file contains only 0 values and looks like

Buckingham_Li_O
N 1001 R 0.00000 0.00000

     1       0.000000000           0.000000000          -0.000000000
     2       0.000000000           0.000000000          -0.000000000
     3       0.000000000           0.000000000          -0.000000000
     4       0.000000000           0.000000000          -0.000000000
     5       0.000000000           0.000000000          -0.000000000
     6       0.000000000           0.000000000          -0.000000000

.
.
.
.
.
.with 1000 rows for each type of interaction (Li-O, Al-O , etc ). I am sure this is not correct so how to correct this?

Is the Li-Al interaction available in any of the libraries provided in GULP. If so kindly suggest how to correctly build a potential of Li-Al-O system.

I really appreciate your response to my last query where you suggested me to use output lammps command. Your advice on this occasion will prove to be very helpful.

Sincerely,
Ankit Roy
Lehigh University

julian · October 8, 2021, 12:19am

Here are the key points:

The error is bug & so I’ll fix the format of the write statement - thanks for spotting this.
For an ionic, formal charged Born-style model then there will be no Li-Al potential. The electrostatics are already too repulsive and there is negligible dispersion between Li+ and Al3+.
The reason there are large numbers of lines for each potential is because this is a spline tabulation.
Given this is such a simple potential model with only a handful of parameters, it’s far more efficient just to cut and paste these values into your LAMMPS input file than to generate via an intermediate piece of software.

anr418 · October 10, 2021, 7:57pm

Hello Dr. Gale,
Thank you for the valuable inputs in your last email.

So the reason I want to use GULP is to optimise the buckingham parameters by using the lattice constants for the LiAlO2 system that I have provided in the input. I have taken the Buckingham parameters from 3 different papers for Li-Al-O and I would like to get them optimised using gulp for the LiAlO2 system. All 6 possible interactions (Li-Li, Li-Al, Li-O, Al-O, O-O and Al-Al) have been defined in the input. Kindly take a look at the input below.

opti conp comp

Created by GDIS version 0.90.0 name LiAlO2_Crystal_Str

cell
5.168700 5.168700 6.267900 90.000000 90.000000 90.000000
cartesian
Li core 4.200086 4.200086 0.000000 1.0000000
Al core 0.909174 0.909174 0.000000 1.0000000
O core 1.741335 1.502024 4.840699 1.0000000
O shell 1.741335 1.502024 4.840699 1.0000000
space
P 41 21 2
species
Li core 1.00
Al core 3.00
O core 0.800
O shel -2.800
buckingham
Li core O shel 632.1018 0.2906 0.0 0.0 12.0

buckingham
O shel O shel 12420.5 0.2215 29.07 0.0 25.0

buckingham
Li core Li core 120.2 0.285710 0.16

buckingham
Al core Al core 0 0.1 0.0

buckingham
Al core Li core 0 0.1 0.0 buckingham
Al core O shel 1109.92381 0.31540 0.0 0.0 10.0
spring
O 31.0

output lammps_pots
dump every LiAlO2.grs
~

I have gone through several of the examples in the manual and I thought example 10 (optimisation of urea showing how to handle interatomic potentials) was the closest to my objective. But the output file is not changing any of the Buckingham parameters that I provided in the input. Therefore I request you to kindly tell me how to correct the input file so as to obtain an optimised value of the Buckingham parameters. It will also be helpful if you could suggest which example in the manual is the closest to what my objective is.

julian · October 10, 2021, 11:26pm

I’d strongly advise you read the manual/GULP papers carefully or discuss with your supervisor to become more familiar with things. The key point here is that optimisation will never change the potential parameters since it optimises the structure for a fixed force field model. You need to read the literature on “fitting”…

anr418 · October 13, 2021, 4:29am

Thanks Dr. Gale. I read about fitting from the manual and I tried to use it on the Li-Al-O2 system using the elastic constants. The example 14 in the GULP directory was helpful. However the error that I am facing says " Largest core-shell distance exceeds cutoff of cuts" my input looks like as shown below. I tried to overcome the error by explicitly specifying the cutoff as “cuts 25” but that didn’t work either.

fit conp relax

stepmax opt 1.0

cell
5.168700 5.168700 6.267900 90.000000 90.000000 90.000000
cartesian
Li core 4.200086 4.200086 0.000000 1.0000000
Al core 0.909174 0.909174 0.000000 1.0000000
O core 1.741335 1.502024 4.840699 1.0000000
O shell 1.741335 1.502024 4.840699 1.0000000
space
P 41 21 2

species
Li core 1.00
Al core 3.00
O core 0.800
O shel -2.800

observables
elastic
1 1 143
elastic
3 3 167
elastic
4 4 60
elastic
6 6 61

buckingham
Li core O shel 632.1018 0.2906 0.0 0.0 12.0 1 0 0

cuts 25

buckingham
O shel O shel 12420.5 0.2215 29.07 0.0 25.0 0 0 0

cuts 25

buckingham
Al core O shel 1109.92381 0.31540 0.0 0.0 10.0 0 0 0

cuts 25

buckingham
Li core Li core 120.2 0.285710 0.16 1 0 0

buckingham
Al core Al core 0 0.1 0.0 1 0 0

buckingham
Al core Li core 0 0.1 0.0 1 0 0

#spring
#O 31.0

dump example14.grs

Also, if I try to use the spring O 31 command, the program meets and error saying “Incorrect potential coefficient input” without running even a single cycle.
I request you to kindly provide me some suggestions on how to circumvent these errors.

julian · October 13, 2021, 5:53am

Several important points here:

cuts is a global quantity so no need to specify multiple times
A value of cuts of 25 Ang would imply a core-shell separation of up to 25 Ang - does this seem like a sensible size for an atom?
If you don’t have a spring constant then cores and shells separating is exactly what you would expect, since there is nothing to hold them together, so I’m not sure why you are surprised by the error?

The important thing is to not to comment out the spring constant, but correct your input by checking the help text to see what you’ve forgotten in your input……