← 输入框|github.com|刷新
Skip to content

Add support for BinaryCIF - #839

Merged
josemduarte merged 26 commits into
biojava:masterfrom
sbittrich:bcif
Jun 3, 2019
Merged

josemduarte merged 26 commits into
biojava:masterfrom
sbittrich:bcif

Conversation

@sbittrich

@sbittrich sbittrich commented May 2, 2019 •

Copy link
Copy Markdown
Member

What is BinaryCIF

  • BinaryCIF is a compact representation of CIF files
  • similar encoding strategies are used as in MMTF - however the format is fully compatible with conventional, text-based CIF files
  • therefore, we get all the advantages and established handling of CIF files as well as the performance of MMTF
  • ciftools-java provides the BinaryCIF codec, all model classes for the content of CIF files, and capabilities for the parsing of text-based CIF files
  • content from binary and text files is stored in the same data structure (a CifFile) - thus, it does not matter where the data came from: binary and text-based CIF data is handled the same way

What changed

  • I tried to introduce no change to existing classes and behavior, the implementation rather coexists with the established and tested parsing of CIF files
  • handling of BinaryCIF and CIF files is delegated to ciftools, this library provides a representation which can be used to populate Structure instances with data
  • parsing behavior was taken from SimpleMMcifConsumer - no information should be missing
  • the majority of tests we duplicated for now to work on the new implementation (both on binary and text-based CIF files)

Performance

  • Some basic performance tests.

The whole PDB archive (in parallel)

  • parsing 151079 BinaryCIF files takes 918 s
  • parsing 151079 (text-based) CIF files takes 2502 s (a new experimental implementation for text-based CIF parsing which comes basically for free by wrapping ciftools)

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

  • SimpleMMcifConsumer uses SimpleDateFormat for date parsing which caused a number of parsing exceptions when executed in parallel - my implementation uses Java 8's LocalDate for parsing, while still reporting Date objects compatible with the data structure

Down the road

  • integrate into StructureIO/AtomCache
  • omit/merge duplicated code if stable (SimpleMMcifConsumer, mmCIF model beans)
  • the new code is a good chance to revisit missing categories in the SimpleMMcifConsumer (currently not parsed content) and refine the writing in FileConvert

@lafita lafita added the new feature New method or data structure label May 7, 2019
@lafita
lafita requested review from josemduarte and pwrose May 7, 2019 14:57

@lafita lafita left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

@josemduarte josemduarte left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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);

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for pointing this out. 196e0c5 replaces the hard-coded category and column names with the corresponding builder functions.

@heuermh

heuermh commented May 11, 2019

Copy link
Copy Markdown
Member

Curious, is there a reason why the code delegated to here is in a separate repository instead of a separate module in biojava?

@sbittrich

Copy link
Copy Markdown
Member Author

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.

@heuermh

heuermh commented May 13, 2019 •

Copy link
Copy Markdown
Member

The ciftools code is not BioJava-specific.

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 ciftools-java exist within BioJava than add a new dependency on an external single-developer project. That will help make deprecation/refactoring/removal of the current CIF implementation in BioJava easier.

@sbittrich

Copy link
Copy Markdown
Member Author

I would much rather have ciftools-java exist within BioJava than add a new dependency on an external single-developer project. That will help make deprecation/refactoring/removal of the current CIF implementation in BioJava easier.

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 josemduarte left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for implementing the changes!

@josemduarte

Copy link
Copy Markdown
Contributor

@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.

@lafita
lafita removed the request for review from pwrose May 17, 2019 08:27
@josemduarte

Copy link
Copy Markdown
Contributor

I'll merge this by the end of this week if there are no other concerns.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

new feature New method or data structure

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants