With MoloVol v1.0.0 (windows release version).
In rare occasions with specific sets of input file and parameters, different optimization depths lead to slightly different results (observed occurrence: <0.01% difference in result).
MoloVol was designed so that to the optimization depth parameter would change the calculation time but not the results of the calculation.
How to reproduce the issue
One example of this bug occurrences is with the PDB 7K43 (see https://www.rcsb.org/structure/7k43).
With default element radii and following parameters:
Exclude HETATM from pdb file
Crystal unit cell analysis: No
Probe mode: one probe
Probe radius: 3 A
Grid resolution: 0.4 A
Optimization depth: variable
Results with optimization depth 0:
Van der Waals volume: 335010.944 A^3
Probe excluded void volume: 224515.968 A^3
Probe shell volume: 331091.968 A^3
Results with optimization depth 1-2:
Van der Waals volume: 335010.880 A^3
Probe excluded void volume: 224525.376 A^3
Probe shell volume: 331082.624 A^3
Results with optimization depth 3-4:
Van der Waals volume: 335010.944 A^3
Probe excluded void volume: 224525.312 A^3
Probe shell volume: 331082.624 A^3
Some volumes show differences below 0.01%, so much lower than the accuracy of the results. Such differences are not observed with several other parameter sets.
The sum of all three volumes is constant: 890618.88 A^3
So the optimization depth in this particular case seems to affect the limit between the voxel types.
Proposed change
First, we should investigate what is the origin of the bug then see if it's inherent to the octree development with specific combinations of grid resolution and probe radius. Then we can decide how to fix it if it can be fixed without jeopardizing the algorithms.
As the difference is minimal, it does not need to be urgently fixed.
Description
With MoloVol v1.0.0 (windows release version). In rare occasions with specific sets of input file and parameters, different optimization depths lead to slightly different results (observed occurrence: <0.01% difference in result). MoloVol was designed so that to the optimization depth parameter would change the calculation time but not the results of the calculation.
How to reproduce the issue
One example of this bug occurrences is with the PDB 7K43 (see https://www.rcsb.org/structure/7k43). With default element radii and following parameters: Exclude HETATM from pdb file Crystal unit cell analysis: No Probe mode: one probe Probe radius: 3 A Grid resolution: 0.4 A Optimization depth: variable
Results with optimization depth 0: Van der Waals volume: 335010.944 A^3 Probe excluded void volume: 224515.968 A^3 Probe shell volume: 331091.968 A^3
Results with optimization depth 1-2: Van der Waals volume: 335010.880 A^3 Probe excluded void volume: 224525.376 A^3 Probe shell volume: 331082.624 A^3
Results with optimization depth 3-4: Van der Waals volume: 335010.944 A^3 Probe excluded void volume: 224525.312 A^3 Probe shell volume: 331082.624 A^3
Some volumes show differences below 0.01%, so much lower than the accuracy of the results. Such differences are not observed with several other parameter sets. The sum of all three volumes is constant: 890618.88 A^3 So the optimization depth in this particular case seems to affect the limit between the voxel types.
Proposed change
First, we should investigate what is the origin of the bug then see if it's inherent to the octree development with specific combinations of grid resolution and probe radius. Then we can decide how to fix it if it can be fixed without jeopardizing the algorithms. As the difference is minimal, it does not need to be urgently fixed.