Diamond database tied to specific diamond build?

woberg

New member
We use local builds of diamond. I'm creating databases with makedb and they seem tied to the specific version of diamond that was built. In addition, the databases seem to be tied to the specific compiler that was used (e.g. gcc 4.9.4 vs 8.X.X). When using a database built with a different diamond version I get:

Code:
Error: Database was built with a different version of Diamond and is incompatible.
Is this behavior by design or is there a compilation flag that can be used to change this behavior?

Thanks.
 

Benjamin Buchfink

Administrator
Staff member
The database format has changed twice in the past, so this is a rare occurence and should not happen regularly between different versions. Can you tell me precisely which versions are causing the problem? Could you also give me the system specs and Diamond version for which you are observing the compiler problem?
 

woberg

New member
This is on CentOS 7.

I have done some more debugging. It seems that for some reason, our builds of Diamond using gcc-4.9.4 require a match between the version that created the database and the version that does blastp. When I use v0.9.24.125 built with gcc-8.2.0, I can use databases created by older Diamond versions. When I use v0.9.24.125 [or any other version (0.9.22, 0.9.16, 0.9.10)] built with gcc-4.9.4, I need to use the specific version that created the database. I don't have access to older Diamond versions built with gcc-8.2.0.

I make a Diamond database every 2-3 months that includes the entire current UniProt database, and we try to keep on top of recent Diamond versions, so the database-Diamond version synchronization crops up with every UniProt database release.

When using Diamond v0.9.24.125 built with gcc-4.9.4, I can run dbinfo on a database created with Diamond v0.9.24.125 built with gcc-8.2.0. But I can't run blastp. Here is the dbinfo from the gcc-8.2.0 database:

Database format version = 3
Diamond build = 125
Sequences = 159092877
Letters = 53371311309

However, v0.9.24.125 built with gcc-8.2.0 can use a database built with gcc-4.9.4. Here is the gcc-4.9.4 dbinfo:

Database format version = 2
Diamond build = 125
Sequences = 159092877
Letters = 53371311309

It's strange to me that the database format version changes depending on the compiler. Is that an issue with our software build process?
 

Benjamin Buchfink

Administrator
Staff member
I think you are building two different versions of Diamond here, because database format version 3 is not created by any release version, but only the latest github commit. That can happen if you clone the repository instead of downloading a release.

These other more substantial incompatibilities should not occur. I will try to reproduce the problem on a CentOS system.
 

Benjamin Buchfink

Administrator
Staff member
I tried to reproduce this on a CentOS 6 system, Diamond compiled from source using GCC 4.9.4. I couldn't find any incompatibilities that shouldn't exist, i.e. databases created by v0.9.10 and v0.9.16 are compatible, as are those created by v0.9.22 and v0.9.24.

Could you reproduce this using a small database file and send me the .dmnd files that should be compatible but aren't?
 

woberg

New member
I have been unable to reproduce the behavior I reported when I created a small database file. There must be some issue with the environment (we have a complicated Lmod-based environment system on our cluster). The only behavior that I am seeing is that the Diamond version compiled with GCC 4.9.4 cannot read the database file created by the same version of Diamond compiled with GCC 8.2.0.

I apologize for the rabbit trail! Thanks for looking into the issue.

If you are interested in trying out the database file that was created with GCC 8.2.0 on your version compiled with 4.9.4 I have attached it. I'm pretty sure the Diamond versions are correct (both are using 0.9.24). I had to rename it to .txt for it to upload.
 

Attachments

Last edited:
Top