Hi,
Thank you so much for making and maintaining this wonderful tool! I was trying to get this working on our cluster and was having some results that didn't make sense, hopefully you'll be able to help me figure out what I'm doing wrong.
I'm looking at potato calmodulin (pdb 1RFJ) as an example, since this was the example used for foldview by you guys, and focusing on the EF hand motif for binding Ca2+at A21,A23,A25,A27,A32.
The exact query I put in was "folddisco query -i /data/xray2/folddisco/index/pdb_folddisco -p "/data/xray2/queries/query_proteins/1RFJ.pdb" -q A21,A23,A25,A27,A32 --header" , but in the output what I get are idf values that start off in the 850k+ range that are clearly not best fits for this motif, here are the top few hits:
pdb/k0/pdb2k0e.ent.gz 5 852272.2500 0.8812 A21,A23,A25,A27,A32 A21,A23,A25,A27,A32
pdb/ko/pdb2kox.ent.gz 4 719508.8125 4.7118 A33,A35,A35,,A73 A21,A23,A25,A27,A32
pdb/k0/pdb2k0f.ent.gz 5 699122.3125 0.3582 A17,A19,A21,A23,A28 A21,A23,A25,A27,A32
pdb/k0/pdb2k0f.ent.gz 5 675060.8125 0.3875 A90,A92,A94,A96,A101 A21,A23,A25,A27,A32
pdb/k0/pdb2k0e.ent.gz 3 214001.0625 0.2070 ,A59,A61,A63, A21,A23,A25,A27,A32
pdb/ko/pdb2kox.ent.gz 2 161846.6875 0.4949 ,A47,,,A69 A21,A23,A25,A27,A32
pdb/lj/pdb2lj5.ent.gz 4 127701.9062 4.9057 A33,A35,A35,,A73 A21,A23,A25,A27,A32
pdb/k0/pdb2k0f.ent.gz 3 102424.9766 0.3399 ,A55,A57,A59, A21,A23,A25,A27,A32
pdb/k0/pdb2k0f.ent.gz 3 58703.3008 1.5247 ,A128,A130,A126, A21,A23,A25,A27,A32
pdb/v5/pdb6v5d.ent.gz 4 50922.2812 4.4841 A33,A35,A35,,A73 A21,A23,A25,A27,A32
pdb/nq/pdb7nqc.ent.gz 5 44552.1055 0.5286 A94,A96,A98,A100,A105 A21,A23,A25,A27,A32
pdb/nr/pdb2nr2.ent.gz 4 35710.1016 4.8469 A33,A35,A35,_,A73 A21,A23,A25,A27,A32
The first hit makes sense, as it fits perfectly and is a Ca2+ binding site, however the second hit here doesn't make as much sense. I assume 1RFJ would come up on top since it would fit itself the best. I checked my output file for 1RFJ and got the following:
pdb/rf/pdb1rfj.ent.gz 5 110.6880 0.0000 A21,A23,A25,A27,A32 A21,A23,A25,A27,A32
pdb/rf/pdb1rfj.ent.gz 5 73.8567 5.6343 A94,A134,A98,A100,A105 A21,A23,A25,A27,A32
pdb/rf/pdb1rfj.ent.gz 3 16.3869 0.2032 ,A132,A134,A136, A21,A23,A25,A27,A32
pdb/rf/pdb1rfj.ent.gz 4 16.3869 3.2532 _,A59,A61,A63,A32 A21,A23,A25,A27,A32
I would expect the first hit to come out on top right? I double checked with the web hosted version of folddisco by putting in the same residue and got this when searching only the pdb:
where the IDF value is similar but not exactly the same as what I got before. As expected, 1RFJ comes out on top, instead of the wacky super high idf values that don't match too well.
Could there possibly be something wrong with what I'm doing with the cluster?
I know there's a note in the readme about different pdb indexes being incompatible, I used wget last week to download from this link: https://opendata.mmseqs.org/folddisco/pdb_folddisco.tar.lz4. It looks like the pdb hosted on the web version is a little older, from 9/25, which might explain the little discrepancy in 1RFJ idf but not the huge idf values I see on the cluster.
Does your team have any idea what I might be doing wrong?
Thanks,
Weber
Hi,
Thank you so much for making and maintaining this wonderful tool! I was trying to get this working on our cluster and was having some results that didn't make sense, hopefully you'll be able to help me figure out what I'm doing wrong.
I'm looking at potato calmodulin (pdb 1RFJ) as an example, since this was the example used for foldview by you guys, and focusing on the EF hand motif for binding Ca2+at A21,A23,A25,A27,A32.
The exact query I put in was "folddisco query -i /data/xray2/folddisco/index/pdb_folddisco -p "/data/xray2/queries/query_proteins/1RFJ.pdb" -q A21,A23,A25,A27,A32 --header" , but in the output what I get are idf values that start off in the 850k+ range that are clearly not best fits for this motif, here are the top few hits:
pdb/k0/pdb2k0e.ent.gz 5 852272.2500 0.8812 A21,A23,A25,A27,A32 A21,A23,A25,A27,A32
pdb/ko/pdb2kox.ent.gz 4 719508.8125 4.7118 A33,A35,A35,,A73 A21,A23,A25,A27,A32
pdb/k0/pdb2k0f.ent.gz 5 699122.3125 0.3582 A17,A19,A21,A23,A28 A21,A23,A25,A27,A32
pdb/k0/pdb2k0f.ent.gz 5 675060.8125 0.3875 A90,A92,A94,A96,A101 A21,A23,A25,A27,A32
pdb/k0/pdb2k0e.ent.gz 3 214001.0625 0.2070 ,A59,A61,A63, A21,A23,A25,A27,A32
pdb/ko/pdb2kox.ent.gz 2 161846.6875 0.4949 ,A47,,,A69 A21,A23,A25,A27,A32
pdb/lj/pdb2lj5.ent.gz 4 127701.9062 4.9057 A33,A35,A35,,A73 A21,A23,A25,A27,A32
pdb/k0/pdb2k0f.ent.gz 3 102424.9766 0.3399 ,A55,A57,A59, A21,A23,A25,A27,A32
pdb/k0/pdb2k0f.ent.gz 3 58703.3008 1.5247 ,A128,A130,A126, A21,A23,A25,A27,A32
pdb/v5/pdb6v5d.ent.gz 4 50922.2812 4.4841 A33,A35,A35,,A73 A21,A23,A25,A27,A32
pdb/nq/pdb7nqc.ent.gz 5 44552.1055 0.5286 A94,A96,A98,A100,A105 A21,A23,A25,A27,A32
pdb/nr/pdb2nr2.ent.gz 4 35710.1016 4.8469 A33,A35,A35,_,A73 A21,A23,A25,A27,A32
The first hit makes sense, as it fits perfectly and is a Ca2+ binding site, however the second hit here doesn't make as much sense. I assume 1RFJ would come up on top since it would fit itself the best. I checked my output file for 1RFJ and got the following:
pdb/rf/pdb1rfj.ent.gz 5 110.6880 0.0000 A21,A23,A25,A27,A32 A21,A23,A25,A27,A32
pdb/rf/pdb1rfj.ent.gz 5 73.8567 5.6343 A94,A134,A98,A100,A105 A21,A23,A25,A27,A32
pdb/rf/pdb1rfj.ent.gz 3 16.3869 0.2032 ,A132,A134,A136, A21,A23,A25,A27,A32
pdb/rf/pdb1rfj.ent.gz 4 16.3869 3.2532 _,A59,A61,A63,A32 A21,A23,A25,A27,A32
I would expect the first hit to come out on top right? I double checked with the web hosted version of folddisco by putting in the same residue and got this when searching only the pdb:
where the IDF value is similar but not exactly the same as what I got before. As expected, 1RFJ comes out on top, instead of the wacky super high idf values that don't match too well.
Could there possibly be something wrong with what I'm doing with the cluster?
I know there's a note in the readme about different pdb indexes being incompatible, I used wget last week to download from this link: https://opendata.mmseqs.org/folddisco/pdb_folddisco.tar.lz4. It looks like the pdb hosted on the web version is a little older, from 9/25, which might explain the little discrepancy in 1RFJ idf but not the huge idf values I see on the cluster.
Does your team have any idea what I might be doing wrong?
Thanks,
Weber