You are here


15 posts / 0 new
Last post

I am currentlt working with implementing saxs into the docking protocol. The only reference I have found is “Determination of the structures of symmetric protein oligomers from NMR chemical shifts and residual couplings” by Nikolaos G. Sgourakis et. Al.
Basically I have added the lines:

-score:saxs:ref_spectrum saxsdatafile.dat
-score:weights docking.wts

where I have copied the docking.wts file to my own directory and added the line
fastsaxs 2.5

I can get it to run using input data created using crysol and converted to nm-1. But when adding the third row with the error estimate the protocol almost goes to a halt. Following error message appears:
core.scoring.saxs.FastSAXSEnergy: [ WARNING ] Input data extends to higher resolution than stored structure factors (1.33A)
core.scoring.saxs.FastSAXSEnergy: Results may be inaccurate!

though the simulation keeps going albeit extreemly slow. Trying to change the input to angstrom does not change the picture.

I would like to know the meaning of fastsax 2.5 amd the input for the simulation...


Post Situation: 
Mon, 2013-07-22 07:29

The "fastsaxs 2.5" line in the weights file is setting the weight (importance) of the fastsaxs term in relation to the other score terms. I've been told that a weight of 2.5 seems high. The recommendation is to use a weight of 1.0 or less - you'll probably get better structures that way.

Regarding the format of the -score:saxs:ref_spectrum file, it's a simple line-based format, with three entries per line: q_k, i_obs_k, i_sig_k, space separated, in that order. All three are expected to exist. If they don't, or aren't properly formatted as numbers, the protocol isn't going to work as expected. See rosetta_tests/integration/tests/RescoreSAXS/gb3_Apr06.dat for an example file.

Also, look at the number of data points in your ref_spectrum file. Because the fastsaxs energy method needs to do a Fourier transform each time it scores the structure, a small increase in the number of datapoints can result in a great slowdown. If you could safely subsample your input SAXS data, you can speed up your runtime.

Mon, 2013-07-22 11:27

Thank you very much!
The /RescoreSAXS/gb3_Apr06.dat does not appear in my library (Rosetta3.4).
Any chance you could send it to me or post it here?

Tue, 2013-07-23 02:19
Tue, 2013-07-23 02:49

I have my input datafile in angstrom and an error estimate, that is similar to that of the the one referred to above, with reduced datapoints as recommended and I do get the program running. Very very oddly the output structures from the docking are pretty far from docked, that is Rosetta seem to be moving the protein to be docked far away from the input structure and an error message of

core.pack.task: Packer task: initialize from command line()
protocols.geometry.RB_geometry: centroids_by_jump_int called but no interface detected!!

core.optimization.LineMinimizer: Inaccurate G! step= 2.44141e-06 Deriv= -3.30229 Finite Diff= 1.82743

pops up over and over again.
The protein complex has been prepacked using the prepack protocol.
The protocol works nicely without the saxs scoring.

I am using the score weight file docking.wts which I assume is the one used for docking. I have tried using score12, score12_full (as in above reference) but they do only give bad results in termes of interface energy.

The script is as following:


-database $dirdata
-in:file:s test.docking.pdb
-nstruct 200 #(test structure pool)
-partners A_B
-dock_pert 3 8
-score:saxs:ref_spectrum test.dat
-score:weights docking.wts #added the line fastsaxs 1 (tried with 2.5 and 0.5)
(-score:saxs:q_min 0.01 -score:saxs:q_max 0.5 -score:saxs:q_step 0.1) #these flags do not seem to make a difference using these numbers. guessing they are default
-unboundrot $dirunboundrot

\mv -f
\mkdir Docking
\mv test.docking_*.pdb Docking

Do appreciate any help!!!


Tue, 2013-07-23 08:45

The defaults for q_min, q_max, and q_step options appear to be 0.01, 0.25 and 0.01, respectively. I don't know how sensitive the results are to those settings though. (BTW, the description of these options are the "minimum/maximum/step of q used in spectra calculations (in [A^-1])")

The no interface detected warning in itself isn't critical, but it does indicate that your bound complex is coming apart. The fact that it doesn't come apart without the saxs indicates that there is something about the saxs score that's not liking the complex. (When you used the score12 energies, did you get complex separation with the saxs score turned on?) Having a complex blow apart with saxs scores on is not entirely unexpected (SAXS gradients can be rather sensitive.) Rescore the complex and the separated proteins. Is the SAXS score higher for the complex? One possibility to try is to keep turning down the saxs weight until you no longer get complex separation.

Regarding scorefunction to use, score12 is usually the default scorefunction to use (at least with the released versions), and most of the work has been done with the score12 scorefunction. For example, all of the SAXS monomer work was most likely done with score12. (There's no practical difference between score12 and score12_full). It's the scorefunction you'd want to use, unless you have compelling reason not to. -- The fact that the docking protocol specifically uses the docking.wts weights is probably such a compelling reason.

Tue, 2013-07-23 12:23

So basically it seems to be working now. The problem appeared to b the input SAXS data file which need to be weighted according to 1 mg/ml which apparently it is not when using crysol with default values.
The complex does not come apart and when scoring the complex I get a saxsscore of ~ 0.005 with fassaxs set to 0.2 which I guess is reasonable.

The energy weight need to be 'docking' as the 'score12' generally score out of range (interface energies) and does not get the correct structure.

When rescoring I am using following script:


$direxe/score.linuxgccrelease -database $dirdata -in:file:s test.pdb -score:saxs:ref_spectrum test.dat -score:weights docking.wts

The rescoresaxs application does not exist in my library..
But when using the score application this following "odd" error appears:

core.scoring.saxs.FastSAXSEnergy: Loading SAXS spectrum
core.scoring.saxs.FastSAXSEnergy: [ WARNING ] Input data extends to higher resolution than stored structure factors (1.33A)
core.scoring.saxs.FastSAXSEnergy: Results may be inaccurate!

As my data file extends to 0.5 å^-1, which would be 2 A, do I need to cut my data for better evaluation?

Thank you for your response!

Tue, 2013-07-30 01:34

I talked with someone who does SAXS stuff, and he said he doesn't use rescoresaxs, using the score application directly (like you just did).

He also isn't concerned by the warning message. As I understand it, it's telling you that the results will not be as accurate as you might have anticipated given the input data you supplied, but *not* that the results based on the input data actually used is inaccurate.

Thu, 2013-08-01 11:38


I have a question somehow related to this discussion thread. I am also doing some saxs-score weighted docking study with Rosetta 3.8 and my saxs data extends to 0.4 A^-1.

I tried to set q_max = 0.4 but this WARNING appears:  (The script runs fine, just get the same result as using default q_max=0.25 )

protocols.jd2.JobDistributor: WARNING: The following options have been set, but have not yet been used:
    -score:saxs:q_max 0.4

Did I use a wrong format or set something wrong?





Thu, 2018-05-03 01:08

The -score:saxs:q_max option is only used for the `saxs_score` term (and then only with the -score:saxs:q_min and -score:saxs:q_step options to determine the sampling scope). The `fastsaxs` scoreterm doesn't use it, using a slightly different input file format.


Fri, 2018-05-18 12:35


Sorry to dig out this old discussion...I tried to search the q_max and q_min terms for fastsaxs in "" but couldn't find it. Does anyone know where I can find those terms for the fastsaxs score term? Thank you.


Wed, 2021-05-19 01:38

Are you able to find the -score:saxs section? (

q_max/q_min are the 12th & 13th entry in that section (3rd and 4th from the bottom):


-q_min <Real>
minimum value of q used in spectra calculations (in [A^-1])
Default: 0.01
-q_max <Real>
maximum value of q used in spectra calculations (in [A^-1])
Default: 0.25
Wed, 2021-05-19 06:14


Yes, I found those terms. But in the previous discussion you said

"The -score:saxs:q_max option is only used for the `saxs_score` term (and then only with the -score:saxs:q_min and -score:saxs:q_step options to determine the sampling scope). The `fastsaxs` scoreterm doesn't use it, using a slightly different input file format."

I was wondering what that "slightly different input file format" is... (Or what option I should use for q_max/q_min for fastsaxs) Thank you.




Wed, 2021-05-19 20:54

Hi everyone,

Sorry to bring this topic out again...does anyone know the options I should use for q_max/q_min for fastsaxs?

I tried  -score:saxs:q_min and -score:saxs:q_max but this error appears:

protocols.jd2.JobDistributor: WARNING: The following options have been set, but have not yet been used:
    -score:saxs:q_max 0.4

Thanlks! Any help would be greatly appreciated...



Thu, 2021-06-10 02:23

Fastsaxs doesn't use those values ... as in there's nothing to replace them with, as they're simply not adjustable parameters for the fastsaxs method. (Fastsaxs is using a different version of the calculation, where the min & max apparently doesn't matter.

Also note that's a warning message, rather than an error. Your run has proceeded and completed as if that option was never actually provided on the command line.

Mon, 2021-06-14 12:56