Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Two-step adsorption relaxation #90

Open
ktran9891 opened this issue Sep 5, 2019 · 5 comments
Open

Two-step adsorption relaxation #90

ktran9891 opened this issue Sep 5, 2019 · 5 comments
Labels
stale Old issue that is not likely to be fixed workflow enhancement

Comments

@ktran9891
Copy link
Collaborator

Apparently, it may be faster to:

  1. Fix all atoms except the adsorbate, and then fix the X and Y position of the adsorbate. Then allow it to relax in the Z direction.
  2. Do the rest of the relaxation normally.

If we were to do this, I'd recommend changing gaspy.fireworks_helper_scripts.make_firework and adding the 2-step procedure within a rocket.

@ktran9891 ktran9891 added the stale Old issue that is not likely to be fixed label Jun 12, 2020
@samueldy
Copy link
Contributor

I agree. More generally, I was thinking it would be good to use separate Fireworks within a Workflow for each step of the process (copy gaspy.vasp_functions to the launch directory, unhex slab_in.traj, do the constrained relaxation, then the full relaxation). If there is a way for Fireworks to expose previous launch information to the running Fireworks job, this could facilitate restarting from previous relaxation results (e.g., in the event of job timeout).

@zulissi
Copy link
Member

zulissi commented Jul 21, 2020

I think this is a good idea for small adsorbates, but I'm not sure how this would interact with something more complicated like a C2 adsorbate with more degrees of freedom.

@samueldy
Copy link
Contributor

Is the issue that many ionic steps are spent getting an adsorbate placed too far from the surface to approach the surface when all adsorbate atoms can move in all degrees of freedom?

Perhaps larger adsorbates could be handled by making a custom ASE constraint that converts the entire adsorbate into a big rigid rotor. After it approaches and aligns with the surface, the constraints could be relaxed to Hookean constrains on the bonds, or removed altogether.

@ktran9891
Copy link
Collaborator Author

Regarding restarts: I think that's something else entirely that would absolutely be worth looking into, but might be too much to lump into this issue. If we think that restarts would be valuable, then I'd recommend making that change alone and then revisiting this afterwards.

Regarding complicated adsorbates: I think Zack was questioning the helpfulness of this procedure for larger adsorbates. We could do a pre-relaxation in the Z-direction, but if we then release the complicated adsorbates and they end up reconfiguring anyway, we could just be adding overhead without much value. But I think this specific issue is really only worth worrying about if people are actually using GASpy on these complicated adsorbates, which we are not doing right now.

Regarding custom constraints: It's worth noting that the last time we tried, VASP could not handle custom constraints. We had to fall back to letting ASE do the relaxations while using VASP as a single-point calculator. Not a huge deal, just something to remember and address when making the FireWorks.

@samueldy
Copy link
Contributor

@ktran9891 Totally with you; restart capability was just an extra thought I had. I agree that this isn't high priority, and we have no plans for running large adsorbates right now. Yes, I was thinking about handling all constraints for the initial relaxation through ASE.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
stale Old issue that is not likely to be fixed workflow enhancement
Projects
None yet
Development

No branches or pull requests

3 participants