Q:
Greetings. Apologies for bothering you, but your morphing site suggests that
I contact you if a job is not finished in a day or so. The following jobs
were submitted last Friday:
– 692711-16199
– 692809-16356
– b692486-16007

For b692486-16007, at https://urldefense.proofpoint.com/v2/url?u=http-3A__www.molmovdb.org_cgi-2Dbin_morph.cgi-3FID-3D&d=AwIFaQ&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=GXLLd-iiiG3R6K6OQPuu_LKCNRF_WFNNajU6UPeecr0&m=Pa2aCcufMFrEjabZ9RvhKK7vIb2V8KTTaDj5TsR6n7E&s=W6R2HgNPIB0eB-w_lOkuCjLbCf_3TMwfNsDf9Nr1lUQ&e=
I get the following message: "Your request could not be processed. The
following error was detected: Morph not found in database.”

A:
An investigation into your morphs has been completed, and we have identified likely causes of these errors. In all cases, it appears as if the errors are a consequence of the PDB file formats. Details on specific morphs are given below:

For kb protein: 2qke_monomer.pdb —> fsTB_avg_min.pdb —> 2qke_monomer.pdb
At least one major issue identified was the fact that there appear to be pathological residue formats. For instance, have a look at the beginning of the ATOM records for the PDB 2qke_monomer.pdb:
ATOM 1 N MET A 1 -8.932 -20.214 2.255 1.00129.79 N
ATOM 2 CA MET A 1 -8.182 -19.102 2.920 1.00129.79 C
ATOM 3 C MET A 1 -8.441 -19.104 4.433 1.00129.79 C
ATOM 4 O MET A 1 -8.910 -18.109 4.991 1.00129.79 O
ATOM 5 CB MET A 1 -8.608 -17.750 2.326 1.00129.79 C
ATOM 6 CG MET A 1 -8.651 -17.719 0.800 1.00129.79 C
ATOM 7 SD MET A 1 -9.005 -16.077 0.094 1.00129.79 S
ATOM 8 CE MET A 1 -10.801 -15.970 0.277 1.00129.79 C

Everything appears to be perfectly fine with this MET residue. But have a look at the corresponding MET (again, the first residue in the file) within the PDB file to which we are trying to morph (ie, MET 1 in fsTB_avg_min.pdb):
ATOM 1 N MET 1 -10.344 9.596 10.785 1.00999.99
ATOM 2 HT1 MET 1 -10.167 8.615 10.490 1.00999.99
ATOM 3 HT2 MET 1 -9.599 10.204 10.388 1.00999.99
ATOM 4 HT3 MET 1 -11.263 9.902 10.406 1.00999.99
ATOM 5 CA MET 1 -10.344 9.693 12.268 1.00999.99
ATOM 6 HA MET 1 -10.330 10.740 12.539 1.00999.99
ATOM 7 CB MET 1 -11.608 9.045 12.838 1.00999.99
ATOM 8 HB1 MET 1 -11.402 8.006 13.048 1.00999.99
ATOM 9 HB2 MET 1 -12.394 9.105 12.100 1.00999.99
ATOM 10 CG MET 1 -12.105 9.700 14.117 1.00999.99
ATOM 11 HG1 MET 1 -11.283 9.762 14.816 1.00999.99
ATOM 12 HG2 MET 1 -12.888 9.087 14.538 1.00999.99
ATOM 13 SD MET 1 -12.756 11.359 13.840 1.00999.99
ATOM 14 CE MET 1 -11.572 12.350 14.748 1.00999.99
ATOM 15 HE1 MET 1 -10.811 12.710 14.072 1.00999.99
ATOM 16 HE2 MET 1 -11.114 11.749 15.519 1.00999.99
ATOM 17 HE3 MET 1 -12.078 13.190 15.200 1.00999.99
ATOM 18 C MET 1 -9.108 9.019 12.853 1.00999.99
ATOM 19 O MET 1 -8.352 9.629 13.609 1.00999.99

Of course, the morph server is trying to morph each residue into the corresponding residue of the other PDB file. However, it is very difficult to do this, most likely because the residues given are actually completely different (your MET residue in fsTB_avg_min.pdb seems to have ~3 times the number of atoms, making it impossible to perform the morph). Notably, the MET 1 residue is not unique in this regard — it appears as if there are many other residues with completely different numbers of atoms and formats.

I would also mention that all morphs are pairwise (rather than being annotated as 3-way morphs in the way that you have this one) — thus, what we tried to generate was really the following: 2qke_monomer.pdb —> fsTB_avg_min.pdb

For ka protein:
truncated5c5e.pdb —> KaiA_transitionState.pdb —> kaiA_fromTernary.pdb —> KaiA_transitionState.pdb —> truncated5c5e.pdb

Again, one immediate issue here is that all morphs are pairwise. Thus, the following individual pairwise morphs are possible
truncated5c5e.pdb —> KaiA_transitionState.pdb
KaiA_transitionState.pdb —> kaiA_fromTernary.pdb
kaiA_fromTernary.pdb —> KaiA_transitionState.pdb
KaiA_transitionState.pdb —> truncated5c5e.pdb

However, a single continues morph between all 5 structures given (really a cycle between 4 morphs) is not possible.

Secondly, if you look closely at the files kaiA_fromTernary.pdb and KaiA_transitionState.pdb, these seem to be completely different sequences (ie, the sequence of residues are very different). Some sequence differences can indeed be tolerated by the morph server, but beyond a certain degree of sequence homology, morphing becomes unreliable and eventually impossible.

For kc protein: c1_from_BCcomplex.pdb —> c1_from_40om.pdb —> c1_from_BCcomplex.pdb

Here, one immediate issue is (as with the first morph), the residue formats seem to be completely different and incompatible. For instance, have a look at VAL 19 in c1_from_BCcomplex.pdb:
ATOM 1 N VAL A 19 41.315 27.606 60.932 1.00 43.58 N
ATOM 2 CA VAL A 19 40.989 28.635 59.949 1.00 41.68 C
ATOM 3 C VAL A 19 42.235 29.400 59.515 1.00 24.69 C
ATOM 4 O VAL A 19 42.771 30.221 60.265 1.00 37.44 O
ATOM 5 CB VAL A 19 39.924 29.626 60.510 1.00 46.84 C
ATOM 6 CG1 VAL A 19 39.678 30.796 59.562 1.00 31.21 C
ATOM 7 CG2 VAL A 19 38.613 28.894 60.761 1.00 49.29 C
ATOM 8 HA VAL A 19 40.613 28.209 59.163 1.00 50.01 H
ATOM 9 HB VAL A 19 40.237 29.983 61.356 1.00 56.21 H
ATOM 10 HG11 VAL A 19 39.011 31.383 59.952 1.00 37.45 H
ATOM 11 HG12 VAL A 19 40.509 31.279 59.434 1.00 37.45 H
ATOM 12 HG13 VAL A 19 39.360 30.452 58.712 1.00 37.45 H
ATOM 13 HG21 VAL A 19 37.962 29.523 61.109 1.00 59.15 H
ATOM 14 HG22 VAL A 19 38.296 28.519 59.924 1.00 59.15 H
ATOM 15 HG23 VAL A 19 38.766 28.185 61.405 1.00 59.15 H

Now compare this to the corresponding residue VAL 19 in the file c1_from_40om.pdb:
ATOM 1 N VAL A 19 -23.156 44.101 -9.426 1.00 64.75 N
ATOM 2 CA VAL A 19 -22.022 43.812 -10.291 1.00 58.63 C
ATOM 3 C VAL A 19 -21.671 42.331 -10.275 1.00 54.58 C
ATOM 4 O VAL A 19 -21.400 41.761 -9.218 1.00 55.90 O
ATOM 5 CB VAL A 19 -20.783 44.627 -9.874 1.00 52.74 C
ATOM 6 CG1 VAL A 19 -19.630 44.361 -10.818 1.00 47.35 C
ATOM 7 CG2 VAL A 19 -21.116 46.109 -9.837 1.00 61.62 C

The VAL 19 within this second file looks good, but there seems to be something wrong with the format of the VAL19 in the first file. It is likely that the errors are a result of a) the incompatible residue formats, and b) the unrecognizable format given in the 1st file. Here, again, I just use VAL19 as an example — many other residues in your file seem to have this issue.

In sum, we advise ‘homogonizing’ the file formats, and adopting conventional residue formats, if possible. You might want to run a python script to extract out the atoms that are consistent with standard formats, for instance. We cannot guarantee with 100% that this will fix everything, but we can guarantee that this is the ideal starting point for resolving these errors.

Thank you again for using the server, and please do not hesitate to contact us if you have further questions or experience further difficulty.