Time for generating supercells in MCSQS

Hi Axel,

I am using mcsqs to generate SQSs of FCC lattice using 100 atoms, however, it just stuck in generating the supercells (has been taking several days in generating the supercells). I am wondering how long should it take according to your experience. To me, this seems to be a little bit longer. For comparison, it only took a very short time (maybe several minutes?) for generating the supercells when using HCP lattice with 100 atoms. Is there any methods to know what’s going on for the FCC lattice case? Or are there any ‘supercell database’ for those usual lattices with varying atom numbers? thank you.

Best,
QJ

The difference is that hcp has 2 atoms per unit cell while fcc has 1. So there are (many) more supercells to enumerate in fcc. Probably O((100/50)^(~9)) more.
BTW you can see to supercell generation process if you use genstr (just list no atoms in lat.in).
You can see if it is really struck or getting slower, as you would expect.
100 atom is a big cell enumeration problem!!!
I don’t have cell data base, but you could create your own, shorter, sqscell.out if you want.
(For large cells, the exact cell shape is less crucial).
Finally, I should mention that a 50 atom fcc sqs is probably as good as a 100 atom hcp sqs, due to the higher symmetry.

Thank you Axel, for the detailed explanations and suggestions. I’ll try them.

Mcsqs never stops (unless all target correlations are matched) and keeps searching. Here, a 4 atom sqs is very small, so no good solution is found, so it keeps searching. I don’t see any problem here. Try a bigger sqs

Yes. This mcsqs code is designed for very large SQS, in which case the chance that it visits the same structure is negligible. But for a small supercell, it is not a good algorithm. Note that the alternative gensqs code does do a systematic enumeration, which works great for small cells (like you tried), but not for large ones.

OK. I initially thought when it explores all the possibilities constrained by -n=4, it will stop, and it should not be long. Are you suggesting some of the searched structures will be searched again and again?

This is a similar question so I guess there is no need to open up a new thread. I am trying a rocksalt primitive cell with one atom at (0, 0, 0) being two species, 0.5/0.5 probability. I noticed when the corrdump -2 parameter is set (say 4) so that there is more than one cluster, it becomes extremely slow even to generate a four atom supercell (mcsqs -n=4). I tried to run it as a job submission and 1 hour later mcsqs.log shows one structure generated, actually from the very beginning few minutes.

========================================
rndstr.in

4 4 4 90 90 90
0.500000 0.500000 0.000000
0.000000 0.500000 0.500000
0.500000 0.000000 0.500000

0.000000 0.000000 0.000000 Cr=.5,Co=.5
0.500000 0.500000 0.500000 O

clusters.out:

6
2.82843
2
1.00000 1.00000 1.00000 0 0
1.00000 0.50000 0.50000 0 0

3
4.00000
2
1.00000 1.00000 1.00000 0 0
1.00000 1.00000 0.00000 0 0

Dear Axel,

I’m wondering is it possible to choose any criterion, the number of MC step for example, to judge whether the mcsqs has converged?
In most cases, it seems difficult to match the correlation functions perfectly and I’m not sure if the SQS is satisfactory.

This is the nature Monte Carlo-based optimization (or genetic algorithms for that matter ): you never know for sure if the best solution has been found.
If a stopping criterion as simple as the number of mc step is what you are looking for , why not just kill the code after a certain amount of time has elapsed ?
In my experience , if the solution has no changed in a few hours, it never will .
You could try to increase temperature (or the other parameters) but mostly, increase cell size (-n).