<div dir="ltr">I guess that if you have a novel ligand in a non-deposited file then it wouldn't have a chemical component and so CONECT would be the only place to find those bonds. Is that an important enough use case to warrant the development effort?<div><br></div><div>Matt, your comments re #330 are well taken. +1 to a high-level try-catch to handle IndexOutOfBounds, NullPointer, and other nonspecific parsing errors.</div><div><br></div><div>-Spencer</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Dec 1, 2016 at 12:24 AM, Jose Duarte <span dir="ltr"><<a href="mailto:jose.duarte@rcsb.org" target="_blank">jose.duarte@rcsb.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">In the move towards version 5.0 (still in development), bonds were unified by using the Bond class to represent them. The Bond objects are a better representation and provide easier access since they are referenced directly from Atom objects.<div><br></div><div>It seems that CONECT records in current HEAD are indeed not used at all (they are parsed but nothing is done with them). In any case Bonds are created for these cases: SSBOND records, peptide bonds (inferred from chain geometry) and intra-residue bonds (by getting information from chemical component dictionary). The question here would be: are the CONECT records adding anything on top of that? What kind of other bonds do we miss that CONECT records have?</div><div><br></div><div>If the CONECT records are providing extra info that we don't have elsewhere then this would be an issue in 5.0-SNAPSHOT that would need to be solved. If they don't provide extra info, then we'd better get rid of all code dealing with CONECT records to be sure we don't have unnecessary parsing problems.</div><div><br></div><div>Jose</div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="h5">On Wed, Nov 30, 2016 at 1:44 PM, Matt Larson <span dir="ltr"><<a href="mailto:larsonmattr@gmail.com" target="_blank">larsonmattr@gmail.com</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5"><div dir="ltr"><div><div><div><div><div>Hi,<br></div><div><br>I was looking back at issue 330 (short lines when parsing PDB) but there have been some large API changes ~ 4.2.x to move BioJava to more resemble mmCIF structure formats. These API changes dropped LINK (and possibly CONECT records?). <br></div></div></div><br>The question I have is whether CONECT records should now be used to create Bond(s), like what happens for SSBonds? Is BioJava only going to use Bond instances to describe bond-like interactions? CONECT records are still being parsed but they may no longer be stored or accessible from a Structure, since they are not creating Bond instances and getConnections() was deprecated.<br></div><br></div>It would be helpful to still provide CONECT information from PDB files to describe bonding between atoms especially for ligands. If not, then CONECT records should not be parsed. <br><br>For issue 330:<br>Parsing CONECT can cause string out-of-bounds exceptions when they have
only 2 atoms are present. Besides implementing line length checks when parsing CONECTs, adding a try/catch block for string out of bound
exceptions around the parsePDBFile(..) handler blocks that skip invalid lines and log warnings rather than breaking
parsing would make the parser more robust.<span class="m_7821985867207038151HOEnZb"><font color="#888888"><br><div><div><div><div><div><div><div><div><div><div><div><br>-- <br><div class="m_7821985867207038151m_-3531968007015073803gmail_signature"><div dir="ltr"><div><div dir="ltr">Matt Larson, PhD<br>Madison, WI 53705 U.S.A.</div></div></div></div>
</div></div></div></div></div></div></div></div></div></div></div></font></span></div>
<br></div></div>______________________________<wbr>_________________<br>
biojava-dev mailing list<br>
<a href="mailto:biojava-dev@mailman.open-bio.org" target="_blank">biojava-dev@mailman.open-bio.o<wbr>rg</a><br>
<a href="http://mailman.open-bio.org/mailman/listinfo/biojava-dev" rel="noreferrer" target="_blank">http://mailman.open-bio.org/ma<wbr>ilman/listinfo/biojava-dev</a><br></blockquote></div><br></div>
<br>______________________________<wbr>_________________<br>
biojava-dev mailing list<br>
<a href="mailto:biojava-dev@mailman.open-bio.org">biojava-dev@mailman.open-bio.<wbr>org</a><br>
<a href="http://mailman.open-bio.org/mailman/listinfo/biojava-dev" rel="noreferrer" target="_blank">http://mailman.open-bio.org/<wbr>mailman/listinfo/biojava-dev</a><br></blockquote></div><br></div>