MakeRotLib inquiry

[MuhammadAttaElhamouly]

Good day,
I'm working on the incorporation of NCAA into Rosetta, params files were successfully prepared, but in the process of using the MakeRotLib.default.linuxgccrelease application for preparing the rotlib file it gave me the following error message:

ERROR: The residue FFF_p:MethylatedCtermProteinFull_p:AcetylatedNtermProteinFull could not be generated. Has a suitable params file been loaded? (Note that custom params files not in the Rosetta database can be loaded with the -extra_res or -extra_res_fa command-line flags.)
ERROR:: Exit from: src/core/chemical/ResidueTypeSet.cc line: 116

Note that the NCAA I'm trying to incorporate have a substitution on the backbone Nitrogen atom, that's why it gives me this message there's no H atom, core.chemical.MutableResidueType: [ ERROR ] atom name : 'H' not available in residue FFF

Furthermore, I tried to recall all the options for this specific application but I didn't find a reliable solution,

Thanks in advance.

[roccomoretti]

Unfortunately, the issue is the fact that MakeRotLib wants to work on residues with acetylated N-termini. If you have a residue without an acetylatable N-term, then you have bigger issues.

But if you have a nominally acetylatable N-terminus, (e.g. something like Proline), then the issue you're running into is that the AcetylatedNtermProteinFull patch is not robust enough to handle it. What you need to do is provide your own patch file which overrides the default provided one.

One way to do that would be to copy the rosetta/database/chemical/residue_type_sets/fa_standard/patches/AcetylatedProteinNterm.txt file to your working directory. Then edit the file with a text editor. What you'll want to do is go to the bottom and find the block which is labeled "general case". Duplicate that block (everything between the BEGIN_CASE and END_CASE tags). Now edit the first copy of the block. Add a NAME3 FFF line between the BEGIN_SELECTOR and END_SELECTOR lines. Then remove the SET_ANCESTOR H GREATGRANDPARENT CO line (which is causing the problem).

Then you would need to tell Rosetta to use that patch definition. You can do this by adding -extra_patch_fa MyAcetylatedProteinNterm.txt to the command line.

I think that should get you most of the way there, though there may be some modifications you may want to make. (If you're feeling fancy, you can compare the SET_ICOOR lines of the general case and the AA PRO case. You can also use the restype_converter app to output the PDB and params files corresponding to the patched type -- just specify the fully patched name (e.g. FFF_p:MethylatedCtermProteinFull_p:AcetylatedNtermProteinFull ) to the -restype_convert:types option and don't forget to include the -extra_res_fa and -extra_patch_fa options.)

[MuhammadAttaElhamouly]

By following your guidance I have tried it with FFF params alongside generating a proline params file to testify it, it worked for the FFF.params, but for proline, it generated a rotamer library that has unrealistic torsion angles, it might be because of the makerotlib_options.in

I made the sampling as follows, " which I'm not sure if it is correct or not "

AA_NAME PRO_T
OMG_RANGE 180 180 1
PHI_RANGE -180 180 10
PSI_RANGE -180 180 10
EPS_RANGE 180 180 1
NUM_CHI 3
NUM_BB 2
CHI_RANGE 1 0 330 30
CHI_RANGE 2 0 330 30
CHI_RANGE 3 0 330 30
CENTROID 27.3 1 -34.5 1 27.8 1
CENTROID -25.1 2 36.3 1 -32.7 1
TEMPERATURE 1

Thanks for your precious guidance.

[roccomoretti]

I checked with someone who has done some MakeRotLib work recently, and he didn't see any issues with your makerotlib_options.in file.

The one issue that was mentioned was that if you're working with a Proline-like residue, then you may have issues with the ring closure not being properly represented. There's some special casing of proline ring closure which may or may not be present for your residue. If you're missing the ring-closure constraints, your rotamer library could be different due to the ring-open rotamers which theoretically could be generated. Unfortunately, there isn't necessarily a good general-purpose way of handling proline-like ring closure.

[everyday847]

Yes, the reason fundamentally is that you're generating a bunch of rotamers with broken rings, and while it's totally possible the mm energy function used in makerotlib (which you can customize!) could account for the break, really bad geometries can be hard to minimize.

I would suggest some other mechanism to build valid ring conformers and then evaluate the energies of protein backbones on those conformers.

[vmullig]

Note that Rosetta does have a general alternative to the pro_close scoreterm, called ring_close. You need to define shadow virtual atoms in your params file, like proline has, but then adding ring_close to the mm_std energy function should keep the ring closed.

…

On Wed, Jul 10, 2024, 9:13 PM Andy Watkins ***@***.***> wrote: Yes, the reason fundamentally is that you're generating a bunch of rotamers with broken rings, and while it's totally possible the mm energy function used in makerotlib (which you can customize!) could account for the break, really bad geometries can be hard to minimize. I would suggest some other mechanism to build valid ring conformers and then evaluate the energies of protein backbones on those conformers. — Reply to this email directly, view it on GitHub <#75 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABACZUFLYNQ2RICSODATST3ZLXL23AVCNFSM6AAAAABKBV5GV2VHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTAMBRGU2TSOA> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.*** com>

[everyday847]

Right; critically, neither is the default score function for MakeRotLib -- and more concerningly, if your starting conformations are too screwed up, minimization may fail to rescue them.

[dougrenfrew]

In the original NCAA paper, MakeRotLib was not used to generate rotamers for the proline-analogs (the ring sampling code was not added till later). Separate params files were made for each ring conformation/pucker; this was also done for the side chains with cyclo-hexyl or cyclo-pentyl rings.

[everyday847]

Even now, for better or for worse, we have unified params files for the NCAAs but sampling (of ring chis) is handled by the aliphatic ring conformer code. For cyclohexylalanine, for example, you get the Cartesian product of cyclohexane ring conformers and chi1 rotamers.

[MuhammadAttaElhamouly]

@everyday847

If there are more details about cyclohexylalanine, cyclopentylalanine, beta-beta-dicyclohexyl-alanine I would be grateful for it..

I had opened a new discussion about it #119 before I wrote this reply

The params file of this amino acid includes both the rotamer library and ring puckering.

My inquiry is, while making the rotamer library, is the application changing the ring pucker while sampling the different dihedral angles, as changing the ring conformation will defiantly favour one angle over another, resulting in different probabilities for the rotamer bins, and a chain of consequal effect of any further calculation.

I tried to make a test of making rotlib for different params, the original one with Chi angles included along with adding the ring pucker, and another params have only the Chi, the generated rotamer libraries are the same in both situations, which could say that the makerotlib application isn't including puckering of the ring while making rotlib.

Any documentation about that would be appreciated.

[everyday847]

Noncanonical rotamer libraries are just intended for sampling, not scoring, so we just build the combinations and let the score function decide.

[MuhammadAttaElhamouly]

Grateful for your precious contribution.

[roccomoretti]

Marking this as "closed", as it sounds like your question has been answered. If that assessment is incorrect, feel free to re-open or open up a new discussion with more details.

[vmullig]

Noncanonical rotamer libraries are just intended for sampling, not

scoring, so we just build the combinations and let the score function decide. Note that this is no longer the case. The fa_dun scoring term will compute scores from a non-canonical rotamer library just as it would for a canonical rotamer library. (It actually does things a bit more elegantly for non-canonicals than for canonicals, using a Voronoi well boundary partition.) The question is only whether one has good energies in the rotamer library. If generated with mm_std, they'll be okay, but not great. We're now working on the RosettaQM paper, which includes means of doing this by a full quantum chemistry calculation in MakeRotlib.Message ID: ***@***.*** com>

…

[MuhammadAttaElhamouly]

I read about the project you are working on in collaboration with Brown Lab, and it’s quite fascinating. I'm thrilled to get hands-on with this new approach and try it out.

I was concerned about the quality of the rotlib I was generating, so I recently started working on generating rotlib by relying on quantum mechanical energy calculations of individual residues ( not a whole project for Rosetta). However, due to time constraints, I initially shifted to using the conventional MM_STD approach. I will give it a try if I have more time.

[everyday847]

That's half right. My description of the intention, which is what I described, is accurate. When the rotlibs under discussion were created, the intention was not for them to be used with fa_dun.

It is absolutely true that they could additionally be used for scoring with fa_dun (that possibility has been around for many years), but -- since they were not created with that application in mind -- I wouldn't suggest it. Some counterfactual rotamer library, created with scoring in mind -- that might be a good idea.

[MuhammadAttaElhamouly]

Got it, so is there any recommendation to take it in effect for making a rotlib for amino acid that can be scored with fa_dun?

[roccomoretti]

fa_dun take the probabilities (both the probability of the rotamer well as well as the standard deviation of the spread within the rotamer well) and converts them into energies. So long as the rotamer well probability values and the well standard deviation parameters are well-formed, the fa_dun energies should be calculated reasonably.

[vmullig]

Ah, gotcha. Yes, treat scores from fa_dun with existing rotamer libraries with a BIG grain of salt.

…

On Thu, Aug 15, 2024 at 3:55 PM Andy Watkins ***@***.***> wrote: That's half right. My description of the intention, which is what I described, is accurate. When the rotlibs under discussion were created, the intention was not for them to be used with fa_dun. It is absolutely true that they could additionally be used for scoring with fa_dun (that possibility has been around for many years), but -- since they were not created with that application in mind -- I wouldn't suggest it. Some counterfactual rotamer library, created with scoring in mind -- that might be a good idea. — Reply to this email directly, view it on GitHub <#75 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABACZUDLVFIHNNXBKTXLOFTZRUBRLAVCNFSM6AAAAABKBV5GV2VHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTAMZVGE4TSOA> . You are receiving this because you commented.Message ID: ***@***.***>