--
You received this message because you are subscribed to the Google Groups "atomate" group.
To unsubscribe from this group and stop receiving emails from it, send an email to atomate+u...@googlegroups.com.
To post to this group, send email to ato...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Hi Zhezhonga) To determine where you want a job to run, see:Scroll down to "Controlling the Worker that executes a Firework"b) To determine which nodes run a job, you need to set the right queue flags in my_qadapter.yaml - assuming your queueing system supports something like this. You might want to have two "FireWorkers" on the same machine - one with a queueadapter for one group of nodes (e.g., high memory node job submission) and another queue adapter for a second group of nodes (e.g., regular job submission).c) For the authentication failed, it's unclear where that code is being run, whether you are able to connect successfully at all from some other location, etc.. Some things to check:- are you using the right my_launchpad.yaml- does your my_launchpad contain the correct credentials?- do you need to set your authsource to admin database?- are you using the correct hostname, port, etc.?There are unfortunately too many potential issues and not enough details for me to give any real opinion on your auth error.As for "how to do (a-b) jobs in python?" I am not sure what you mean. Note that typically we set up all our workflows, etc. in Python but then manually execute "qlaunch -r rapidfire" on the nodes (i.e., log in manually and execute the command). Sometimes a cron job on the system is used, although you need to be careful to set that up well (e.g. with timeouts on the qlaunch).
To unsubscribe from this group and stop receiving emails from it, send an email to ato...@googlegroups.com.
To post to this group, send email to ato...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--Best,
Anubhav
Hi Anubhav,Thanks very much for your reply! I am still debugging the authentication error.1. my_launchpad.yaml is correct as the local laptop can connect to the database using 'lpad add' and supercomuter can find the job with 'lpad get_fws' and 'qlaunch'.2. The credential is correct that I tried the following test code and received 'True' from authenticate.```pythonfrom pymongo import MongoClient
client = MongoClient('mongodb+srv://user:pass...@alloyproject-4qquz.mongodb.net')db=client.admindb.authenticate(name=user,password=passwd)
```I traced the error back to atomate.utils.get_database, as I run the following code give bad authtication error.```python
config_file='/path/to/db.json'd = loadfn(config_file)conn = MongoClient(host=d["host"], port=d["port"])db = conn[d["database"]]user = d["admin_user"]passwd = d["admin_password"]db.authenticate(user, passwd)```The db.json file is like this
{"host": "mongodb+srv://admin:pass...@alloyproject-4qquz.mongodb.net",
To unsubscribe from this group and stop receiving emails from it, send an email to atomate+u...@googlegroups.com.
To post to this group, send email to ato...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "atomate" group.
To unsubscribe from this group and stop receiving emails from it, send an email to atomate+u...@googlegroups.com.
To post to this group, send email to ato...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
On 24 Apr 2019, at 20:43, Steven Hartman <stevent...@gmail.com> wrote:
Hi,
I've also seen this "nameless" VASP error message recently when running nscf-line calculations. If it's the same one I've had, it happens because the KPOINTS file doesn't list the tetrahedra, which are required for ISMEAR = -5. I'm not sure if this is a bug or if we're just doing it wrong. I've been working around it by switching to ISMEAR 0, SIGMA 0.01 for nscf-line, using the update_wflows command.
On Wednesday, April 24, 2019 at 12:24:09 PM UTC-5, Zezhong Zhang wrote:
Dear Anubhav,
I have updated my local atomate.utils.get_database, and add source='admin' to CalcDb.__init__ in atomate.utils.database (line42) (otherwise, it reports authentication error here).
Now, I can run the MgO band structure tutorial. Atomate seems to access the database and perform vasp calculation with no problem, as the optimisation and static calculations are fine (I have also checked the vasp output files). But theMgO-nscf uniform is fuzzled, the vasp output file and slurm output file are as attached.
Look forward to getting the atomate working on our machine, quite excited!
Best regards,
Zezhong
Cheers,Zezhong
To unsubscribe from this group and stop receiving emails from it, send an email to ato...@googlegroups.com.
Hey everyone,
To follow up on this: I’ve recently started using atomate
and was running into issues with the atomate.vasp.firetasks.parse_outputs.VaspToDb
firetask. I traced the problem to the authentication to the mongoDB database, so figured I must have made a mistake in setting up my db.json file. Nothing I tried, however, seemed to work.
I then started playing around with pymongo
to see if I could somehow understand the problem. Here’s a little notebook on colab with some of the tests I’ve run. I think the problem lies in the initialization of the atomate.utils.database.CalcDb
class, i.e. when testing the authentication using db.authenticate
. Even though the “authsource” is passed correctly to the MongoClient
initialization, it is not passed to the db.authentication()
call, and that causes authentication failures down the line, I think.
I’ve made a pull request with a little fix for this, that simply passes the “authsource” kwargs to the source
argument for the db.authenticate
call. That fixes the problem for me. Hopefully it doesn’t cause any other issues that I’ve missed.
Kind regards,
Marnik
PS: Thanks to Zezhong for pointing out this morning that using source= "admin"
in the db.authenticate
call fixed the problem for him. Having an office mate that also uses atomate
can be really useful! ;)