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

SPHInX restart_from_charge_density surprisingly starts from atomic density #418

Closed
freyso opened this issue Nov 10, 2021 · 6 comments
Closed
Labels
bug Something isn't working

Comments

@freyso
Copy link
Contributor

freyso commented Nov 10, 2021

Summary

SPHInX restart_from_charge_density silently switches to restart from atomic densities if the code believes that no reliable density is available. That produces surprising behavior. It would be better to stop with a warning.

pyiron Version and Platform

developer version on cmti, as of November 2021.

Expected Behavior

Stop with a clear error message.

Actual Behavior

pyiron submits job with a different type of charge initialization

Steps to Reproduce

It's not entirely clear to me under which circumstances this happens. It was observed by @skatnagallu

I understand this happens when the main loop was never reached, or when the rho.sxb cannot be found for whatever reason.

The silent workaround seems to be from @samwaseda

@freyso freyso added the bug Something isn't working label Nov 10, 2021
@samwaseda
Copy link
Member

SPHInX restart_from_charge_density silently switches to restart from atomic densities if the code believes that no reliable density is available.

I don't really understand the phrase here. rho.sxb is not meant to be the charge density?

@skatnagallu
Copy link
Contributor

When I restart SPHInX jobs based on previous charge density, the function restart_from_charge_density probably does not find the previous job's density file (rho.sxb). Instead of raising an error (that it couldn't find the previous rho.sxb) when this happens, job restarts with a some different charge initialization.

@samwaseda
Copy link
Member

Ah ok so the atomic density is the estimated charge density based on the atomic configuration then. I didn't get the vocabulary but now I understand the problem. Let me see what VASP does and I'll decide what to do 😎

@samwaseda
Copy link
Member

So VASP raises an error so I'll fix it in SPHInX then.

/u/system/SLES12/soft/pyiron/dev/anaconda3/lib/python3.8/shutil.py in copyfile(src, dst, follow_symlinks)
    262         os.symlink(os.readlink(src), dst)
    263     else:
--> 264         with open(src, 'rb') as fsrc, open(dst, 'wb') as fdst:
    265             # macOS
    266             if _HAS_FCOPYFILE:

FileNotFoundError: [Errno 2] No such file or directory: '/cmmc/u/samsstud/RESEARCH/2021/1108/PYIRON/RESTART/vasp_init_hdf5/vasp_init/CHGCAR'

@samwaseda
Copy link
Member

@sudarsan-surendralal VASP raises the error above when run() is called, but it might be more helpful to do so when restart() is called. In addition, it could be good to say more explicitly that the charge density file was not found

@sudarsan-surendralal
Copy link
Member

Thanks for pointing this out @samwaseda. I've implemented a generic check in #422. Can you have a look at this? If you like it we can also apply them in #420.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants