A sulphur modification explode after optimization in GULP by pgfnff.
It is not a charged system = no ions, not the already discussed problem.
When optimized by DFT a large cut off must be used to descipbe week interaction.
Maybe similar option is missing in pgfn ff ?
Input data follows:
gfnff conp gwolf opti
vectors
10.46460000000000 0.00000000000000 0.00000000000000
0.00000000000000 12.86600000000000 0.00000000000000
0.00000000000000 0.00000000000000 24.48600000000000
spacegroup
F D D D
fractional
S 0.85584000000000 -0.04733000000000 -0.04854000000000
S 0.70733000000000 -0.02023000000000 0.00409000000000
S 0.78415000000000 0.03022000000000 0.07623000000000
S 0.78596000000000 -0.09232000000000 0.12947000000000
output cif FURHUV-out
The initial energy is a bit ugly, but I tried your input file with GULP-6.3 (latest version) and the optimisation converges. Attached below is the output file. s.got (20.3 KB)
I had upgraded my engine to GULP 6.3.3.
I had processed the input file by GULP 6.3.3 and I got totally identical output as Mr. Gale.
Unfortunate the final geometry is still incorrect. See following screenshots from Mercury:
It is far from the experimentaly determined structure (confirmed by my by geometry optimization in 3 different engines CASTEP (r2SCAn+MBD, Quantum Espresso(PBE+D3), ASE/MACE_OFF23L)
The CIF with incorrect geometry generated by GULP 6.3.3:
data_cif
_audit_creation_method ‘generated by GULP’
_symmetry_space_group_name_H-M 'F D D D ’
_symmetry_Int_Tables_number 70
_symmetry_cell_setting Orthorhombic
The short answer is that there was nothing wrong with GULP 6.2.3.
What you’re missing is that different optimisers can take different pathways from the initial state to the final one; i.e. there is no one single pathway that is the right one or the wrong one. What changed is that there were improvements to the optimiser in 6.3 related to checking the status of the Hessian and applying a shift if the curvature was wrong. So all you are seeing is that the new optimiser is more effective than the old one. However, there was nothing technically wrong with the old one.
It’s not clear what you’re talking about here since you mention final geometry. The geometry after optimisation depends on the model you optimise with & so you need to focus on this rather than the software, which just does what you’ve instructed it to do. It’s not surprising that QM methods (including ML that’s trained against QM) do better than a force field (unless this is specifically fitted to the system of interest). It would be a shame to use a computationally more expensive method to get a worse answer.
If you want a force field that is better then you just need to think about what physical interactions are important and how to construct a model that captures these for your structure of interest.
I talk abou pGN-FF generating for this specific structure in GULP a result wich have nothing to do with reality (see the short contact suplhurs). It is an exception from a few thausands of my test for witch pGN-FF give somehig giving sense with acceptable agreement with other methods. But this structure is a total outlier with final geometry converged to something not giving sense. There must be something specific (space group ?) why this structure does not work. I will try to recalc in P1.
The target of my work is to use GULP as pre-screening method for latge dataset experimental structures validation, before using more computationaly expensive methods.
Problem solved. We on our side detect the origin 2 setting from the CIF file, but we did not exported this to the GULP input. Adding
origin 2
gives correct output …
Maybe GULP should be able to read the CIF and symmetry directly (not to generate it from the non-sufficient symbol or SPG number) so the issues with space groups with multiple origins will be avoided.
