Submitting a workflow

Hello,

I am trying to install atomate/fireworks to run VASP calculations. I have completed the tutorial in Installing atomate — atomate 1.0.3 documentation, except for workflow submission step with “qlaunch rapidfire -m 1”. All the previous steps in that tutorial worked for me.

After submitting the workflow I get the following input/output:

lpad reset
Database at /home/ks2488/SOFTWARE/atomate/config/FW_config.yaml is getting selected.
Are you sure? This will RESET 1 workflows and all data. (Y/N)Y
2020-11-29 16:16:02,077 DEBUG RESTARTED fw_id, launch_id to (1, 1)
2020-11-29 16:16:02,106 INFO Performing db tune-up
2020-11-29 16:16:02,106 DEBUG Updating indices…
2020-11-29 16:16:02,607 INFO LaunchPad was RESET.

atwf add -l vasp -p wf_structure_optimization -m mp-149
Database at /home/ks2488/SOFTWARE/atomate/config/FW_config.yaml is getting selected.
2020-11-29 16:16:09,076 INFO Added a workflow. id_map: {-1: 1}

lpad get_wflows -d more
Database at /home/ks2488/SOFTWARE/atomate/config/FW_config.yaml is getting selected.
{
“state”: “READY”,
“name”: “Si–1”,
“created_on”: “2020-11-29T21:16:08.878000”,
“updated_on”: “2020-11-29T21:16:08.878000”,
“states”: {
“Si-structure optimization–1”: “READY”
},
“launch_dirs”: {
“Si-structure optimization–1”:
}
}

qlaunch rapidfire -m 10
Database at /home/ks2488/SOFTWARE/atomate/config/FW_config.yaml is getting selected.
2020-11-29 16:16:16,698 INFO getting queue adapter
2020-11-29 16:16:16,699 INFO Found previous block, using /gpfs/loomis/project/ks2488/4-mongod/test/block_2020-11-29-21-15-09-448527
2020-11-29 16:16:16,727 INFO The number of jobs currently in the queue is: 7
2020-11-29 16:16:16,727 INFO 7 jobs in queue. Maximum allowed by user: 10

Then, I check the block_2020-11-29-21-15-09-448527 folder, but there is nothing inside it. Also, when I check with squeue, there is no new job related to the workflow submitted.

I am using Mongodb Atlas. This is an institutional cluster which requires VPN for ssh access. I am not sure what the problem is at the moment, there is no error information. I have already changed strm_lvl: DEBUG in my_launchpad.yaml following an advice in one of the posts here, but it didnt print out any additional information. I appreciate your help.

Thanks,
Kayahan

Kayahan Saritas
Post-doctoral associate
Yale University

Hello,

can you post your my_qadapter.yaml file? I think that could help with troubleshooting…

Since your lpad commands work and show you the workflow, it is pretty clear that connection to the database is not the issue. Something seems to go wrong during the job submission.

Can you run the calculation (I am guessing you are testing with a small system) using rlaunch singleshot on the login node?

Thanks for quick reply. Yes, I am running Si bulk structure (mp-149) optimization using pymatgen. Below is my_qadapter.yaml file:

_fw_name: CommonAdapter
_fw_q_type: SLURM
rocket_launch: rlaunch -c /home/ks2488/SOFTWARE/atomate/config rapidfire
nodes: 2
walltime: 24:00:00
queue: day
job_name: dft-wf
pre_rocket: module purge; module load VASP/5.4.1-iomkl-2018b
logdir: /home/ks2488/SOFTWARE/atomate/logs

Here is the workflow output after I run lpad reset:

> atwf add -l vasp -p wf_structure_optimization -m mp-149
Database at /home/ks2488/SOFTWARE/atomate/config/FW_config.yaml is getting selected.
2020-11-30 08:12:24,434 INFO Added a workflow. id_map: {-1: 1}

> rlaunch singleshot
Database at /home/ks2488/SOFTWARE/atomate/config/FW_config.yaml is getting selected.
2020-11-30 08:12:35,496 INFO Hostname/IP lookup (this will take a few seconds)
2020-11-30 08:12:35,497 INFO Launching Rocket
No FireWorks are ready to run and match query! {'$or': [{'spec._fworker': {'$exists': False}}, {'spec._fworker': None}, {'spec._fworker': 'grace_vasp'}], 'spec._category': 'vasp'}
2020-11-30 08:12:35,684 INFO Rocket finished

This might be a my_fworker.yaml issue. What does that file look like?

Thanks for the help. my_fworker.yaml I have looks like this:

name: grace_vasp
category: 'vasp'
query: '{}'
env:
    db_file: /home/ks2488/SOFTWARE/atomate/config/db.json
    vasp_cmd: mpirun -np 40 /home/ks2488/SOFTWARE/vasp.5.4.4/bin/vasp_std
    scratch_dir: /home/ks2488/project/4-mongod/test/scratch

Delete the category line. That is causing the actual worker to only look for fireworks with category set to vasp

1 Like

It worked, thanks for the help.