MagneticOrderingsWF gives RuntimeError with `scan=True`

Creating a MagneticOrdering workflow with atomate gives an error when scan=True.

Example code

from pymatgen import MPRester
from atomate.vasp.workflows.base.magnetism import MagneticOrderingsWF

structure = MPRester().get_structure_by_material_id('mp-556058')

mag = MagneticOrderingsWF(structure).get_wf(scan=True) 

Gives the error:

/home/zccaayo/.conda/envs/atomate/lib/python3.7/site-packages/pymatgen/core/ UserWarning: Not all sites have property wyckoff. Missing values are set to None.
  "are set to None." % k)
/home/zccaayo/.conda/envs/atomate/lib/python3.7/site-packages/pymatgen/io/vasp/ BadInputSetWarning: Overriding the POTCAR functional is generally not recommended  as it significantly affect the results of calculations and compatibility with other calculations done with the same input set. Note that some POTCAR symbols specified in the configuration file may not be available in the selected functional.
RuntimeError                              Traceback (most recent call last)
<ipython-input-14-0389cc0e976d> in <module>
----> 3 mag = MagneticOrderingsWF(structure).get_wf(scan=True)

~/.conda/envs/atomate/lib/python3.7/site-packages/atomate/vasp/workflows/base/ in get_wf(self, scan, perform_bader, num_orderings_hard_limit, c)
    325                 # wf_scan_opt is just a single FireWork so can append it directly
--> 326                 scan_fws = wf_scan_opt(ordered_structure, c=c).fws
    327                 # change name for consistency with non-SCAN
    328                 new_name = scan_fws[0].name.replace(

~/.conda/envs/atomate/lib/python3.7/site-packages/atomate/vasp/workflows/presets/ in wf_scan_opt(structure, c)
     39             "job_type": "metagga_opt_run",
     40             "db_file": db_file,
---> 41             "vasp_cmd": vasp_cmd
     42         })
     43     wf = add_common_powerups(wf, c)

~/.conda/envs/atomate/lib/python3.7/site-packages/atomate/vasp/ in use_custodian(original_wf, fw_name_constraint, custodian_params)
     87             custodian_params["vasp_cmd"] = original_wf.fws[idx_fw].tasks[idx_t]["vasp_cmd"]
     88         original_wf.fws[idx_fw].tasks[idx_t] = \
---> 89             RunVaspCustodian(**custodian_params)
     90     return original_wf

~/.conda/envs/atomate/lib/python3.7/site-packages/fireworks/core/ in __init__(self, *args, **kwargs)
     71                     raise RuntimeError(
     72                         "Invalid keyword argument specified for: {}. You specified: {}. Allowed values are: {}.".format(
---> 73                             self.__class__, k, allowed_params))
     75     @abc.abstractmethod

RuntimeError: Invalid keyword argument specified for: <class 'atomate.vasp.firetasks.run_calc.RunVaspCustodian'>. You specified: db_file. Allowed values are: ['vasp_cmd', 'job_type', 'handler_group', 'max_force_threshold', 'scratch_dir', 'gzip_output', 'max_errors', 'ediffg', 'auto_npar', 'gamma_vasp_cmd', 'wall_time', 'half_kpts_first_relax'].

Hi @Arthur_Youd, welcome to the forum!

There was a bug in atomate with running with SCAN enabled due to stricter error checking – the db_file arg was never actually used.

Try updating your atomate version first, and if that doesn’t work please report the atomate version you’re running and I can help you get it fixed.

Hi @mkhorton, thanks for the welcome. I’m using the atomate 0.9.4 version and that I git cloned from the Github repository (so I assume this is the latest version). This still produces the same error. I also tried both within and outside an anaconda virtual environment. My python proficiency isn’t very advanced so this may well be an issue of not correctly setting the input parameters. Thanks for your help

Hi @Arthur_Youd,

0.9.4 is the latest version, however the code you’re showing does not actually reflect the latest version available – I wonder if you cloned the correct repository? Perhaps you cloned my fork.

See this line:

That’s line 41 from your error message, but as you can see there is no "db_file": db_file there.

Perhaps try installing via pip or conda instead, e.g. pip install atomate ?

Hi @mkhorton, we need to git clone the master branch to make it work, 0.9.4 haven’t merged the bug fix for ‘scan’ yet. It would be great if we can have the bug fix in the new version soon.


Ah, understood! Thanks @guoqianglan. I’m not able to make a release myself, but I can ask the atomate maintainers. @Alex, would it be possible to push a release?

I can push a release this weekend

Ok, atomate v0.9.5 should be released to PyPI now which should include the most up-to-date changes.

1 Like

Thanks, @mkhorton @Anubhav_Jain for your help so far. atomate 0.9.5 gives me a new error when running the same code as above. No such a problem occurs without the scan functional:

KeyError                                  Traceback (most recent call last)
<ipython-input-3-bc3cfefe5399> in <module>
      1 for i in structures:
      2     mag = MagneticOrderingsWF(i)
----> 3     mag = mag.get_wf(scan=True)
      4     meta = add_tags(modified_wf, "SCAN")
      5     launchpad.add_wf(meta)
~/miniconda3/envs/atomate/lib/python3.7/site-packages/atomate/vasp/workflows/base/ in get_wf(self, scan, perform_bader, num_orderings_hard_limit, c)
    353                 )
    354                 scan_fws[0].name = new_name
--> 355                 scan_fws[0].tasks[-1]["additional_fields"]["task_label"] = new_name
    356                 fws += scan_fws
KeyError: 'additional_fields'

I don’t think the SCAN functionality is tested (because the underlying ScanOptimizeFW was also under active development), so it may have broken because of a change to the underlying FireWork. This is still true, so it’s a bit tricky to fix right now (if I had to do it now, I would import the ScanOptimizeFW directly instead of using wf_scan_opt, and set the name correctly during init rather than changing it after the fact).

Ultimately, setting the name shouldn’t even be necessary, it is simply that the analysis task currently uses the task label to find the optimize tasks, so changing the regex in MagOrderingToDB would also fix it, if it was changed to look for tasks with “optimiz” (to cover both “optimize” and “optimization”. Relying on task label is not a good way to go though, I suspect I’d write this differently if I wrote it again.

Pull requests are welcome if you’d like to fix it, otherwise I’ll try and get a fix merged sometime in the next few weeks.