Addition of JDFTx code

[cote3804]

Summary

Adding support for JDFTx, an open source plane wave code that supports grand-canonical DFT and implements accurate solvation models.

Dependencies on other repositories

• Pymatgen
• Custodian

What we've done

• Written JDFTx input and output parsers in pymatgen/io
• Implemented base input set and generator plus three base input sets
• Implemented basic calculation input and output schema
• Written tests following CP2K and VASP format

Future Development

• Make JDFTx compliant with the adsorbate workflows
• Add more rich schemas and store custodian metadata in schemas

Developer Note

We are working with @mkhorton on this project. We are the developers behind the BEAST Database and have extensive experience using JDFTx for high-throughput workflows as well as direct collaboration with the developer of JDFTx.

[utf]

Hi @cote3804, this is fantastic. Thank you for contributing it.

Firstly, would you be able to send me an email? My address is aganose [at] imperial [dot] ac [dot] uk.

For the PR, here are some high level comments to start with:

• The best place for the IO functionality is pymatgen. Are you happy to submit a PR there once the input sets are completed? I'm happy for you to keep them in this PR while you work on finalising the workflows, as I realise this makes it easier for testing etc.
• You can rename the emmet folders to schemas inline with atomate2 convention.
• The READMEs and test files inside the atomate2/src directory aren't ideal. We can add a JDFTx page to the documentation (in docs) and the test files should go in tests (although currently it looks like most of these files will be in pymatgen anyway).
• To help conform with the atomate2 code style, can you install pre-commit and run it on all of your files. This gets called automatically as part of the GitHub CI and the tests won't pass until all style issues are resolved.

pip install pre-commit
pre-commit run -all

Once you're ready for me to look at the input sets and jobs/flows please let me know (currently they have a lot of VASP code still).

[cote3804]

Hi @utf,

I emailed aganose@imperial.ac.uk but didn't get a reply. Is that the correct email? Your faculty profile seems to show it as a.ganose@imperial.ac.uk.

[soge8904]

Hi everyone,
I know this PR was previously blocked because it depended on materialsproject/pymatgen#4189 and materialsproject/pymatgen#4190. That dependency has now been merged, so I wanted to check if this PR can be reviewed again.
I’ve updated the branch with the latest changes from main, made sure pre-commit checks pass, and verified that the tests run correctly. Let me know if anything else needs to be addressed!

[cote3804]

Hi @utf
This PR should now be ready to merge. All of the JDFTx related tests should pass. There is one cp2k test that's failing, however this is also the case for the main branch.

[utf]

Hi @cote3804, apologies for the delay responding on this. Overall, I think it looks great. I'd just note that in most cases, we have now moved the input sets into pymatgen directly. Would you be OK to submit a PR to transition them over?

The only other thing is the jdftxcov.xml file which I think can be removed and added to the gitignore.

Once those changes are made I'm happy to merge it.

[cote3804]

Hi @utf

I'm happy to make both of those changes. Do you think it makes sense to merge the changes before moving the sets to pymatgen for the sake of having the JDFTx code working when the publication goes live? I'll still open the PR here and in pymatgen to move the sets.

[cote3804]

Hi @utf,

Sorry for the long pause on this from my end. I deleted the jdftxcov.xml file and didn't include it in the gitignore because I don't think it's necessary.

I moved our base input set over to Pymatgen and tried to follow the VASP style as faithfully as I could. There was very little code I changed. The PR is active at materialsproject/pymatgen#4479