Closed MartinWenge closed 8 years ago
I still left the Base move in the implementations for generality. This mean, compiler will not complain, if a "wrong" or just unknown move is applied to the feature, if they inherit from MoveBase. We already talked about this, but couldn't find a concluding solution. It is very useful to "ignore" unknown moves, if you are using different kinds of move. But at the moment I didn't see any other moves than the MoveLocal.. ones. Could this change some day?
How about explicitly adding a checkMove for MoveLocalBcc in FeatureExcludedVolumeSc (and vice versa), so that the wrong move is forbidden? Or is this unnecessary overhead?
I added the suggestions and fixed the problems. This should fix #4 now.
I have tested FeatureExcludedVolumeSc with different systems (single chain, cross linked single chain globule, lipid membrane) and together with some of my features (NNInteraction, Umbrella sampling, external potentials). It seems to be working nicely, both with 2^n and other box sizes. So to my opinion wen could merge this.
Adding two different features for bcc and sc bfm. Now there is some code doubling, but we have high performance Excluded Volume Checks for both Sc and Bcc BFM. Adding MoveAddBccMonomer. Again some code doubling with the Sc counterpart, MoveAddScMonomer, but now systems for bcc and sc bfm can be created using the add monomer moves beeing safer than adding monomers "by hand". Test provides for the Features, using all kinds of moves.