Does qmof_relax_job support copy_files keyword?

[honghuikim]

Hi all,

I'm trying to run VASP calculations with the same setting as the QMOF database, but it seems that the qmof_relax_job function does not copy WAVECARs between jobs of the QMOF workflow.

#1759 handles most of copy_files keywords, but the ones in qmof.py are all removed. Do you know if this is meant?
I'm using parsl, so I was wondering if this is related with #1776 or if I'm doing something wrong.

Another minor question is that the current QMOFset.yaml is using algo=All as default and NSW is set to be 250 or 500, which are different from the original setting in the paper. Is this change reported somewhere else or just modified for better convergence?

Thank you

[Andrew-S-Rosen]

@honghuikim: Thank you for your questions.

Let's start with the simple ones:

• ALGO doesn't change the compatability of the calculations. For MOFs, I have internal benchmarks (now long gone) showing that ALGO = All is generally most efficient for MOFs. For some machines though, you'll get a crash depending on how VASP is compiled. I think in the original paper, that was why I didn't use ALGO = All since it was causing VASP to crash on the machine I was using. I generally prefer ALGO = All though. I also used ALGO = All in the follow up npj Comput Mater paper I believe.
• For NSW, it really doesn't matter since I ran the calculations to convergence regardless and the relaxations are rerun several times if needed.

If the WAVECAR isn't copied, that seems like a bug. If you open an issue report, I can patch it tomorrow. It should be an easy fix. Don't worry about a minimal example. I know what the issue is (you pointed it out correctly).

If you're using Parsl, it should be okay for QMOF because it is all done as one job. But if you see an error raised during file copying with Parsl for multistep flows, that indeed will be solved with Parsl/parsl#3111.

[honghuikim]

@Andrew-S-Rosen Thank you for the fast reply!

I see, it's interesting that ALGO=All is the most efficient one for MOFs. I thought that setting ALGO=fast and NSW to be small can effectively change ALGO to All if ALGO=fast is not working fine by custodian.

For the copy issue, I'll check the issue again after updating my installed quacc to the latest one, and open an issue.

Thank you.

[Andrew-S-Rosen]

@honghuikim You're absolutely right. If custodian sees algo = Fast failing, it will change to All. So, in the case of using Custodian, it is probably fine to use either approach. In the original QMOF paper, I wasn't using Custodian yet so it wasn't available to me at the time. Now, either route is sensible. Same with NSW.

Thanks for bringing up the potential bug! I think I must have forgotten to update the copy file handling in that big PR...

[Andrew-S-Rosen]

PS. If you prefer/suggest the YAML to reflect the original ALGO and NSW values, feel free to open a PR. It doesn't matter much to me. Entirely up to you.

[honghuikim]

I think the current YAML should be fine for general purpose and originality. The only reason I was considering using ALGO=Fast was to reduce the cost, but if we start with the pre-optimized WAVECAR, working with ALGO=All should be fairly efficient.