# Using NCAAs in protocols with native heme proteins

3 posts / 0 new
Using NCAAs in protocols with native heme proteins
#1

Hello Rosetta Community!

I'm writing to you with previous knowledge and use of Rosetta, but very little experience troubleshooting anything outside of symmetric docking. Currently, I'm attempting to run a relax protocol on a native protein with four heme ligands and mutated CYS residues. To do this, I'm running the included Rosetta Scripts xml file using a scored version of 1TGU without hemes. I previously had followed the documentation for creating and implementing NCAA use (in this case, cysteine persulfide) in Rosetta, and obtained the included .params and used the .rotlib options file for said operations. However, when attempting to run the Rosetta Scripts protocol (using mm_std.wts), I obtain the following error:

core.pack.rotamers.SingleNCAARotamerLibraryCreator: Number of chi mismatch. Expected 3 rotatable heavy atom chis, found 2

ERROR:: Exit from: src/core/pack/rotamers/SingleNCAARotamerLibraryCreator.cc line: 67

I'm not sure if there's an error with how I'm creating the options files, or an issue with how the final rotlibs are in Rosetta themselves.

// On a side note, I also realize that since the native protein has hemes, using the score function mm_std will result in an error because of missing torsions. Is there any way to read the native protein with the hemes and still use the NCAA rotamer libraries, or would I be better off removing the heme from the protocol entirely? The reason I ask is because the mutations seem to be causing conformational changes (experimentally shown), and I feel the hemes may be important to keep in regards to that (?). I have already developed the heme parameters and used them in scoring, so that isn't a problem.

Any help will be appreciated!

Best,

Héctor

AttachmentSize
1.86 KB
909 bytes
686 bytes
Post Situation:
Wed, 2018-01-24 08:32
htorres

The issue is that in your params file you have three chis defined, but are saying that one of them is a PROTON_CHI. Proton chi sampling is handled outside the rotamer library formulism, so the PROTON_CHIs aren't counted in the number of chis present in the sampled library.

How you have your PROTON_CHI doesn't make sense, anyway - right now you have it set as CHI 1, which is your N-CA-CB-SG chi -- which is probably not what you want. Instead, you probably want PROTON_CHI 3 ..., as your CHI 3 is the CB-SG-SD-1HD  chi.

That won't fix your problem, as you'll only have two non-protein chis, whereas your rotamer library specification is set up for three (non-proton) chis. There's two possible ways to fix it. The first is just to remove the PROTON_CHI designation completely, classifying the CB-SG-SD-1HD  chi as a "non-proton" chi. (The proton chi designation is one of sampling -- you don't necessarily need to have all chis involving protons be "proton chis".) -- A potential problem with that, though, is if you have any chemical connectivity to that SD atom, you'll remove the attached proton and thus the chi, leading to potential issues. The other issue is that, depending on how you did it, your rotlib generation may not have sampled that degree of freedom appropriately enough to count it as a full-blown chi.

Your other option is to re-do your rotlib such that you're only recording the parameters for the heavyatom chi samples, ignoring the 1HD positional variability. Then you can use that rotlib with the `PROTON_CHI 3 ...-adjusted params file, with an appropriately adjusted NCAA_ROTLIB_NUM_ROTAMER_BINS line.

Tue, 2018-01-30 08:21
rmoretti

Ah, that makes sense. Thank you very much Rocco! While I waited for an answer, I also decided to see how the calculations would run using the ROTAMER_AA params file line on the cysteine persulfide using CYS residues, just to see how Rosetta would treat that.

I had used the scripts for param file generation quite like a black box, and I see how that acted against my favor. I'll get the chi issue fixed asap. Much obliged!

Mon, 2018-02-05 06:53
htorres