You are here

SnugDock - What protocol should I use?

9 posts / 0 new
Last post
SnugDock - What protocol should I use?

Hello everyone,

I'm looking foward to use the SnugDock  protocol. I did read both "SnugDock: Paratope Structural Optimization during Antibody-Antigen Docking Compensates for Errors in Antibody Homology Models" (  and "Modeling and docking of antibody structures with Rosetta" ( articles. 

Also, I read the SnugDock web page in .

The problem is that the description of the protocol in the website is different from the articles. In the webpage are mentioned a lot of flags that theoretically should be used in the protocol that are not mentioned in the articles.

For instance: In the articles, after modeling all the structures for the ensembles and prepacking them, the authors only says to run the command  snugdock.mpi.linuxgccrelease -s antibody_antigen_start.prepack.pdb -ensemble1 antibody_ensemble.list  -ensemble2 antigen_ensemble.list -antibody:auto_generate_kink_constraint -antibody:all_atom_mode_kink_constraint -nstruct 1000

but in the webpage manual it says that all the following flags should be used: snugdock.mpi.linuxgccrelease -s input.pdb -native native_input.pdb -out:file:scorefile -out:path:pdb models_path_out -out:pdb_gz -nstruct 1000 -constraints:cst_file kink.cst -constraints:cst_weight 1.0 -constraints:cst_fa_file kink.cst -constraints:cst_fa_weight 1.0 -partners LH_G –spin -dock_pert 3 8 -h3_filter false -kic_rama2b -loops:ramp_fa_rep -loops:ramp_rama -kic_omega_sampling -allow_omega_move true -loops:refine_outer_cycles 3 -loops:max_inner_cycles 80 -ex1 -ex2aro -talaris2014 true 

I'm aware that some of these additional flags should be used only if I need/want (like constraints flags, output flags) but there are several others flags that seem to be important. So, should I only use the flags described in the articles or use all the options mentioned in the protocol webpage?

Thanks in advance,


Post Situation: 
Tue, 2018-11-27 07:32

Hey Danilo,

First, let me apologize for the asynchornous documentation. We are in the process of cleaning up the flags and the documentation has not kept pace.

I will try to describe the flags and my reasoning for which to keep/toss.

  • Some of the flags set input/output locations, e.g. -s or -ensembleX. These are necessary
  • A few are for CDR H3 constraints, which are optional (they improve performance if you believe your H3 has a kink, and typically 90% do). Previously these constraints were manually specified, now they are automatic so do not keep them.
  • Others are for setting loop modeling options (all the KIC/loops flags). You do not need these any more as these options are now default. Again, do not keep.
  • There are two flags for setting your level of side-chain rotamer sampling (default is 3 rotamers per side-chain dihedral, each ex level should add +/- 1 std. dev. per dihedral, so -ex1 means 9 rotamers). These are up to you, though typically -ex1 and -ex2aro (aro means only add extra rotamers for aromatic residues) are used.
  • Finally, -talaris2014 true restores the older energy function, but we no longer use this flag as snugdock appears to perform ok with the new energy function.


That said, I would use mostly the paper flags with a slight addition (I have highlighted in red): snugdock.mpi.linuxgccrelease -s antibody_antigen_start.prepack.pdb -ensemble1 antibody_ensemble.list  -ensemble2 antigen_ensemble.list -antibody:auto_generate_kink_constraint -antibody:all_atom_mode_kink_constraint -partners LH_G –spin -dock_pert 3 8 -ex1 -ex2aro -nstruct 1000 

Let me know if you have further questions,


Tue, 2018-11-27 07:50

Hello Jeliazko,

Your answer was complete and very helpfull. Thank you very much.

I only have one more question. I'm using the Rosetta 3.7 version. So, when you say that some of the options are now default, is the 3.7 version aware of that? Or maybe it's better to use a newer version, like 3.10?




Tue, 2018-11-27 07:59

Hey Danilo, 

I would use the latest version, unless you want to replicate work from a paper, then use the version described therein. The options changes all likely occured before version 3.7, but I would use a more recent version to be safe.



Tue, 2018-11-27 12:30

That's perfect. I can upgrade to version 3.10. In fact I have already built this version on our cluster but haven't tried yet.

Thank you very much for all responses.



Tue, 2018-11-27 14:58

Many of these flags were introduced in this paper, which is mentioned in the documentation:

Weitzner et al. for more

Tue, 2018-11-27 10:15

Thank you jadolfbr. I'll take a look into it.




Tue, 2018-11-27 10:44

Just another update about this.

I'm now running SnugDock in Rosetta version 3.10.

At the end of the docking_prepack protocol, I have now 10 prepacked antibody structures (ensemble1) and 10 prepacked antigen structures (ensemble2). These files have a final "extension" .ppk , how they are supposed to be according to the tutorials.

For my surprise, two additional structures were added to the ensembles list, one for each: partner1_starting_conf.pdb.ppk for ensemble1 and partner2_starting_conf.pdb.ppk for the ensemble2. This feature is not present in the 3.7 version. I suppose that this is to ensure that the initial input structure will be considered during the initial steps of the docking protocol.

Everything ready to start. I used the command line suggested by Jeliazkov, as follow:

snugdock.mpi.linuxgccrelease -s antibody_antigen_start.prepack.pdb -ensemble1 antibody_ensemble.list  -ensemble2 antigen_ensemble.list -antibody:auto_generate_kink_constraint -antibody:all_atom_mode_kink_constraint -partners LH_A –spin -dock_pert 3 8 -ex1 -ex2aro -nstruct 1000

and then I got an error:

ERROR: Sequence for partner1:


does not match first member of ensemble1:


I double checked all my input files: all chains are in the correct order (light chain, heavy chain, chain A); ensemble lists are directing to the corret directory (ensemble1 for antibody structures and ensemble2 for antigen structures). It looks like it compares the sequence of the antibody in the input file given by -s flag with all other structures in the ensemble1 and it thinks that the chains are in the inverse order (as you can see in the error output). But it is not, I have cheked all my input files and they match the chains order: Light chain L, heavy chain H.

Since everything seems ok, I went to check the output files from prepack protocol that I wasn't expecting (partner1_starting_conf.pdb.ppk and partner2_starting_conf.pdb.ppk). It happens that the partner1_starting_conf.pdb.ppk , which is the initial configuration for the antibody, contains all the chains ID modified from the original configuration. For instance, the light chain, which should be labeled as L, is now labeled as A. Similarly, the chain H is labeled as B. Also, the numbering scheme is absent: the amino acids are now numbered consecutively (from 1 to 240), whereas in the original input file the numbering follows the Chothia scheme. In other words, the docking_prepack is messing up the initial configuration of the antibody and putting the pdb.ppk file with errors into the ensemble1 list/directory causing error in the simulation.

Expecting that the source of the error was the different numbering, I renumbered the file to be identical to the original input. But the error keeps occouring. So I thought that if I discard both partner1_starting_conf.pdb.ppk and partner2_starting_conf.pdb.ppk files I should be able to run the protocol. But again, using only the ppk files given by the docking_prepack protocol the error is still there.

This problem does not happen when I use the version 3.7.

I'm not sure if I'm doing something wrong (I don't think so, since the version 3.7 works fine with the same input files) nor if the developers are aware of this problem already. I'm sory if I'm reporting in the wrong topic and for the long text (and possible gramatical erros).



Tue, 2018-11-27 17:35

One more update.

I swapped the order of the chain in the prepacked antibody files (.ppk) of ensemble1 to be fisrt heavy chain H and then light chain L.

Now the SnugDock in version 3.10 works.

So I don't really now if it's some kind of bug, but the protocol only works if the structures in the ensemble1 list have first heavy chain instead of light chain. All the protocols say otherwise. Also I don't know how much it will influence the result, since both the input file given by -s flag and the -partners LH_A flag say that the order of chains should be the inverse (first light and then heavy).

I tested both Rosetta 3.10 Release date: Tuesday, October 2, 2018 and Rosetta 2018.44 Release date: Wednesday, November 14, 2018



Wed, 2018-11-28 08:07