Something went wrong on our end
-
Studer Gabriel authored
The main idea is to pull out the actual optimization procedure from the sidechain module in order to use it for other applications as well. The result is a GraphOptimizer object in the core module, that has a heavily reduced usage of pointer magic. Eigen matrices are used instead. Two bugs have been identified and solved in this procedure. - Pairwise energy calculation in RRMRotamerGroups. There is a check to skip the according edge if all of the absolute energy values are below a certain threshold. There was no absolute value calculation => some of the edges have been skipped if only negative pairwise energies have been present. This is relatively rare and had no too big impact on performance (by default we're using the flexible rotamer model anyway) - Edge decomposition bug. The edge decomposition removes edges if the removal can be compensated by adding single values to the solutions of the two connected nodes. The logic to decide whether an edge should be removed or not was correct, but the added values were partially wrong. This has a measurable impact on performance and we should consider a bugfix relase at some point.
Studer Gabriel authoredThe main idea is to pull out the actual optimization procedure from the sidechain module in order to use it for other applications as well. The result is a GraphOptimizer object in the core module, that has a heavily reduced usage of pointer magic. Eigen matrices are used instead. Two bugs have been identified and solved in this procedure. - Pairwise energy calculation in RRMRotamerGroups. There is a check to skip the according edge if all of the absolute energy values are below a certain threshold. There was no absolute value calculation => some of the edges have been skipped if only negative pairwise energies have been present. This is relatively rare and had no too big impact on performance (by default we're using the flexible rotamer model anyway) - Edge decomposition bug. The edge decomposition removes edges if the removal can be compensated by adding single values to the solutions of the two connected nodes. The logic to decide whether an edge should be removed or not was correct, but the added values were partially wrong. This has a measurable impact on performance and we should consider a bugfix relase at some point.
rotamer_graph.cc 1.21 KiB
#include <promod3/sidechain/rotamer_graph.hh>
namespace promod3 { namespace sidechain {
RotamerGraph::~RotamerGraph() { }
template<typename RotamerGroupPtr>
RotamerGraphPtr RotamerGraph::CreateFromList(
const std::vector<RotamerGroupPtr>& rotamer_groups) {
core::ScopedTimerPtr prof = core::StaticRuntimeProfiler::StartScoped(
"RotamerGraph::CreateFromList", 2);
RotamerGraphPtr graph(new RotamerGraph);
// let's create the nodes
uint counter = 0;
std::vector<Real> self_energies;
for(uint i = 0; i < rotamer_groups.size(); ++i) {
RotamerGroupPtr rot_group = rotamer_groups[i];
self_energies.resize(rot_group->size());
for(uint j = 0; j < rot_group->size(); ++j){
self_energies[j] = (*rot_group)[j]->GetSelfEnergy();
}
graph->AddNode(self_energies);
}
// let's create the edges
for(uint i = 0; i < rotamer_groups.size(); ++i){
for(uint j = i+1; j < rotamer_groups.size(); ++j){
promod3::core::EMatXX emat;
if(rotamer_groups[i]->CalculatePairwiseEnergies(rotamer_groups[j],
0.01, emat)) {
graph->AddEdge(i, j, emat);
}
}
}
return graph;
}
}}//ns