aplowman / castep-parse

Input file writers and output file readers for the density functional theory code CASTEP.
Mozilla Public License 2.0
7 stars 4 forks source link

Support parsing DFPT results from the castep file #2

Open amundmr opened 3 years ago

amundmr commented 3 years ago

https://github.com/aplowman/castep-parse/blob/678e9770c3e84f6e6f6d0e87c394124b39c6cbc4/castep_parse/readers.py#L862

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

@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 commented 3 years ago

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:

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