Looking at mmclib.c++, it appears as though the functionality implemented by the presence of a ‘frozensite.in’ file only gets triggered within the ‘MultiMonteCarlo::spin_flip’ method, which leaves the ‘multi_spin_flip’ method free to select any site, frozen or not. Sadly, my system appears to rely exclusively on multi_spin_flip.
A zip file containing input files to demonstrate this failure should be attached. If I’m misunderstanding or overlooking something, please let me know.
Sorry I didn’t realize that.
If you are ok with a using canonical MC (constant composition), then that would fix your problem.
(To do so, specify a conccons.in file, as explained in memc2 -h ). In the meantime, I’ll look into making the feature available in grandcanonical MC as well.
Hi,
Thank you for looking into this, and I apologize for any confusion. If I’m not mistaken (hardly a sure thing), I am using canonical MC, and there should be a conccons.in file within the zipped example directory. When I run the example on my computer, composition appears to remain constant (as expected), but sublattice sites I expect to remain "frozen" still swap their species around. From what I could tell during some brief debugging, the frozensite file is read properly, but the information is never used by the routine that’s doing the MC swaps (multi_spin_flip).
-Craig
Thank you for the patch. When I test it with the example provided in the previous zip file, it appears to get caught within MultiMonteCarlo::find_all_allowed_flips. From what I can tell, the following break condition is never satisfied:
for (same=0; same<nbflip; same++) {
if (((Array<int> &)before_types)(same)==((Array<int> &)after_types)(same)) break;
}
Any suggestions regarding what I might be doing wrong?