protocol neb issue with different versions of VASP #694
Comments
|
Similar behavior in GPAW: |
|
So I see a few places things could be going wrong:
Re (1): I just re-ran the demo notebook using LAMMPS, and while there's some outdated syntax and some warnings, everything worked fine. I was concerned that maybe the stuff protocols do under the hood (mostly copying input template jobs) had gone off the rails, but it looks like everything is still compatible. Re (2): This is the top suspect for me right now. The The fact things fail for v6.3 is not crazy to me -- I have no idea if anyone has updated our parsers to that version. However, certainly it should be working for v5.4.4.
What is the "problem"? Can you please post the python stack trace or error log file contents (similarly for the GPAW issue, it would be very helpful to have the full trace). Is this problem specific to the NEB protocol? I.e. are you able to run static calculations/minimizations with Re (3): I doubt this is the issue, but what system are you working on and what's (roughly) your geometric setup? In pyiron_atomistics pyiron/pyiron_base#1048 I see we are apparently having trouble with parsing spins atm, so if you're altering the demo in any way to run magnetic systems that would give us a lead to follow. Unfortunately, Vasp is licensed and I no longer have access to it, and GPaw won't install trivially on my machine, so I don't intend to experiment with this directly myself -- at least not today; if the issue persists I can find a workaround. @raynol-dsouza @hari-ushankar, any insight? |
|
Thank you for your time.
Yes, LAMMPS works fine for me too.
I can run every example from this page without any errors. All lamps, gpaw, Sphinx, vasp examples.
The error message for GPAW: Error log for VASP: Al supercell, same as the example notebook. I didn't change the structure. |
|
Can it be related to what Jan mentioned here? Originally posted by @jan-janssen in pyiron/pyiron#979 (comment) |
|
Perfect, this is exactly what was needed. We're in luck that actually everything relevant is just in the last two frames: File envs/prnenvnew/lib/python3.9/site-packages/pyiron_contrib/protocol/primitive/one_state.py:280, in ExternalHamiltonian._reload(self)
278 self._job = pr.load(self._job_name)
279 self._job.interactive_open()
--> 280 self._job.interactive_initialize_interface()
File envs/prnenvnew/lib/python3.9/site-packages/pyiron_atomistics/gpaw/pyiron_ase.py:71, in AseJob.interactive_initialize_interface(self)
69 def interactive_initialize_interface(self):
70 self.status.running = True
---> 71 self._structure.calc.set_label(self.working_directory + "/")
72 self._interactive_library = True
AttributeError: 'NoneType' object has no attribute 'set_label'So in My first impression is that it's bad form for
Everything above is for Gpaw (which inherits from |
I gave VASP 6.3 another try, and it seems the issue has something to do with this: The last lines of OUT file: |
|
Is this output after recompiling 6.3 with the interactive patch? This anyhow looks like it's just directly an issue with vasp parsing/interactive vasp, so we'll probably need to pull in someone other than me to help fix it. |
Correct. |
Can you try running just a basic interactive job with this and see if it fails in the same way? I suspect it will, in which case you'll need to go over to I think a Vaspified version of the following should work for a MWE: from pyiron_atomistics import Project
pr = Project("tmp")
pr.remove_jobs(silently=True, recursive=True)
job = pr.create.job.Lammps("interactive")
job.structure = pr.create.structure.bulk("Al", cubic=True)
# For VASP you probably want to set low encut and one kpoint for speed
job.calc_md(n_ionic_steps=2, n_print=1, temperature=300)
with job.interactive_open() as ijob:
ijob.run()
job.output.energy_pot
>>> array([-13.43971504, -13.43886176])
# Obviously works fine for Lammps,
# but I hope/expect the same error as you got before with VaspEDIT: add hyperlink |
The Lammps version works, VASP version is stuck and results same error: POSITIONS: reading from stdin
|
Ok, in a way that's good news; it means that other than the issue with gpaw (which, IMO, is the gpaw job's fault for initializing the
Glad to hear that! 😄
That's hard for me to answer precisely, because it certainly won't be me doing the work (no Vasp license=no debugging changes on my local machine). Use the MWE above to open a new issue on Does the MWE also give an error with 5.4.4? If so, please also include this info on the new issue; if interactivity is working ok but it's somehow borking on the NEB protocol, lmk the details here and I'll try to fix it on the protocol's side. |
Since pyiron does not have any documentation on NEB, can you please provide some clarification on pyiron NEB protocol? I assume that these are similar to method parameter of ase.neb.NEB (here) One question is, which one is upwinding? My second question is, is there an easy way to implement Solid State Nudged Elastic Band in pyiron? An example code of SSNEB is this, so I assume pyiron can generate p1 and p2 to feed this code. |
Welcome to
I failed to document I'm not going to dig through the papers to compare, and I'm not going to go back and dig through the papers now. It's extremely likely that The crux of NEB is to allow the system to evolve according to the interatomic forces in the hyperspace perpendicular to the reaction pathway, while constraining the forces parallel to that reaction pathway. You can take a look at the protocol and see that the only fancy bit is calculating the NEB forces. Taking a look again at the vertex that does this, I'm retrospectively pretty happy with the readability (although I do regret not directly putting the paper citations in the docstring). You can see all the different tangent definitions here; The method for the upwinding tangent looks slightly scary, but it's just complicated by the fact that we need to account for the central image where there is not up-hill reference. You can compare the code to the papers to see what the connections are. E.g. I can see that the
Without being super familiar with it, yes, there should be a way. The easiest is probably just to sub-class the python template job, and pass Here is an older example of subclassing |
|
@sinazadeh did you ever manage to get interactive Vasp working? I patched the issue with Gpaw here, so on the latest head of |
It didn't work for me so I ran my calculations the manual way, without Pyiron. |
I'm sorry to hear that. The atomistics issue for interactive vasp is still open over on atomistics, but now that the NEB protocol is playing well with Gpaw I don't think there's any further issues with the NEB part. I'll close this now, but if you play with the uploaded notebook and run into any Gpaw+NEB problems feel free to re-open it. |
The following notebook for different versions of VASP raises different issues: protocol_neb_example.ipynb
In Version 6.3, there is an issue with starting the neb job. It only generates the neb_job_initialize_jobs_0 folder along with the following files: POSCAR, POTCAR, INCAR, and KPOINTS. The job never starts.
In Version 5.4.4, the notebook successfully creates the neb_job_initialize_jobs_0_hdf5 file and completes the calculations. However, it fails to compress the folder. Additionally, it generates neb_job_initialize_jobs_1_hdf5 and the same files as before (POSCAR, POTCAR, INCAR, and KPOINTS). Unfortunately, it encounters a problem and does not perform calculations for jobs_1, resulting in being stuck at this point.
The text was updated successfully, but these errors were encountered: