Advice on Parameterizing N-Terminal Pyroglutamate for FlexPepDock

[LTosh124]

Hi,

I am fairly new to using Rosetta and looking for some advice. I would to incorporate the N-Terminal NCAA pyroglutamate into some FlexPepDock runs. Therefore, I am looking to parameterize this residue.

I understand that parameterisation of proline-like N-cyclic amino acids has not been supported in the past, i.e with MakeRotLib. So, I am wondering if anyone can suggest the best practice when dealing with these residues? Would I be able to use Proline as the parent?

Thanks in advance :)

[roccomoretti]

While MakeRotLib might not work well with cyclic acids, I think (but have not tried) that the FakeRotLib" (https://doi.org/10.1021/acs.jcim.5c01030) approach might be able to handle them.

After the generation of rotamers, one limitation may be the enforcement of the ring closure under rotatable bond. The closure geometry for proline is likely not to be idea, given the gamma carbon is sp2 versus sp3, but you may be able to use cart_bonded (without pro_close) and have things work properly. (Alternatively, there's a ring_close term which should work with any residue type with a VIRTUAL_SHADOW designation in the params file.)

It's possible you'll run into issues while attempting to implement things -- please let us know if you come across any errors, and we'll hopefully be able to help debug them.

[LTosh124]

Dear @roccomoretti,

Thank you so much for your guidance on this. I have attempted using the FakeRotLib protocol for the parameterisation of the pyroglutamate residue (5-oxoproline) as well as some other NCAA (including 4-oxoproline).

The protocol is successful for 4-oxoproline and several other NCCAs I have tested, but fails specifically for pyroglutamate. The error occurs when fake_rotlib.py launches the molfile_to_params_polymer.py as a subprocess which then calls polymer_functions.py to assign the Greek letter names to the atoms. At this stage, a TypeError is raised due to a floating value rather than the required and expected integer:

Traceback (most recent call last):
File ".../molfile_to_params_polymer.py", line 217, in main
polymer_assign_pdb_like_atom_names_to_sidechain( m.atoms, m.bonds, args.peptoid )
File ".../polymer_functions.py", line 187, in polymer_assign_pdb_like_atom_names_to_sidechain
a.pdb_greek_dist = greek_alphabet[all_all_dist[ca_index][i]]
~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^
TypeError: list indices must be integers or slices, not float

I suspect this may be due to the cyclic amide bond (forming the lactam ring) and proximity of the carbonyl to the backbone, which breaks the assumptions of how backbone and sidechain atoms are separated. However, please correct me if this interpretation is incorrect.

If you have any idea of solutions for addressing this issue or an alternative method for parameterisation of pyroglutamate, your advice would be greatly appreciated.

Thank you in advance,

Lily

[willsheffler]

Thanks for the detailed report — your interpretation is probably close.

What is happening here is that polymer_assign_pdb_like_atom_names_to_sidechain() computes graph distances with Dijkstra, but the distance matrix is initialized with 1e100 and therefore comes back as floats. For most residues the reachable sidechain atoms get values like 1.0, 2.0, etc., which Python 2 tolerated more loosely in some contexts, but in current Python the line

a.pdb_greek_dist = greek_alphabet[all_all_dist[ca_index][i]]

fails because list indices must be integers, not floats. So the immediate bug is the float indexing, not specifically pyroglutamate chemistry.

That said, pyroglutamate is likely exposing a second issue too: the code was written with fairly simple backbone/sidechain separation assumptions, and a cyclic N-terminal lactam is exactly the kind of case where those assumptions can get shaky.

Two things I would try:

1. Patch the script locally so the Greek-distance lookup uses an integer, e.g.

   a.pdb_greek_dist = greek_alphabet[int(all_all_dist[ca_index][i])]

   (and similarly the peptoid branch with int(...)-1 as appropriate).

2. If that gets you past this error but naming/topology is still wrong, then the next place to inspect is the neighbor construction in the same function — it excludes atoms tagged as backbone, and pyroglutamate may be causing an unexpected pathing/naming situation because the ring closes back near the backbone.

So in short: yes, pyroglutamate may well be violating the residue-shape assumptions, but the traceback you showed points first to a small Python compatibility bug in the naming code.

If you want, I can also put together a minimal Rosetta-side fix/PR for this so the script handles these cases more robustly.

[roccomoretti]

N.B. From other messages, it looks like this message may be from Will's AI agent going rogue. That said, I don't notice anything objectionable in this message.

[JHLubin]

Also note that fake_rotlib will not add the virtual atoms for ring closure. For an example, you can look at the cyclohexyl glycine params <https://github.com/RosettaCommons/rosetta/blob/main/database/chemical/residue_type_sets/fa_standard/residue_types/l-ncaa/cyclohexyl-glycine.params>--you can add two virtual atoms, their bonds, virtual shadows, and internal coordinate lines. My understanding is that even with the virtual closure, not all protocols handle it right--I'm mostly using Cartesian FastRelax. You also want to check that the internal coordinate descriptions of your ncAA are reasonable (particularly which atom is referenced for the dihedral). molfile_to_params_poly is far from perfect. A common issue is defining hydrogen positions in terms of a linear set of atoms, rather than an improper dihedral (for example, having the N-terminal H defined relative to N-CA-C instead of N-LOWER-CA), which can lead to unrealistic geometries. A general note: parametrizing ncAAs remains a consistent pain point, even with fake_rotlib making it less odious.

…

On Thu, Apr 2, 2026 at 10:32 AM Rocco Moretti ***@***.***> wrote: N.B. From other messages, it looks like this message may be from Will's AI agent going rogue. That said, I don't notice anything objectionable in this message. — Reply to this email directly, view it on GitHub <#602?email_source=notifications&email_token=AD6PZS265DGE623LYYBKV334TZ2XJA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCNRUGI2DENJVUZZGKYLTN5XKU43VMJZWG4TJMJSWJJLFOZSW45FMMZXW65DFOJPWG3DJMNVQ#discussioncomment-16424255>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AD6PZS77VE24UOHEYNHYCJ34TZ2XJAVCNFSM6AAAAACRKOFV7SVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTMNBSGQZDKNI> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.*** com>