Dear Eric I had a similar case. Apart from giving them the same residue number and "A" and "B" altloc identifiers, you should make sure the summation of their occupancies equals 1. Therefore you can use the "occupancy refinement selections" (in the GUI, go to "all parameters", then "atoms selections") and select your two ligands as "constrained groups". Kind regards Elke Elke De Zitter PhD student, KU Leuven Biochemistry, Molecular and Structural Biology Celestijnenlaan 200f - bus 2404, 3001 Leuven Room 00.84, +32 16 3 26530 ________________________________ Van: [email protected] [[email protected]] namens Nathaniel Echols [[email protected]] Verzonden: woensdag 30 juli 2014 22:00 Aan: Eric Girard CC: PHENIX user mailing list Onderwerp: Re: [phenixbb] Two ions at same position They need to have the altloc identifiers set differently: one ion gets "A", the other gets "B", which will prevent them from clashing in refinement. It is probably a good idea to give them the same residue number if you haven't already - I'm hoping this will result in the occupancy constraint being handled automatically. -Nat On Wed, Jul 30, 2014 at 3:53 PM, Eric Girard mailto:[email protected]> wrote: Dear phenixbb members, I am refining a structure that contains Ca2+ atoms. The structure was determined in presence of lanthanide ions. Thus, the resulting density clearly indicates that a part of each Ca2+ sites is substituted with Eu3+ (let's say 75% Ca2+ and 25% Eu3+ per sites). How can I deal with such situation? Indeed phenix.refine complains when I try to put a Ca2+ ion and a Eu3+ one with the same coordinates (and with the occupancies mentionned above) and stop. Thanks for your help. Eric. -- **************************************************************** Eric Girard Extremophiles and Large Macromolecular Assemblies (ELMA) group Institut de Biologie Structurale UMR 5075 CEA-CNRS-UJF-PSB 71 avenue des Martyrs CS 10090 38044 Grenoble Cedex 9 Phone: +33 (0)4 57 42 86 45tel:%2B33%20%280%294%2057%2042%2086%2045 Fax: +33 (0)4 76 50 18 90tel:%2B33%20%280%294%2076%2050%2018%2090 Web site: http://www.ibs.fr/ ***************************************************************** _______________________________________________ phenixbb mailing list [email protected]mailto:[email protected] http://phenix-online.org/mailman/listinfo/phenixbb

I also ran into this recently and was puzzled about the correct PDB encoding. Using the same residue number with differing altloc, atom name and element fields seems straightforward but what should the residue name be ? In my experience not all PDB-processing software is happy with different residue names for the same residue number. Is there definitive PDB documentation for this case? thanks, Alastair On 08/02/2014 08:12 AM, Pavel Afonine wrote:

On 8/2/14, 5:36 AM, Elke De Zitter wrote:

...

you should make sure the summation of their occupancies equals 1.

While this might help refinement convergence, in general this is not necessarily because phenix.refine will constrain coupled occupancies to add up to 1.

Pavel

_______________________________________________ phenixbb mailing list [email protected] http://phenix-online.org/mailman/listinfo/phenixbb

On Sat, Aug 2, 2014 at 8:36 AM, Alastair Fyfe wrote:

I also ran into this recently and was puzzled about the correct PDB encoding. Using the same residue number with differing altloc, atom name and element fields seems straightforward but what should the residue name be ? In my experience not all PDB-processing software is happy with different residue names for the same residue number. Is there definitive PDB documentation for this case?

This does appear to be permitted by the PDB (in addition to Phenix, of course) - a good example is crambin (1CBN), which has a naturally occurring polymorphism: ATOM 352 N ASER A 22 4.909 12.659 -3.127 0.20 3.03 N ATOM 353 N BSER A 22 4.909 12.659 -3.127 0.20 3.03 N ATOM 354 CA ASER A 22 6.035 13.459 -2.622 0.20 3.04 C ATOM 355 CA BSER A 22 6.035 13.459 -2.622 0.20 3.04 C ATOM 372 N CPRO A 22 4.909 12.659 -3.127 0.60 3.03 N ATOM 373 CA CPRO A 22 6.035 13.459 -2.622 0.60 3.04 C There are other examples of crambin that are numbered differently but this is presumably due to the preferences of the investigator and/or the limitations of the refinement software used. A counter-example is 3QXB, which has mixed metal sites: HETATM 9585 FE A FE A 301 -6.546 23.487 57.436 0.66 26.72 FE HETATM 9586 MN B MN A 302 -6.549 23.490 57.439 0.34 25.22 MN I would say that if software can't handle the first case (same residue number, different residue name) that is a bug, but there doesn't appear to be consensus on the "correct" way to do things. My preference would be to keep the numbering the same but the PDB will accept either convention. -Nat