Internal database construction stalled out?

Hey Axel,

I’m observing some weird behavior from maps. It’s been 50 hours running and the internal database of structures still "extends at least up to 0 atoms/unit cell". My predstr.out reflects this, it only contains a small handful of structures. Of those structures, some of them have "b" next to their names in the predstr.out file but those structures’ directories contain an energy file from a converged job. Also, the "ready" tag takes a very long time to be processed by maps (a handful of hours at least).

In the past, once the internal database of structures got rather large (>40 atoms/unit cell I think), the process of gobbling up the "ready" tag and creating files took a little while, but the other issues were never a problem.

Any ideas on what’s going on here?

Thank you a ton, Axel! I really appreciate your suggestions; I’m going to try them right away.

I am away from the lab for a couple days, but I will send you those files via email on Wednesday the 28th (put it on my todo list).

Thanks again,
Greg

P.S. Your compliment made my day.

I’ve posted a new version (3.39 - currently, the beta version) that include the option -mw=… for both maps and mmaps. This lets you specify the maximum weight a structure can receive while the code is trying to match the ground state line. Setting this to 1, will disable the feature trying to match the ground states. This will speed things up to get a preliminary answer. You can then check the output and more easily decide in which composition range (-c0=… -c1=…) it makes sense to enforce the right ground states.
I hope this helps!

I’d need the input files to debug this better…

Just to update: When I look in maps.log, I see

The wall time of the job running maps is now at 117.2 hours and will max out at 168 hours and need to be restarted. Nothing in the log file of the job indicates a problem…it just spends a very long time "finding the best cluster expansion".

Many thanks!

I am still looking into this.
In your example, it seems that the code is spending most of the time trying to optimize the cluster expansion to match the right ground states (you can see this by the fact that it restarts multiple times to loop over the cluster choices and that the next-to-last column is "0" ).
On way that could help is to specify a narrow concentration range where maps enforces the correct ground states.
That way, the optimization problem is easier to solve.
You can also force the code to use fewer clusters with the -m=… option.
Or you can specify a nbclusters.in file to force a given set of clusters.

If you could send just the */str.out */energy files that would help debug the slowness issue.
(BTW, your scripts are very well written!)