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/structure.py:740: 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/sets.py:437: 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.
BadInputSetWarning,
---------------------------------------------------------------------------
RuntimeError Traceback (most recent call last)
<ipython-input-14-0389cc0e976d> in <module>
1
2
----> 3 mag = MagneticOrderingsWF(structure).get_wf(scan=True)
4
5
~/.conda/envs/atomate/lib/python3.7/site-packages/atomate/vasp/workflows/base/magnetism.py in get_wf(self, scan, perform_bader, num_orderings_hard_limit, c)
324
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/scan.py 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/powerups.py 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
91
~/.conda/envs/atomate/lib/python3.7/site-packages/fireworks/core/firework.py 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))
74
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: https://github.com/hackingmaterials/atomate/blob/44f1240e96c3a137b4196cb7a91d08e232d5be2b/atomate/vasp/workflows/presets/scan.py#L40
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.
Thanks
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/magnetism.py 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
357
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.
Iâve removed the ["additional_fields"]
part of the magnetism.py from
scan_fws[0].tasks[-1]["additional_fields"]["task_label"] = new_name
source code and it seems to be working so far. The long term solution would be to use unique identifiers such that each optimisation is easily identifiable by subsequent firetasks. Will report back as, when or if the entire workflow works out
1 Like
Thanks for the update! As previously, the overall SCAN functionality in atomate is still under very active development (@rkingsbury lead), until this is finalized âdownstreamâ workflows that use SCAN might break. Agreed that task label is a poor substitute for a dedicated identifier, although the task labels themselves should ultimately be consistent and follow a convention.