CONTCAR copied from previous directory gets overwritten

[qianchenqc]

Currently when a CONTCAR is copied as POSCAR from the previous directory, it gets overwritten by the new POSCAR generated from write_vasp_input_set. Even if the new POSCAR is generated from last structure in the last run, it loses the predictor-corrector coordinates stored in CONTCAR when continuing an MD job. When the overwrite option is off in https://github.com/materialsproject/atomate2/blob/9dcf35586eab52c4be842b1010aa268b98c8493d/src/atomate2/vasp/sets/base.py#L71, it will raise a FileExistsError. Is there a way to skip writing new input files for continuation jobs?

I did a temporary fix in my own branch by just changing the error raised by the existing POSCAR to a warning to allow the job to proceed. I'm not sure if that will break other things. An alternative might be moving the file existence check before copying files in https://github.com/materialsproject/atomate2/blob/9dcf35586eab52c4be842b1010aa268b98c8493d/src/atomate2/vasp/jobs/base.py#L130 to allow the user to turn off the overwrite option when writing inputs?

[utf]

Thanks for this bug report. The predictor-corrector coordinates are parsed by pymatgen Poscar class but lost when the converting to the structure object. E.g., see here:

https://github.com/materialsproject/atomate2/blob/daf06b4696415eee06db857819f22db91b467e52/src/atomate2/vasp/schemas/calculation.py#L503

I think a nice approach would be to enable storing these coordinates in the Structure object and then enable writing them when the input set is written back to a file. This should be enabled with an option in the TaskDocument that is turned on for MD calculations.

Do you think you would interested to add this feature? This would be useful as then we can store the predictor-coordinates in the output database.

Storing the predictor-coordinates is as simple as adding:

structure.add_site_property("predictor_corrector", contcar.predictor_corrector)
structure.add_site_property("velocities", contcar.velocities)

The only issue is that the predictor_corrector_preamble is not currently stored. I added an issue to pymatgen about the possibility of supporting this.