Repository navigation
Add support for BinaryCIF - #839
Conversation
- solves Exceptions in binary parsing + speed-up (?) - Exception were parsing exceptions from the prominent Date class when executing in parallel. Not possible to reproduce, but omitted by changing to robust, thread-safe number parsing class.
lafita
left a comment
There was a problem hiding this comment.
Many thanks for this @JonStargaryen ! The code looks good and clean to me, I just had a couple of minor comments. I will leave it open for others to have a more thorough review, though.
- isolates consumer and converter functions - omits highly specific performance test
josemduarte
left a comment
There was a problem hiding this comment.
This looks fantastic, thank you so much! It adds a much more versatile and performant CIF parser compare to the current one, plus support for binary CIF. In my opinion we should eventually replace the current parser by this one, but that would be quite a dramatic change that breaks some API compatibility, so it needs to go with release 6.0. In the meantime we could release 5.3.0 that adds this parser as a second option. One thing to consider for a separate PR is whether to add full AtomCache functionality for binary cif.
I have one comment/doubt about the hard-coded atom_site field names, could you clarify that?
|
|
||
| AtomSiteCollector() { | ||
| // TODO this doesn't really make the case for the builder ;) | ||
| this.groupPDB = new StrColumnBuilder<>("atom_site", "group_PDB", null); |
There was a problem hiding this comment.
I thought these hard-coded strings shouldn't be needed. They should come from metadata available via the CIFTools library. Or am I missing something?
There was a problem hiding this comment.
Thanks for pointing this out. 196e0c5 replaces the hard-coded category and column names with the corresponding builder functions.
|
Curious, is there a reason why the code delegated to here is in a separate repository instead of a separate module in biojava? |
The ciftools code is not BioJava-specific. Rather it provides generic functionality for the handling of CIF files which can also be used by other projects. Therefore, I opted to create a separate project. |
Well, the scope of BioJava is what is in BioJava. There wasn't any support for 3D structures in BioJava until there was. :) I would much rather have |
That sure is a valid concern. The basic (binary) CIF handling is realized by dedicated, language-specific projects to be able to publish/promote the format as well as codec implementations. A project is more visible than a module somewhat hidden in BioJava. The same was done for MMTF. Also, don't worry about maintenance as ciftools-java is a RCSB project. Jose has admin rights to the repo and we're literally one desk apart for the case that refactoring becomes an issue. |
josemduarte
left a comment
There was a problem hiding this comment.
Thanks for implementing the changes!
|
@heuermh just want to reiterate that outsourcing to an external library is the same as was done for the mmtf format. Additionally, in this case, the new CIFtools library is more general than just parsing BinaryCIF. It provides all the tooling needed for dealing with the CIF format and CIF schemas. So it does a lot more that what we would want to have in BioJava. |
|
I'll merge this by the end of this week if there are no other concerns. |
What is BinaryCIF
What changed
Performance
The whole PDB archive (in parallel)
5000 PDB structures (in parallel)
parsing 5000 BinaryCIF files takes 35 s
parsing 5000 (text-based) CIF files with the new CIF parser takes 132 s
parsing 5000 (text-based) CIF files with the current BioJava CIF parser takes 310 s
parsing 5000 MMTF files (fetched from the web) with the BioJava MMTF parser the takes 17 s
in summary, parsing for conventional CIF files is substantially faster
performance should match MMTF when only atom coordinates are considered, BinaryCIF however provides all content from a file
Side notes
Down the road