ValueError in all_stored_data.update

Hello,

I ran a number of workflows which consist of a static calculation followed by two non-self-consistent calculations, one in line mode and one in uniform mode. All of the static calculations fizzled, even though the calculations finished correctly and there were no errors reported in the custodian file or the .out and .err files. Using

lpad get_fws -s fizzled -d all

shows that there was a runtime error during the task.

[‘launches’][0][‘action’][‘stored_data’][’_stacktrace’] shows

“Traceback (most recent call last):\n File “/work/04391/tg836903/stampede2/atomate/atomate_env/lib/python3.6/site-packages/fireworks/core/rocket.py”, line 318, in run\n all_stored_data.update(m_action.stored_data)\nValueError: dictionary update sequence element #0 has length 8; 2 is required\n”

Here’s how I created the workflows, which are intended to be similar to the default band structure workflow, but without the initial relaxation (I already have relaxed structures):

for fname in filenames:
struct = Structure.from_file(fname + ‘.vasp’)

stat = StaticFW(structure = struct, vasp_cmd=‘ibrun tacc_affinity vasp_std’)
uni = NonSCFFW(parents=stat, vasp_cmd=‘ibrun tacc_affinity vasp_std’)
lin = NonSCFFW(parents=stat, mode=‘line’, vasp_cmd=‘ibrun tacc_affinity vasp_std’)

wf = Workflow([stat,uni,lin])
wf = add_modify_incar(wf, modify_incar_params={'incar_update':
    {'KPAR': 2, 'NCORE': 4, 'NSIM': 8, 'EDIFF': 0.000002, 'LMAXMIX': 6,
    'LSCALAPACK': '.FALSE.', 'ALGO': 'All'}})

lpad = LaunchPad.auto_load()

lpad.add_wf(wf)

Does anyone know why I’ve gotten this error? The only strange thing that I’m aware of is the use of ALGO ‘All’ in combination with ISMEAR -5, which triggers a warning in VASP but doesn’t seem to harm the calculation.

Thank you

Hi,

Is it possible for you to print out the value of m_action.stored_data right before the error?

Also which of the Fireworks is the one that fails?

···

On Thursday, February 28, 2019 at 2:31:46 PM UTC-8, Steven Hartman wrote:

Hello,

I ran a number of workflows which consist of a static calculation followed by two non-self-consistent calculations, one in line mode and one in uniform mode. All of the static calculations fizzled, even though the calculations finished correctly and there were no errors reported in the custodian file or the .out and .err files. Using

lpad get_fws -s fizzled -d all

shows that there was a runtime error during the task.

[‘launches’][0][‘action’][‘stored_data’][’_stacktrace’] shows

“Traceback (most recent call last):\n File “/work/04391/tg836903/stampede2/atomate/atomate_env/lib/python3.6/site-packages/fireworks/core/rocket.py”, line 318, in run\n all_stored_data.update(m_action.stored_data)\nValueError: dictionary update sequence element #0 has length 8; 2 is required\n”

Here’s how I created the workflows, which are intended to be similar to the default band structure workflow, but without the initial relaxation (I already have relaxed structures):

for fname in filenames:
struct = Structure.from_file(fname + ‘.vasp’)

stat = StaticFW(structure = struct, vasp_cmd=‘ibrun tacc_affinity vasp_std’)
uni = NonSCFFW(parents=stat, vasp_cmd=‘ibrun tacc_affinity vasp_std’)
lin = NonSCFFW(parents=stat, mode=‘line’, vasp_cmd=‘ibrun tacc_affinity vasp_std’)

wf = Workflow([stat,uni,lin])
wf = add_modify_incar(wf, modify_incar_params={'incar_update':
    {'KPAR': 2, 'NCORE': 4, 'NSIM': 8, 'EDIFF': 0.000002, 'LMAXMIX': 6,
    'LSCALAPACK': '.FALSE.', 'ALGO': 'All'}})

lpad = LaunchPad.auto_load()

lpad.add_wf(wf)

Does anyone know why I’ve gotten this error? The only strange thing that I’m aware of is the use of ALGO ‘All’ in combination with ISMEAR -5, which triggers a warning in VASP but doesn’t seem to harm the calculation.

Thank you

I’ve noticed that the new wf_bandstructure_no_opt predefined workflow does exactly what my workflow was meant to do. It was my static calculation firework that failed; when I get home from APS, I’ll see if I can figure out what was going on if anyone is still curious.

Thanks

···

On Sunday, March 3, 2019 at 7:50:27 PM UTC-5, Anubhav Jain wrote:

Hi,

Is it possible for you to print out the value of m_action.stored_data right before the error?

Also which of the Fireworks is the one that fails?

On Thursday, February 28, 2019 at 2:31:46 PM UTC-8, Steven Hartman wrote:

Hello,

I ran a number of workflows which consist of a static calculation followed by two non-self-consistent calculations, one in line mode and one in uniform mode. All of the static calculations fizzled, even though the calculations finished correctly and there were no errors reported in the custodian file or the .out and .err files. Using

lpad get_fws -s fizzled -d all

shows that there was a runtime error during the task.

[‘launches’][0][‘action’][‘stored_data’][’_stacktrace’] shows

“Traceback (most recent call last):\n File “/work/04391/tg836903/stampede2/atomate/atomate_env/lib/python3.6/site-packages/fireworks/core/rocket.py”, line 318, in run\n all_stored_data.update(m_action.stored_data)\nValueError: dictionary update sequence element #0 has length 8; 2 is required\n”

Here’s how I created the workflows, which are intended to be similar to the default band structure workflow, but without the initial relaxation (I already have relaxed structures):

for fname in filenames:
struct = Structure.from_file(fname + ‘.vasp’)

stat = StaticFW(structure = struct, vasp_cmd=‘ibrun tacc_affinity vasp_std’)
uni = NonSCFFW(parents=stat, vasp_cmd=‘ibrun tacc_affinity vasp_std’)
lin = NonSCFFW(parents=stat, mode=‘line’, vasp_cmd=‘ibrun tacc_affinity vasp_std’)

wf = Workflow([stat,uni,lin])
wf = add_modify_incar(wf, modify_incar_params={'incar_update':
    {'KPAR': 2, 'NCORE': 4, 'NSIM': 8, 'EDIFF': 0.000002, 'LMAXMIX': 6,
    'LSCALAPACK': '.FALSE.', 'ALGO': 'All'}})

lpad = LaunchPad.auto_load()

lpad.add_wf(wf)

Does anyone know why I’ve gotten this error? The only strange thing that I’m aware of is the use of ALGO ‘All’ in combination with ISMEAR -5, which triggers a warning in VASP but doesn’t seem to harm the calculation.

Thank you

I’ve encountered the same error with the wf_banstructure_no_opt. I logged the contents of m_action.stored_data on the line before the error:

2019-03-11 13:05:34,346 DEBUG [{‘job’: <custodian.vasp.jobs.VaspJob object at 0x2b2b70c2ff98>, ‘corrections’: [], ‘handler’: None, ‘validator’: None, ‘max_errors’: False, ‘max_errors_per_job’: False, ‘max_errors_per_handler’: False, ‘nonzero_return_code’: False}]

···

On Tuesday, March 5, 2019 at 5:58:17 PM UTC-6, Steven Hartman wrote:

I’ve noticed that the new wf_bandstructure_no_opt predefined workflow does exactly what my workflow was meant to do. It was my static calculation firework that failed; when I get home from APS, I’ll see if I can figure out what was going on if anyone is still curious.

Thanks

On Sunday, March 3, 2019 at 7:50:27 PM UTC-5, Anubhav Jain wrote:

Hi,

Is it possible for you to print out the value of m_action.stored_data right before the error?

Also which of the Fireworks is the one that fails?

On Thursday, February 28, 2019 at 2:31:46 PM UTC-8, Steven Hartman wrote:

Hello,

I ran a number of workflows which consist of a static calculation followed by two non-self-consistent calculations, one in line mode and one in uniform mode. All of the static calculations fizzled, even though the calculations finished correctly and there were no errors reported in the custodian file or the .out and .err files. Using

lpad get_fws -s fizzled -d all

shows that there was a runtime error during the task.

[‘launches’][0][‘action’][‘stored_data’][’_stacktrace’] shows

“Traceback (most recent call last):\n File “/work/04391/tg836903/stampede2/atomate/atomate_env/lib/python3.6/site-packages/fireworks/core/rocket.py”, line 318, in run\n all_stored_data.update(m_action.stored_data)\nValueError: dictionary update sequence element #0 has length 8; 2 is required\n”

Here’s how I created the workflows, which are intended to be similar to the default band structure workflow, but without the initial relaxation (I already have relaxed structures):

for fname in filenames:
struct = Structure.from_file(fname + ‘.vasp’)

stat = StaticFW(structure = struct, vasp_cmd=‘ibrun tacc_affinity vasp_std’)
uni = NonSCFFW(parents=stat, vasp_cmd=‘ibrun tacc_affinity vasp_std’)
lin = NonSCFFW(parents=stat, mode=‘line’, vasp_cmd=‘ibrun tacc_affinity vasp_std’)

wf = Workflow([stat,uni,lin])
wf = add_modify_incar(wf, modify_incar_params={'incar_update':
    {'KPAR': 2, 'NCORE': 4, 'NSIM': 8, 'EDIFF': 0.000002, 'LMAXMIX': 6,
    'LSCALAPACK': '.FALSE.', 'ALGO': 'All'}})

lpad = LaunchPad.auto_load()

lpad.add_wf(wf)

Does anyone know why I’ve gotten this error? The only strange thing that I’m aware of is the use of ALGO ‘All’ in combination with ISMEAR -5, which triggers a warning in VASP but doesn’t seem to harm the calculation.

Thank you

Hi Steven,

I think this is likely due to recent changes which try to save custodian data in stored_data. In particular, the part that tries to store:

‘job’: <custodian.vasp.jobs.VaspJob object at 0x2b2b70c2ff98>

doesn’t look right to me as it is not a JSON object.

I am going to post this as part of https://github.com/hackingmaterials/atomate/issues/262

We can follow up there.

···

On Monday, March 11, 2019 at 11:23:15 AM UTC-7, Steven Hartman wrote:

I’ve encountered the same error with the wf_banstructure_no_opt. I logged the contents of m_action.stored_data on the line before the error:

2019-03-11 13:05:34,346 DEBUG [{‘job’: <custodian.vasp.jobs.VaspJob object at 0x2b2b70c2ff98>, ‘corrections’: [], ‘handler’: None, ‘validator’: None, ‘max_errors’: False, ‘max_errors_per_job’: False, ‘max_errors_per_handler’: False, ‘nonzero_return_code’: False}]

On Tuesday, March 5, 2019 at 5:58:17 PM UTC-6, Steven Hartman wrote:

I’ve noticed that the new wf_bandstructure_no_opt predefined workflow does exactly what my workflow was meant to do. It was my static calculation firework that failed; when I get home from APS, I’ll see if I can figure out what was going on if anyone is still curious.

Thanks

On Sunday, March 3, 2019 at 7:50:27 PM UTC-5, Anubhav Jain wrote:

Hi,

Is it possible for you to print out the value of m_action.stored_data right before the error?

Also which of the Fireworks is the one that fails?

On Thursday, February 28, 2019 at 2:31:46 PM UTC-8, Steven Hartman wrote:

Hello,

I ran a number of workflows which consist of a static calculation followed by two non-self-consistent calculations, one in line mode and one in uniform mode. All of the static calculations fizzled, even though the calculations finished correctly and there were no errors reported in the custodian file or the .out and .err files. Using

lpad get_fws -s fizzled -d all

shows that there was a runtime error during the task.

[‘launches’][0][‘action’][‘stored_data’][’_stacktrace’] shows

“Traceback (most recent call last):\n File “/work/04391/tg836903/stampede2/atomate/atomate_env/lib/python3.6/site-packages/fireworks/core/rocket.py”, line 318, in run\n all_stored_data.update(m_action.stored_data)\nValueError: dictionary update sequence element #0 has length 8; 2 is required\n”

Here’s how I created the workflows, which are intended to be similar to the default band structure workflow, but without the initial relaxation (I already have relaxed structures):

for fname in filenames:
struct = Structure.from_file(fname + ‘.vasp’)

stat = StaticFW(structure = struct, vasp_cmd=‘ibrun tacc_affinity vasp_std’)
uni = NonSCFFW(parents=stat, vasp_cmd=‘ibrun tacc_affinity vasp_std’)
lin = NonSCFFW(parents=stat, mode=‘line’, vasp_cmd=‘ibrun tacc_affinity vasp_std’)

wf = Workflow([stat,uni,lin])
wf = add_modify_incar(wf, modify_incar_params={'incar_update':
    {'KPAR': 2, 'NCORE': 4, 'NSIM': 8, 'EDIFF': 0.000002, 'LMAXMIX': 6,
    'LSCALAPACK': '.FALSE.', 'ALGO': 'All'}})

lpad = LaunchPad.auto_load()

lpad.add_wf(wf)

Does anyone know why I’ve gotten this error? The only strange thing that I’m aware of is the use of ALGO ‘All’ in combination with ISMEAR -5, which triggers a warning in VASP but doesn’t seem to harm the calculation.

Thank you

Actually, it looks like the problem was solved and pushed to v0.8.7.

Before I post anything, can you please make sure you have the latest version of atomate installed? (v0.8.7).

Anubhav

···

On Monday, March 25, 2019 at 1:09:32 PM UTC-7, Anubhav Jain wrote:

Hi Steven,

I think this is likely due to recent changes which try to save custodian data in stored_data. In particular, the part that tries to store:

‘job’: <custodian.vasp.jobs.VaspJob object at 0x2b2b70c2ff98>

doesn’t look right to me as it is not a JSON object.

I am going to post this as part of https://github.com/hackingmaterials/atomate/issues/262

We can follow up there.

On Monday, March 11, 2019 at 11:23:15 AM UTC-7, Steven Hartman wrote:

I’ve encountered the same error with the wf_banstructure_no_opt. I logged the contents of m_action.stored_data on the line before the error:

2019-03-11 13:05:34,346 DEBUG [{‘job’: <custodian.vasp.jobs.VaspJob object at 0x2b2b70c2ff98>, ‘corrections’: [], ‘handler’: None, ‘validator’: None, ‘max_errors’: False, ‘max_errors_per_job’: False, ‘max_errors_per_handler’: False, ‘nonzero_return_code’: False}]

On Tuesday, March 5, 2019 at 5:58:17 PM UTC-6, Steven Hartman wrote:

I’ve noticed that the new wf_bandstructure_no_opt predefined workflow does exactly what my workflow was meant to do. It was my static calculation firework that failed; when I get home from APS, I’ll see if I can figure out what was going on if anyone is still curious.

Thanks

On Sunday, March 3, 2019 at 7:50:27 PM UTC-5, Anubhav Jain wrote:

Hi,

Is it possible for you to print out the value of m_action.stored_data right before the error?

Also which of the Fireworks is the one that fails?

On Thursday, February 28, 2019 at 2:31:46 PM UTC-8, Steven Hartman wrote:

Hello,

I ran a number of workflows which consist of a static calculation followed by two non-self-consistent calculations, one in line mode and one in uniform mode. All of the static calculations fizzled, even though the calculations finished correctly and there were no errors reported in the custodian file or the .out and .err files. Using

lpad get_fws -s fizzled -d all

shows that there was a runtime error during the task.

[‘launches’][0][‘action’][‘stored_data’][’_stacktrace’] shows

“Traceback (most recent call last):\n File “/work/04391/tg836903/stampede2/atomate/atomate_env/lib/python3.6/site-packages/fireworks/core/rocket.py”, line 318, in run\n all_stored_data.update(m_action.stored_data)\nValueError: dictionary update sequence element #0 has length 8; 2 is required\n”

Here’s how I created the workflows, which are intended to be similar to the default band structure workflow, but without the initial relaxation (I already have relaxed structures):

for fname in filenames:
struct = Structure.from_file(fname + ‘.vasp’)

stat = StaticFW(structure = struct, vasp_cmd=‘ibrun tacc_affinity vasp_std’)
uni = NonSCFFW(parents=stat, vasp_cmd=‘ibrun tacc_affinity vasp_std’)
lin = NonSCFFW(parents=stat, mode=‘line’, vasp_cmd=‘ibrun tacc_affinity vasp_std’)

wf = Workflow([stat,uni,lin])
wf = add_modify_incar(wf, modify_incar_params={'incar_update':
    {'KPAR': 2, 'NCORE': 4, 'NSIM': 8, 'EDIFF': 0.000002, 'LMAXMIX': 6,
    'LSCALAPACK': '.FALSE.', 'ALGO': 'All'}})

lpad = LaunchPad.auto_load()

lpad.add_wf(wf)

Does anyone know why I’ve gotten this error? The only strange thing that I’m aware of is the use of ALGO ‘All’ in combination with ISMEAR -5, which triggers a warning in VASP but doesn’t seem to harm the calculation.

Thank you

Updating to v0.8.7 fixed the problem, and the wf_bandstructure_no_opt now works correctly. Thanks!

···

On Monday, March 25, 2019 at 3:12:07 PM UTC-5, Anubhav Jain wrote:

Actually, it looks like the problem was solved and pushed to v0.8.7.

Before I post anything, can you please make sure you have the latest version of atomate installed? (v0.8.7).

Anubhav

On Monday, March 25, 2019 at 1:09:32 PM UTC-7, Anubhav Jain wrote:

Hi Steven,

I think this is likely due to recent changes which try to save custodian data in stored_data. In particular, the part that tries to store:

‘job’: <custodian.vasp.jobs.VaspJob object at 0x2b2b70c2ff98>

doesn’t look right to me as it is not a JSON object.

I am going to post this as part of https://github.com/hackingmaterials/atomate/issues/262

We can follow up there.

On Monday, March 11, 2019 at 11:23:15 AM UTC-7, Steven Hartman wrote:

I’ve encountered the same error with the wf_banstructure_no_opt. I logged the contents of m_action.stored_data on the line before the error:

2019-03-11 13:05:34,346 DEBUG [{‘job’: <custodian.vasp.jobs.VaspJob object at 0x2b2b70c2ff98>, ‘corrections’: [], ‘handler’: None, ‘validator’: None, ‘max_errors’: False, ‘max_errors_per_job’: False, ‘max_errors_per_handler’: False, ‘nonzero_return_code’: False}]

On Tuesday, March 5, 2019 at 5:58:17 PM UTC-6, Steven Hartman wrote:

I’ve noticed that the new wf_bandstructure_no_opt predefined workflow does exactly what my workflow was meant to do. It was my static calculation firework that failed; when I get home from APS, I’ll see if I can figure out what was going on if anyone is still curious.

Thanks

On Sunday, March 3, 2019 at 7:50:27 PM UTC-5, Anubhav Jain wrote:

Hi,

Is it possible for you to print out the value of m_action.stored_data right before the error?

Also which of the Fireworks is the one that fails?

On Thursday, February 28, 2019 at 2:31:46 PM UTC-8, Steven Hartman wrote:

Hello,

I ran a number of workflows which consist of a static calculation followed by two non-self-consistent calculations, one in line mode and one in uniform mode. All of the static calculations fizzled, even though the calculations finished correctly and there were no errors reported in the custodian file or the .out and .err files. Using

lpad get_fws -s fizzled -d all

shows that there was a runtime error during the task.

[‘launches’][0][‘action’][‘stored_data’][’_stacktrace’] shows

“Traceback (most recent call last):\n File “/work/04391/tg836903/stampede2/atomate/atomate_env/lib/python3.6/site-packages/fireworks/core/rocket.py”, line 318, in run\n all_stored_data.update(m_action.stored_data)\nValueError: dictionary update sequence element #0 has length 8; 2 is required\n”

Here’s how I created the workflows, which are intended to be similar to the default band structure workflow, but without the initial relaxation (I already have relaxed structures):

for fname in filenames:
struct = Structure.from_file(fname + ‘.vasp’)

stat = StaticFW(structure = struct, vasp_cmd=‘ibrun tacc_affinity vasp_std’)
uni = NonSCFFW(parents=stat, vasp_cmd=‘ibrun tacc_affinity vasp_std’)
lin = NonSCFFW(parents=stat, mode=‘line’, vasp_cmd=‘ibrun tacc_affinity vasp_std’)

wf = Workflow([stat,uni,lin])
wf = add_modify_incar(wf, modify_incar_params={'incar_update':
    {'KPAR': 2, 'NCORE': 4, 'NSIM': 8, 'EDIFF': 0.000002, 'LMAXMIX': 6,
    'LSCALAPACK': '.FALSE.', 'ALGO': 'All'}})

lpad = LaunchPad.auto_load()

lpad.add_wf(wf)

Does anyone know why I’ve gotten this error? The only strange thing that I’m aware of is the use of ALGO ‘All’ in combination with ISMEAR -5, which triggers a warning in VASP but doesn’t seem to harm the calculation.

Thank you