OK, I looked into it a little deeper. FloppyTail will automatically detect N-terminal tails and attempt to handle them properly. The N-terminal handling comes at two costs:
A) The N-terminal tail has to be the FIRST part of the PDB (this is opposite from the suggestion I had before; C-terminal tails work best last). I tried this briefly and it worked okay
There may be a significant performance hit for an N-terminal tail as compared to a C-terminal tail of equal length. You may be able to fix this by playing with the FoldTree. Refer to the 2011 Leaver-Fay Rosetta3 paper, and the 2007 Wang/Bradley/Baker paper on docking with backbone flexibility, to understand what the FoldTree is. N-terminal tails may be slower because if the FoldTree root is in the tail, all parts of the complex will move as the tail moves; updating the 3d coordinates will get expensive.
If you see a performance hit, you can try fiddling with the code inside this block (starting at line 232 or so of src/apps/public/scenarios/FloppyTail.cc)
//for nonterminal sections, this fold tree might help (or might make it worse...)
if( stop_ != pose.total_residue() ){
TR << "non-terminal floppy section, using a linear fold tree to try to ensure downstream residues follown"
<< "Old tree: " << pose.fold_tree();
pose.fold_tree(core::kinematics::linearize_fold_tree(pose.fold_tree()));
TR << pose.fold_tree();
}
You may be able to restore performance if, after the line that says linearize_fold_tree, you add a line:
pose.fold_tree(pose.fold_tree().reorder(pose.total_residue());
I haven’t tested it but it has a fair chance of helping. Let me know if it works and I’ll patch it for the next release.