Geometry optimisation
Status: Beta
Brought to you by:
exciting
Menu
▾
▴
Hello
I'm trying to do a structure optimisation (task 2). I was wondering where the forces for the the atoms can be found after an scf. Also is there any way of finding out which part of the scf is curently being performed.
Thank you
Michael
The forces are reported in INFO.OUT at the end of each self-consistent cycle. The mean absolute value of the forces are written to MAFORCE.OUT and the current atomic positions to GEOMETRY.OUT. (Forces are not calculated after each s.c. cycle because the IBS correction takes a long time to compute.)
Now that you mention it, it would be nice to have forces written to a separate file (FORCES.OUT) - I'll put this in the next release, along with a counter indicating the number of atomic steps.
Regards,
Kay.
The code ran through 1 complete scf cycle. After which it started over. However, the MAFORCE.OUT file is still empty and the positions contained in the GEOMETRY.OUT file are the same as those contained in the exciting.in file. I enclose my input file as I believe that it is far more likelt that I'm doing something wrong than the code is.
-----
tasks
1
2
spinpol
.false.
spinorb
.false.
autokpt
.true.
xctype
20
rgkmax
3
avec
6.0018029412 -3.4651425436 0.0000000000
0.0000000000 6.9302850872 0.0000000000
0.0000000000 0.0000000000 42.6310753938
scale
1.889716165
nempty
50
dos
1000 150
-0.5 2.0
lmaxapw
10
lmaxvr
8
gmaxvr
14.0
sppath
'/usr/local/exciting/exciting/species/'
autormt
.true.
atoms
3 : nspecies
'H.in' : spfname
3 : natoms
0.33264049 0.66704400 0.98420715 0.0 0.0 0.0
0.66663483 0.33307070 0.98444451 0.0 0.0 0.0
0.00062660 0.00101872 0.98461015 0.0 0.0 0.0
'Li.in' : spfname
3 : natoms
0.58619990 0.01624190 0.38618918 0.0 0.0 0.0
0.01517725 0.58800696 0.38611974 0.0 0.0 0.0
0.44519599 0.44751105 0.39743884 0.0 0.0 0.0
'Ge.in' : spfname
45 : natoms
0.00047380 0.00078689 0.77154130 0.0 0.0 0.0
0.00697671 0.00798678 0.54086019 0.0 0.0 0.0
0.33364190 0.66735274 0.77116938 0.0 0.0 0.0
0.34048609 0.67457109 0.53467022 0.0 0.0 0.0
0.66717558 0.33404503 0.77112090 0.0 0.0 0.0
0.67388977 0.34148398 0.53451477 0.0 0.0 0.0
0.33314929 0.66697690 0.94577690 0.0 0.0 0.0
0.33442344 0.66820274 0.71287703 0.0 0.0 0.0
0.34396882 0.67827024 0.47580507 0.0 0.0 0.0
0.66672389 0.33361149 0.94648140 0.0 0.0 0.0
0.66797690 0.33492212 0.71293062 0.0 0.0 0.0
0.67722075 0.34544657 0.47590471 0.0 0.0 0.0
0.33325785 0.00077207 0.92780871 0.0 0.0 0.0
0.33378322 0.00188626 0.69286681 0.0 0.0 0.0
0.32821628 0.01175608 0.45815345 0.0 0.0 0.0
0.66759866 0.66749221 0.92781823 0.0 0.0 0.0
0.66906636 0.66942502 0.69298963 0.0 0.0 0.0
0.69603119 0.69726004 0.45821405 0.0 0.0 0.0
0.99986204 0.33330899 0.92781085 0.0 0.0 0.0
0.00126714 0.33393116 0.69290587 0.0 0.0 0.0
0.01021064 0.32848954 0.45806192 0.0 0.0 0.0
0.33310690 0.00038153 0.86980796 0.0 0.0 0.0
0.33442298 0.00377463 0.63477275 0.0 0.0 0.0
0.22799418 0.01333603 0.40110787 0.0 0.0 0.0
0.66692078 0.66721676 0.86986033 0.0 0.0 0.0
0.67211830 0.67258148 0.63481959 0.0 0.0 0.0
0.80327960 0.80436899 0.40072814 0.0 0.0 0.0
0.99993606 0.33340174 0.86980845 0.0 0.0 0.0
0.00309249 0.33486398 0.63472947 0.0 0.0 0.0
0.01154232 0.22904823 0.40094717 0.0 0.0 0.0
0.00005213 0.66681903 0.84972227 0.0 0.0 0.0
0.00337271 0.66745527 0.61472947 0.0 0.0 0.0
0.66647009 0.00038756 0.84971912 0.0 0.0 0.0
0.66668520 0.00368747 0.61472540 0.0 0.0 0.0
0.33364734 0.33399602 0.84971779 0.0 0.0 0.0
0.34002547 0.34059836 0.61474991 0.0 0.0 0.0
0.00035872 0.66695391 0.79151189 0.0 0.0 0.0
0.00716316 0.66799089 0.55659022 0.0 0.0 0.0
0.66653437 0.00044636 0.79150802 0.0 0.0 0.0
0.66679765 0.00766204 0.55659009 0.0 0.0 0.0
0.33407441 0.33444220 0.79150462 0.0 0.0 0.0
0.34682394 0.34776980 0.55661428 0.0 0.0 0.0
0.01152601 0.01329788 0.48418182 0.0 0.0 0.0
0.00130100 0.00168338 0.71337136 0.0 0.0 0.0
0.00019894 0.00051975 0.94667132 0.0 0.0 0.0
!ngridk
! 4 4 1
vkloff
0.25 0.25 0.75
plot1d
3 200 : nvp1d, npp1d
0.5 0.0 1.0 : vlvp1d
0.0 0.0 1.0
0.5 0.5 1.0
-----
I know that some of the latter stuff in the in file is not needed, but I guessed that it would be ignored if the task was not activated.
On another issue. I've compiled the code with the mkl libs from intel. However, threading over 2 processors (well two cores) does not seem to work. Has it been turned off. Also will k-point paralisation be implemented in the near future (only thing stopping me from running this on the pc cluster at the moment). Otherwise I must admit that I really do like the code and am looking forward to comparing the results to Wien2k
Michael
You just need to set
tasks
2
Geometry optimisation always starts from scratch. The updated atomic positions are written to GEOMETRY.OUT.
Did you compile with the OpenMP option? If you do, then the k-points will be distributed over processors, although this doesn't work on a cluster (there are some attempts to create virtual multiprocessor machines from clusters though). MPI is not implimented in the code. I think I'll switch all parallelisation to co-arrays when they are widely available in Fortran 2005, then multi-processors and clusters will be treated in the same way.
Let me know how the structural optimisation goes.
Kay.
Do the new positions get ammended to GEOMETRY.OUT or are the original positions simply written over. Also Is there anyway of seeing how the converged total energy is decreasing with changing geometry (if not this would be nice to have). My suggestion (which is largely based on Wien2k use), is that it is handy to be able to see changes in forces, total energy, and positions during a geometry optimisation. Also, I looked in the MAFORCE.OUT file, but this does not appear to be ascii, is this possibly a bug or has something gone wrong with my calculation.
Finally, you wrote "Geometry optimisation always starts from scratch". Does that mean that if I perform a clean stop at scf 40, all information is lost and that I'm back to square 1 again if I restart the optimisation. Does that entail that one needs to take the GEOMETRY.OUT data and paste that into the exciting.in file also?
Looking forward to hearing you
Michael
GEOMETRY.OUT is written over. As you say, you should finally take the data in GEOMETRY.OUT and paste it in to exciting.in.
You can monitor the change in energy w.r.t. geometry by plotting TOTENERGY.OUT. The same goes for MAFORCE.OUT (which should be ASCII, b.t.w.), although this is updated only after every atomic step.
Kay.
First SCF cycle has completed (55 cycles). However, the INFO file was last written to 6 hours ago. What part of the code is now running (its taking about 1.7 Gb of ram). MAFORCE has not been written to yet so I'm guessing that it could be forces.
There could probably be more information being pumped out by the program in regards to what is going on at the time. Also, the fact that (if I understood you correctly) one cannot stop during an scf without have to start from scratch is a large problem as I've noticed on my sytem atleast that each individual SCF almost double in execution time after about 30 cycles due to gam-server taking a large amount of processor time .
Michael
The IBS correction to the forces takes a long time to compute. I'll try and speed this up a bit. Also in the next version (0.9.52) I'll include the option to restart the geometry optimisation calculation from a previous density, and include the ability to switch off the IBS calculation (currently, of course, you can restart a ordinary ground state calculation with tasks=1).
Cheers, Kay.