rosettaCM not recognizing Mn atom

[Anonymous]

hi i am running rosettaCM with a protein which has a ligand and a heavy atome molecule, MN.

I input a params file for the ligand which rosetta sees ok, but it gives an error saying that MN is unrecognized residue.

I confirmed that MN.params file is in the right directory and the the txt file which specifies residues has the MN in it.

I also tried to input the MN.params file directly using -extra_res_fa flag but the error remains.

is metal ions not allowed when running rosettaCM? thanks.

[Anonymous]

Off the top of my head, check the spacing.  If the spacing in the PDB file is “-MN-” and the spacing in the params file is “–MN”, Rosetta won’t recognize one as the other.  This has been a moderately common problem with monatomic metal ions.

You should also try changing it to some other metal ion to see if that works instead.

[Anonymous]

The other issue might be that the Mn atom is not being recognized during centroid mode stages. Try passing the params file to ‘-extra_res_cen‘ and see if that fixes things.

[Anonymous]

I am having a similar problem.

I am attempting to model an enzyme with an Fe(2+) ion. I generated the hybrid structures, added the Fe ion from the template structure, and obtained the FE2.params file from the ROSETTA database to place in my active directory. I passed the FE2.params file to both -extra_res_cen and -extra_res_fa, but when I run rosettaCM, I get the following error:

[ERROR]  EXCN_utility_exit has been thrown from: src/core/chemical/AtomTypeSet.cc line: 162

ERROR: unrecognized atom_type_name ‘Fe2p’

I tried changing the spacing of the ‘FE’ in the PDB file in case that was the issue, but each time I get the same error.

Any ideas?

 

 

[Anonymous]

I am having a similar problem.

I am attempting to model an enzyme with an Fe(2+) ion. I generated the hybrid structures, added the Fe ion from the template structure, and obtained the FE2.params file from the ROSETTA database to place in my active directory. I passed the FE2.params file to both -extra_res_cen and -extra_res_fa, but when I run rosettaCM, I get the following error:

[ERROR]  EXCN_utility_exit has been thrown from: src/core/chemical/AtomTypeSet.cc line: 162

ERROR: unrecognized atom_type_name ‘Fe2p’

I tried changing the spacing of the ‘FE’ in the PDB file in case that was the issue, but each time I get the same error.

Any ideas?

 

 

[Anonymous]

I am having a similar problem.

I am attempting to model an enzyme with an Fe(2+) ion. I generated the hybrid structures, added the Fe ion from the template structure, and obtained the FE2.params file from the ROSETTA database to place in my active directory. I passed the FE2.params file to both -extra_res_cen and -extra_res_fa, but when I run rosettaCM, I get the following error:

[ERROR]  EXCN_utility_exit has been thrown from: src/core/chemical/AtomTypeSet.cc line: 162

ERROR: unrecognized atom_type_name ‘Fe2p’

I tried changing the spacing of the ‘FE’ in the PDB file in case that was the issue, but each time I get the same error.

Any ideas?

 

 

[Anonymous]

thanks steven but i am using the right spacing

[Anonymous]

bingo. thanks!

[Anonymous]

Hey Rocco,

I am having a similar problem trying to model a protein-protein complex which contains two Zn metal ions with RosettaCM. I am using the Rosetta3.8 release on dors, and when I run ../rosetta_scripts.default.linuxgccrelease @flags I get “Expected file: /path/to/Rosetta/main/database/chemical/residue_type_sets/centroid/shadow_list.txt” with a segfault. I have the “in:file:extra_res_cen” flag turned on, and I’ve tried directly specifying where the params are using “extra_res_path”. I have also played around with the spacing in my PDB file with no luck (I attached a truncated version of the PDB file). Any recommendations?

Thanks a lot,

Ben

[Anonymous]

Hey Rocco,

I am having a similar problem trying to model a protein-protein complex which contains two Zn metal ions with RosettaCM. I am using the Rosetta3.8 release on dors, and when I run ../rosetta_scripts.default.linuxgccrelease @flags I get “Expected file: /path/to/Rosetta/main/database/chemical/residue_type_sets/centroid/shadow_list.txt” with a segfault. I have the “in:file:extra_res_cen” flag turned on, and I’ve tried directly specifying where the params are using “extra_res_path”. I have also played around with the spacing in my PDB file with no luck (I attached a truncated version of the PDB file). Any recommendations?

Thanks a lot,

Ben

[Anonymous]

Hey Rocco,

I am having a similar problem trying to model a protein-protein complex which contains two Zn metal ions with RosettaCM. I am using the Rosetta3.8 release on dors, and when I run ../rosetta_scripts.default.linuxgccrelease @flags I get “Expected file: /path/to/Rosetta/main/database/chemical/residue_type_sets/centroid/shadow_list.txt” with a segfault. I have the “in:file:extra_res_cen” flag turned on, and I’ve tried directly specifying where the params are using “extra_res_path”. I have also played around with the spacing in my PDB file with no luck (I attached a truncated version of the PDB file). Any recommendations?

Thanks a lot,

Ben

[Anonymous]

The issue is likely that the Centroid mode atom types don’t include the ‘Fe2p’ type. (While certain types are shared between full atom and centroid mode, there are type differences.)

My suggestion would be to make a copy of the FE2.params file for centroid mode, and change the ‘Fe2p’  (not a centroid atom type) to ‘Fe3p’ (which is). That should prevent crashing. The difference in typing should be dwarfed by the intrinsic inaccuracies in centroid mode, so I wouldn’t worry about it too much.

[Anonymous]

The issue is likely that the Centroid mode atom types don’t include the ‘Fe2p’ type. (While certain types are shared between full atom and centroid mode, there are type differences.)

My suggestion would be to make a copy of the FE2.params file for centroid mode, and change the ‘Fe2p’  (not a centroid atom type) to ‘Fe3p’ (which is). That should prevent crashing. The difference in typing should be dwarfed by the intrinsic inaccuracies in centroid mode, so I wouldn’t worry about it too much.

[Anonymous]

The issue is likely that the Centroid mode atom types don’t include the ‘Fe2p’ type. (While certain types are shared between full atom and centroid mode, there are type differences.)

My suggestion would be to make a copy of the FE2.params file for centroid mode, and change the ‘Fe2p’  (not a centroid atom type) to ‘Fe3p’ (which is). That should prevent crashing. The difference in typing should be dwarfed by the intrinsic inaccuracies in centroid mode, so I wouldn’t worry about it too much.

[Anonymous]

Hi Rocco,

I get the same error with ‘Fe3p’.

If I scroll up before the error I also get this line:

core.chemical.ResidueTypeSet:     Expected file: /home/derekjs/storage/ROSETTAXXX/main/database/chemical/residue_type_sets/centroid/shadow_list.txt

When I cd to this dir_ectory I the file ‘shadow_lists.txt’ is missing. I copied it in from fa_standard and still the same error.

Also, I tried using the FE.params instead of FE2.params (while renaming the FE in the PDB file) and still get the same error.

If I change the metal ion to MN, and use the relevant files, the program begins to run.

[Anonymous]

Hi Rocco,

I get the same error with ‘Fe3p’.

If I scroll up before the error I also get this line:

core.chemical.ResidueTypeSet:     Expected file: /home/derekjs/storage/ROSETTAXXX/main/database/chemical/residue_type_sets/centroid/shadow_list.txt

When I cd to this dir_ectory I the file ‘shadow_lists.txt’ is missing. I copied it in from fa_standard and still the same error.

Also, I tried using the FE.params instead of FE2.params (while renaming the FE in the PDB file) and still get the same error.

If I change the metal ion to MN, and use the relevant files, the program begins to run.

[Anonymous]

Hi Rocco,

I get the same error with ‘Fe3p’.

If I scroll up before the error I also get this line:

core.chemical.ResidueTypeSet:     Expected file: /home/derekjs/storage/ROSETTAXXX/main/database/chemical/residue_type_sets/centroid/shadow_list.txt

When I cd to this dir_ectory I the file ‘shadow_lists.txt’ is missing. I copied it in from fa_standard and still the same error.

Also, I tried using the FE.params instead of FE2.params (while renaming the FE in the PDB file) and still get the same error.

If I change the metal ion to MN, and use the relevant files, the program begins to run.

[Anonymous]

Hmm .. Fe3p should be present in the most recent version of Rosetta, but if you’re using an older version (e.g. from mid-2016 or before), then it might not be present.

Not a problem – as I said, the exact type of the atom in centroid mode desn’t really matter. You can certainly use the ‘Mg2p’ type (what MN is using) in the centroid mode params file for the Fe(2+) ion.  — The benefit of doing it this way, rather than just changing things to Mn completely, is that when you swtich back to full atom mode, you’ll get the full atom parameters for Fe(2+), and your output files will have Fe atoms, rather than Mn atoms.

[Anonymous]

Hmm .. Fe3p should be present in the most recent version of Rosetta, but if you’re using an older version (e.g. from mid-2016 or before), then it might not be present.

Not a problem – as I said, the exact type of the atom in centroid mode desn’t really matter. You can certainly use the ‘Mg2p’ type (what MN is using) in the centroid mode params file for the Fe(2+) ion.  — The benefit of doing it this way, rather than just changing things to Mn completely, is that when you swtich back to full atom mode, you’ll get the full atom parameters for Fe(2+), and your output files will have Fe atoms, rather than Mn atoms.

[Anonymous]

Hmm .. Fe3p should be present in the most recent version of Rosetta, but if you’re using an older version (e.g. from mid-2016 or before), then it might not be present.

Not a problem – as I said, the exact type of the atom in centroid mode desn’t really matter. You can certainly use the ‘Mg2p’ type (what MN is using) in the centroid mode params file for the Fe(2+) ion.  — The benefit of doing it this way, rather than just changing things to Mn completely, is that when you swtich back to full atom mode, you’ll get the full atom parameters for Fe(2+), and your output files will have Fe atoms, rather than Mn atoms.

[Anonymous]

Hi Rocco,

Thanks for your input.

One more question: when I generate the models, the MN/FE ion is present, but is not coordinated (there are 3 histidines involved in coordination). I looked back at the initial hybrid model and the conserved histidines are not oriented to coordinate the ion. I then added the -in:auto_setup_metals flag to generate the hybrid, but the HIS residues are still oriented away from the ion. Am I missing a step that fixes the coordination, or do I require a constraints file?

[Anonymous]

Hi Rocco,

Thanks for your input.

One more question: when I generate the models, the MN/FE ion is present, but is not coordinated (there are 3 histidines involved in coordination). I looked back at the initial hybrid model and the conserved histidines are not oriented to coordinate the ion. I then added the -in:auto_setup_metals flag to generate the hybrid, but the HIS residues are still oriented away from the ion. Am I missing a step that fixes the coordination, or do I require a constraints file?

[Anonymous]

Hi Rocco,

Thanks for your input.

One more question: when I generate the models, the MN/FE ion is present, but is not coordinated (there are 3 histidines involved in coordination). I looked back at the initial hybrid model and the conserved histidines are not oriented to coordinate the ion. I then added the -in:auto_setup_metals flag to generate the hybrid, but the HIS residues are still oriented away from the ion. Am I missing a step that fixes the coordination, or do I require a constraints file?

[Anonymous]

I’d probably do it with constraints. The -in:auto_setup_metals flag does add some constraints, but that requires that there be an existing metal coordinating geometry. In homology modeling, where you’re starting with your target as just a sequence, you don’t have any of that geometry to start with.  It’s also nothing which would be modeled currently by transfering over from templates, even if the templates had the correct geometry.

[Anonymous]

I’d probably do it with constraints. The -in:auto_setup_metals flag does add some constraints, but that requires that there be an existing metal coordinating geometry. In homology modeling, where you’re starting with your target as just a sequence, you don’t have any of that geometry to start with.  It’s also nothing which would be modeled currently by transfering over from templates, even if the templates had the correct geometry.

[Anonymous]

I’d probably do it with constraints. The -in:auto_setup_metals flag does add some constraints, but that requires that there be an existing metal coordinating geometry. In homology modeling, where you’re starting with your target as just a sequence, you don’t have any of that geometry to start with.  It’s also nothing which would be modeled currently by transfering over from templates, even if the templates had the correct geometry.

[Anonymous]

The standard advice for segfaults is: what does it do when compiled in debug mode (without mode=release)?

Is the shadow list file there where it should be?  If not – well, the main question is “where did it go”?  We can resupply it for you but it makes me wonder if your install is damaged in some way.  (Or maybe it expects the shadow file, finds it, and then errors later.)

[Anonymous]

The standard advice for segfaults is: what does it do when compiled in debug mode (without mode=release)?

Is the shadow list file there where it should be?  If not – well, the main question is “where did it go”?  We can resupply it for you but it makes me wonder if your install is damaged in some way.  (Or maybe it expects the shadow file, finds it, and then errors later.)

[Anonymous]

The standard advice for segfaults is: what does it do when compiled in debug mode (without mode=release)?

Is the shadow list file there where it should be?  If not – well, the main question is “where did it go”?  We can resupply it for you but it makes me wonder if your install is damaged in some way.  (Or maybe it expects the shadow file, finds it, and then errors later.)

[Anonymous]

Thanks for the reply.

I have not re-installed on my machine, but I have re-run it using my build as well as versions 3.6, 3.7, and 3.8 on our lab’s directory in the university’s storage system. In all of those cases I get the same error, and the shadow list is not present in the ../residue_type_sets/centroid/ directory. I had thought that it would need to reference the zinc centroid parameter file in ../residue_type_sets/centroid/residue_types/metal_ions/, but it does not seem to be making it that far.

I appreciate your thoughts on the issue.

[Anonymous]

Thanks for the reply.

I have not re-installed on my machine, but I have re-run it using my build as well as versions 3.6, 3.7, and 3.8 on our lab’s directory in the university’s storage system. In all of those cases I get the same error, and the shadow list is not present in the ../residue_type_sets/centroid/ directory. I had thought that it would need to reference the zinc centroid parameter file in ../residue_type_sets/centroid/residue_types/metal_ions/, but it does not seem to be making it that far.

I appreciate your thoughts on the issue.

[Anonymous]

Thanks for the reply.

I have not re-installed on my machine, but I have re-run it using my build as well as versions 3.6, 3.7, and 3.8 on our lab’s directory in the university’s storage system. In all of those cases I get the same error, and the shadow list is not present in the ../residue_type_sets/centroid/ directory. I had thought that it would need to reference the zinc centroid parameter file in ../residue_type_sets/centroid/residue_types/metal_ions/, but it does not seem to be making it that far.

I appreciate your thoughts on the issue.

[Anonymous]

You have four builds available?  Are you making sure Rosetta is mapping to the correct database with each (the database that came with that release?)

A copy of shadow_list.txt is attached, but I still think the problem is a damaged (or, now, mis-selected) database.

[Anonymous]

You have four builds available?  Are you making sure Rosetta is mapping to the correct database with each (the database that came with that release?)

A copy of shadow_list.txt is attached, but I still think the problem is a damaged (or, now, mis-selected) database.

[Anonymous]

You have four builds available?  Are you making sure Rosetta is mapping to the correct database with each (the database that came with that release?)

A copy of shadow_list.txt is attached, but I still think the problem is a damaged (or, now, mis-selected) database.

[Anonymous]

The builds are absolutely definitely not overlapping. I am also specifying my database in my command prompt and it matches the executable. 

You are right that it is not shadow_list that is the problem. I added it in to my local build and that error disappeared but I still got a segfault. I ran it in debug mode and saw that something was not being recognized as a protein. I went back to my fasta, and if I remove the “Z” characters at the end of my fasta for my zinc metal ions then it will run just fine. I have two fastas that I have tried: one of them is annotated (Z[Zn]Z[Zn]) and the other is not annotated (ZZ). Neither of them works, but if I delete the metal ions then it will run with or without annotation of my other residues. 

Any idea why this might be the case? Thanks a lot for the input.

-Ben

[Anonymous]

The builds are absolutely definitely not overlapping. I am also specifying my database in my command prompt and it matches the executable. 

You are right that it is not shadow_list that is the problem. I added it in to my local build and that error disappeared but I still got a segfault. I ran it in debug mode and saw that something was not being recognized as a protein. I went back to my fasta, and if I remove the “Z” characters at the end of my fasta for my zinc metal ions then it will run just fine. I have two fastas that I have tried: one of them is annotated (Z[Zn]Z[Zn]) and the other is not annotated (ZZ). Neither of them works, but if I delete the metal ions then it will run with or without annotation of my other residues. 

Any idea why this might be the case? Thanks a lot for the input.

-Ben

[Anonymous]

The builds are absolutely definitely not overlapping. I am also specifying my database in my command prompt and it matches the executable. 

You are right that it is not shadow_list that is the problem. I added it in to my local build and that error disappeared but I still got a segfault. I ran it in debug mode and saw that something was not being recognized as a protein. I went back to my fasta, and if I remove the “Z” characters at the end of my fasta for my zinc metal ions then it will run just fine. I have two fastas that I have tried: one of them is annotated (Z[Zn]Z[Zn]) and the other is not annotated (ZZ). Neither of them works, but if I delete the metal ions then it will run with or without annotation of my other residues. 

Any idea why this might be the case? Thanks a lot for the input.

-Ben

[Anonymous]

You’re using the Hybridize mover via RosettaScripts, right?

It normally takes FASTA input, but if there are ligands, it has to take its input sequence from a Pose instead.  Give it a PDB through -s instead of a fasta file.  The conformation of this PDB is ignored – it just harvests the sequence.  

The ZN are in your templates, right?

[Anonymous]

You’re using the Hybridize mover via RosettaScripts, right?

It normally takes FASTA input, but if there are ligands, it has to take its input sequence from a Pose instead.  Give it a PDB through -s instead of a fasta file.  The conformation of this PDB is ignored – it just harvests the sequence.  

The ZN are in your templates, right?

[Anonymous]

You’re using the Hybridize mover via RosettaScripts, right?

It normally takes FASTA input, but if there are ligands, it has to take its input sequence from a Pose instead.  Give it a PDB through -s instead of a fasta file.  The conformation of this PDB is ignored – it just harvests the sequence.  

The ZN are in your templates, right?

[Anonymous]

Yessir. 

Ahh, I did not know that. I passed in a PDB file instead of the fasta and I no longer receive a segfault! Thanks.

Yeah, they are in the template. When I threaded my fasta onto my templates I made sure to include the metals. 

I am getting a CYS parameter problem now:

“can not find a residue type that matches the residue CYS:MP-SG-connect:MP-SG-pruneH:MP-SG-connect:MP-SG-pruneH:CtermProteinFull at position 249”

My protein has 2 chains, and the C-term of chain A is a CYS that also happens to be coordinating a ZN. If I remove the “TER” from the PDB file and treat it as one chain I still get: “can not find a residue type that matches the residue CYS:MP-SG-connect:MP-SG-pruneH:MP-SG-connect:MP-SG-pruneH at position 249”. My CYS does not have a hydrogen atom assigned to the sulfur; is this there a flag or parameter edit I can make to fix this error?

ATOM   3978  N   CYS A 270      30.416   7.742  47.737  1.00  0.00           N  

ATOM   3979  CA  CYS A 270      29.467   8.309  46.791  1.00  0.00           C  

ATOM   3980  C   CYS A 270      29.561   7.487  45.565  1.00  0.00           C  

ATOM   3981  O   CYS A 270      30.704   7.311  45.106  1.00  0.00           O  

ATOM   3982  CB  CYS A 270      29.798   9.778  46.515  1.00  0.00           C  

ATOM   3983  SG  CYS A 270      29.795  10.830  47.996  1.00  0.00           S  

ATOM   3984  H   CYS A 270      31.217   8.290  48.019  1.00  0.00           H  

ATOM   3985  HA  CYS A 270      28.442   8.323  47.161  1.00  0.00           H  

ATOM   3986 1HB  CYS A 270      30.794   9.865  46.080  1.00  0.00           H  

ATOM   3987 2HB  CYS A 270      29.064  10.208  45.834  1.00  0.00           H  

 

Thanks again.

-Ben

 

[Anonymous]

Yessir. 

Ahh, I did not know that. I passed in a PDB file instead of the fasta and I no longer receive a segfault! Thanks.

Yeah, they are in the template. When I threaded my fasta onto my templates I made sure to include the metals. 

I am getting a CYS parameter problem now:

“can not find a residue type that matches the residue CYS:MP-SG-connect:MP-SG-pruneH:MP-SG-connect:MP-SG-pruneH:CtermProteinFull at position 249”

My protein has 2 chains, and the C-term of chain A is a CYS that also happens to be coordinating a ZN. If I remove the “TER” from the PDB file and treat it as one chain I still get: “can not find a residue type that matches the residue CYS:MP-SG-connect:MP-SG-pruneH:MP-SG-connect:MP-SG-pruneH at position 249”. My CYS does not have a hydrogen atom assigned to the sulfur; is this there a flag or parameter edit I can make to fix this error?

ATOM   3978  N   CYS A 270      30.416   7.742  47.737  1.00  0.00           N  

ATOM   3979  CA  CYS A 270      29.467   8.309  46.791  1.00  0.00           C  

ATOM   3980  C   CYS A 270      29.561   7.487  45.565  1.00  0.00           C  

ATOM   3981  O   CYS A 270      30.704   7.311  45.106  1.00  0.00           O  

ATOM   3982  CB  CYS A 270      29.798   9.778  46.515  1.00  0.00           C  

ATOM   3983  SG  CYS A 270      29.795  10.830  47.996  1.00  0.00           S  

ATOM   3984  H   CYS A 270      31.217   8.290  48.019  1.00  0.00           H  

ATOM   3985  HA  CYS A 270      28.442   8.323  47.161  1.00  0.00           H  

ATOM   3986 1HB  CYS A 270      30.794   9.865  46.080  1.00  0.00           H  

ATOM   3987 2HB  CYS A 270      29.064  10.208  45.834  1.00  0.00           H  

 

Thanks again.

-Ben

 

[Anonymous]

Yessir. 

Ahh, I did not know that. I passed in a PDB file instead of the fasta and I no longer receive a segfault! Thanks.

Yeah, they are in the template. When I threaded my fasta onto my templates I made sure to include the metals. 

I am getting a CYS parameter problem now:

“can not find a residue type that matches the residue CYS:MP-SG-connect:MP-SG-pruneH:MP-SG-connect:MP-SG-pruneH:CtermProteinFull at position 249”

My protein has 2 chains, and the C-term of chain A is a CYS that also happens to be coordinating a ZN. If I remove the “TER” from the PDB file and treat it as one chain I still get: “can not find a residue type that matches the residue CYS:MP-SG-connect:MP-SG-pruneH:MP-SG-connect:MP-SG-pruneH at position 249”. My CYS does not have a hydrogen atom assigned to the sulfur; is this there a flag or parameter edit I can make to fix this error?

ATOM   3978  N   CYS A 270      30.416   7.742  47.737  1.00  0.00           N  

ATOM   3979  CA  CYS A 270      29.467   8.309  46.791  1.00  0.00           C  

ATOM   3980  C   CYS A 270      29.561   7.487  45.565  1.00  0.00           C  

ATOM   3981  O   CYS A 270      30.704   7.311  45.106  1.00  0.00           O  

ATOM   3982  CB  CYS A 270      29.798   9.778  46.515  1.00  0.00           C  

ATOM   3983  SG  CYS A 270      29.795  10.830  47.996  1.00  0.00           S  

ATOM   3984  H   CYS A 270      31.217   8.290  48.019  1.00  0.00           H  

ATOM   3985  HA  CYS A 270      28.442   8.323  47.161  1.00  0.00           H  

ATOM   3986 1HB  CYS A 270      30.794   9.865  46.080  1.00  0.00           H  

ATOM   3987 2HB  CYS A 270      29.064  10.208  45.834  1.00  0.00           H  

 

Thanks again.

-Ben

 

[Anonymous]

Our best guess is that it’s the centroid <-> fullatom problem that always plagues people using chemistries other than canonical amino acids.  How badly do you need the metals?  Try HM without them – if all the templates have the metal site, Rosetta is likely to leave it open even without the metal present.  Other options include:

* make a homemade residue type (in centroid and fa) that already has the metal connected to the CYS, so it’s only one ResidueType

* turn off the ability to generate the patches that are problematic.  There’s probably a list of activatable patches in database/chemical/residue_type_sets/*/patches – you can try commenting out the relevant MP-SG connect ones.

[Anonymous]

Our best guess is that it’s the centroid <-> fullatom problem that always plagues people using chemistries other than canonical amino acids.  How badly do you need the metals?  Try HM without them – if all the templates have the metal site, Rosetta is likely to leave it open even without the metal present.  Other options include:

* make a homemade residue type (in centroid and fa) that already has the metal connected to the CYS, so it’s only one ResidueType

* turn off the ability to generate the patches that are problematic.  There’s probably a list of activatable patches in database/chemical/residue_type_sets/*/patches – you can try commenting out the relevant MP-SG connect ones.

[Anonymous]

Our best guess is that it’s the centroid <-> fullatom problem that always plagues people using chemistries other than canonical amino acids.  How badly do you need the metals?  Try HM without them – if all the templates have the metal site, Rosetta is likely to leave it open even without the metal present.  Other options include:

* make a homemade residue type (in centroid and fa) that already has the metal connected to the CYS, so it’s only one ResidueType

* turn off the ability to generate the patches that are problematic.  There’s probably a list of activatable patches in database/chemical/residue_type_sets/*/patches – you can try commenting out the relevant MP-SG connect ones.

[Anonymous]

Hi Rocco,

I’d completely forgotten about this subject…

Is there a way of reading in a PDB file with metals and ligand, and writing out a metal-binding constraints file for use in RosettaCM?

[Anonymous]

I’m not sure if there’s a best way of doing this, but my initial thought would be to use RosettaScripts with the CstInfoMover and the dump_cst_file option see https://www.rosettacommons.org/docs/latest/scripting_documentation/RosettaScripts/Movers/movers_pages/CstInfoMover.

RosettaScripts should work with the -auto_setup_metals option, or there’s always the SetupMetalsMover https://www.rosettacommons.org/docs/latest/scripting_documentation/RosettaScripts/Movers/movers_pages/SetupMetalsMover

[Author]

Posts