Support parsing DFPT results from the castep file

[amundmr]

castep-parse/castep_parse/readers.py

Line 862 in 678e977

if 'CASTEP version' in line:

It seems that if the version finding fails, the whole reader fails. This is because unless the version is found, no "version" variable is made, so the next if statement fails.

Can this be avoided by using an else statement and setting the version to nan?

Traceback (most recent call last):
File ".\importer.py", line 95, in
data = cp.readers.read_castep_file(fn1)
File "c:\users\amund\documents\megasync\prosjekter\castep-parse\castep_parse\utils.py", line 391, in decorated
return func(lines, *args, **kwargs)
File "c:\users\amund\documents\megasync\prosjekter\castep-parse\castep_parse\readers.py", line 64, in read_castep_file
run = parse_castep_run(run_str, run_idx)
File "c:\users\amund\documents\megasync\prosjekter\castep-parse\castep_parse\readers.py", line 703, in parse_castep_run
header = parse_castep_file_header(header_str)
File "c:\users\amund\documents\megasync\prosjekter\castep-parse\castep_parse\readers.py", line 866, in parse_castep_file_header
if not version:
UnboundLocalError: local variable 'version' referenced before assignment

[amundmr]

It seems that the reason this fails is that my .castep file looks a little different, and that it reads in this as the header in stead of the actual header that comes before it:

+-------------------------------------------------+
| |
| D D D D F F F F F P P P P T T T T T |
| D D F P P T |
| D D F F F F P P P P T |
| D D F P T |
| D D D D F P T |
| |
+-------------------------------------------------+
| |
| Welcome to Castep Linear Response (DFPT) |
| |
| Copyright (c) 2006 - 2010 |
| |
| Please cite the following publications in all |
| work arising from your use of CASTEP LR. |
| |
| K. Refson, S. J. Clark and P. R. Tulip |
| Variational density functional perturbation |
| theory for dielectrics and lattice dynamics |
| Phys. Rev. B 73(15), 155114 (2006) |
+-------------------------------------------------+

However, the regular "CASTEP" box does come right before it. Would you need my castep file to troubleshoot this?

[aplowman]

Hi @amundmr, I haven't run any DFPT simulations before, which is why castep-parse is having issues. Happy to see what we would need to do to fix this though, if you could share your .castep file (change the extension to .txt and you should be able to drag and drop the file into a reply).

[amundmr]

Hello, thanks for the reply! I haven't had time to look through the code enough to make a PR, if you know how to solve this, it would be fantastic! My castep file is below. (Thanks for the suggestion on the .txt and drag and drop!)

ZrO2_cubic_Efield.txt

Best regards,
Amund.

[amundmr]

Hi again @aplowman. I've been looking in to it, and I am having some trouble understanding exactly what you are doing with the runs concept, but I believe that we can make some sort of fix in there where you are checking out the header.

Best regards,
Amund

[aplowman]

@amundmr, the idea behind "runs" is that multiple runs of Castep may output to the same .castep file, for instance when continuing a simulation from a checkpoint. I can see how to fix the version/header issue. However, what information would you like to be parsed from the file? Currently, none of the results from the DFPT will be parsed, because I only used castep-parse for single point and geometry optimisation simulations.

[amundmr]

Alright. Sorry, I think it has become obvious that I am not all that familiar with .castep files. I have actually not generated these files myself. The data I am looking to read is as follows:

• species
• unit cell
• lattice parameters
• coordinates of elements
• point group
• which modes are raman active (and at which frequencies)
• which modes are IR active (and at which frequencies)
• Optical and DC permittivity
• optical and static polarisability
• born effective charge for all elements

To be honest I am not sure if any of these are specific to the DFPT simulation.