Can this problem be related to this thread somehow?<br>https://groups.google.com/forum/?hl=en&fromgroups=#!searchin/cp2k/Marc$20Van$20Houteghem/cp2k/t5UYWtZt3HI/DlfmK2W-a28J<br><br>No succes yet on this matter. I added a big molecular methanol system (128 molecules) and a small one (2 molecules) that reproduce the problem. Important to mention is that the computation only fails when run in parallel mode. It does not occur with a NVT ensemble and/or in serial mode (only the combination NPT ensemble and parallel computation fails). <br>Probably this is due to the stress tensor implementation.<br><br>marc<br><br>On Tuesday, November 27, 2012 3:35:51 PM UTC+1, Noam Bernstein wrote:<blockquote class="gmail_quote" style="margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Hi - I think I've found a small bug in the alchemy code, and I'm not sure how<div>best to fix it. For example for</div><div> FORCE_EVAL%MIXED%MIXING_TYPE LINEAR_COMBINATION,</div><div>there are two calls to mixed_map_forces(), the first with overwrite=.true., the</div>
<div>second with overwrite=.false. However, if the first FORCE_ENV has some of</div><div>the atoms missing (e.g. alchemy), the atoms that are missing never have</div><div>their forces overwritten. Presumably those forces should be set to 0 before</div>
<div>the forces from the second FORCE_ENV are added. </div><div><br></div><div>Was there some particular reason that the mixed forces aren't all just initialized to 0, </div><div>and instead the overwrite argument is used? Because I don't see a reliable way of</div>
<div>fixing this problem without either some tedious bookkeeping to find</div><div>all atoms that map to nothing in the overwrite=.true. case, or just setting</div><div>all the forces to 0 before the calls to mixed_map_forces(). I'd be happy</div>
<div>to submit a patch, but if there's some reason it's not a good idea to set</div><div>all the forces to 0, I'd like to understand that.</div><div><br></div><div> Noam</div>
</blockquote>