auto_setup_metals flag with loop modeling application fails

Member Site Forums Rosetta 3 Rosetta 3 – Applications auto_setup_metals flag with loop modeling application fails

Viewing 3 reply threads
  • Author
    • #2210

        I’m trying to make a homology model for a Zn-binding metalloenzyme based on some other members of the same family that have been crystallized. My general strategy has been to do comparative modeling first with limited redesign of the loops to get the main structural features in place, and then use the loopmodel appliation to refine the structure a bit more. I had trouble incorporating the Zn residue into the comparative modeling application, so I inserted the Zn into the PDB result and now I’m trying to include it in the loop modeling step.

        So far, I can get something fairly representative by manually including constraint files to define the Zn placement; however, I want to use the auto_setup_metals flag if I can as I imagine it might be more effective. In the fullatom state, the flag appears to recognize the correct binding residues (the connections are correct in the sequence), but the application crashes shortly after because I believe it is trying to include the newly named residue types in the centroid stage. I have been probing the options and code a bit and I haven’t been able to find why it’s switching to centroid in this order. Kind of hard to describe I think, so I attached the output of the loopmodel debug application. The relevant section is here: 

        protocols.looprelax: ==== Loop protocol: =================================================
        protocols.looprelax: remodel no
        protocols.looprelax: intermedrelax no
        protocols.looprelax: refine refine_kic_with_fragments
        protocols.looprelax: relax no
        protocols.evaluation.ChiWellRmsdEvaluatorCreator: Evaluation Creator active ...
        core.chemical.ResidueTypeSet: Finished initializing centroid residue type set. Created 1042 residue types
        can not find a residue type that matches the residue HISND1_connectat position 54
        ERROR: core::util::switch_to_residue_type_set fails
        ERROR:: Exit from: src/core/util/ line: 323


        Anyone happen to know why it’s trying to initialize the centroid residue type set, and why it thinks the HISND1_connect is in the sequence even though that should be the fullatom sequence (I think)? Any advice would be appreciated! 


        I attached a debug run log, the input PDB file, and flags file to this post. Thanks!


        *edited to change the reference to the flag from auto_setup_ligands to the correct auto_setup_metals

      • #11059

          Hi, there:

          I implemented the -auto_setup_metals feature. Unfortunately, it currently only works will all-atom structures. Part of the problem is that it keeps track of the detailed geometry of the metal-binding atoms in the metal-binding residue (the bond distance and bond angles to the delta or epsilon nitrogens of histidine, for example), and all of those atoms vanish when you switch to centroid mode, to be replaced by a single big pseudo-atom. This means that there’s not really any sensible way of preserving the geometric information that -auto_setup_metals aims to preserve.

          I’m less familiar with the remodel-based loop refinement. If there is an option for using remodel exclusively in fullatom mode, that would be what you’d need to use. Alternatively, you could do one of the following:

          — Use a loop modelling protocol that’s designed for full-atom modelling, such as GeneralizedKIC.
          — Use an alternative means of coordinating your metal, such as a virtual zinc atom with manually-defined constraints.

        • #11061

            Hi vmulligan, thanks very much for your help.

            That makes a lot of sense actually — I was slowly coming to a similar realization when I was hacking my way through debugging; I saw it was changing the pose to centroid mode within the LoopRelaxMover, and it wasn’t able to successfully switch, since the modified residues of the pose (HISND1_connect, CYSSG_connect, etc) aren’t recognized while in centroid mode it seems. I was trying to figure out if there was any way to make it better handle those residues, but based on your comment I’m thinking it’s definitely a bad idea… even if I did somehow trick Rosetta into converting the pose to centroid despite its better judgement, the loss of the geometry information would basically render the whole thing pointless. Sounds like sticking to a fullatom protocol would be far better. I’ll have to give GeneralizedKIC a try!

          • #11062

              Actually, what’s interesting is that I’m skipping the loop-remodel stage here, and only doing loop-refine. Now that I think about it, I did that so I would keep it in fullatom mode precisely for that reason. I’m wondering if maybe it shouldn’t be getting converted after all? I’ll have to take a look again…

          Viewing 3 reply threads
          • You must be logged in to reply to this topic.