[Biojava-dev] Introducing the GSoC project

[Peter Rose]

I just talked to a mass spec. guy here at UCSD, and he recommends the NIST data (averaged and mono-isotopic masses of the elements): http://physics.nist.gov/cgi-bin/Compositions/stand_alone.pl?ele=&ascii=html&isotype=some as the authoritative resource for these data.

-Peter

From: Peter Rose [mailto:pwrose at sdsc.edu]
Sent: Monday, May 09, 2011 1:03 PM
To: Andreas Prlic
Cc: biojava-dev; Rose, Peter; Chuan Hock Koh; Scooter Willis; Sergio Pulido
Subject: RE: [Biojava-dev] Introducing the GSoC project

A few more comments on the Element class:


1.       We are using the covalent radii in the protmod package. The covalent radii came from a variety of sources and are not documented. To have a consistent and up to date set of data, I suggest we use the data from: Beatriz Cordero, Verónica Gómez, Ana E. Platero-Prats, Marc Revés, Jorge Echeverría, Eduard Cremades, Flavia Barragán and Santiago Alvarez, in "Covalent radii revisited", Dalton Trans., 2008, [DOI: 10.1039/b801115j].

2.       The Element class contains a few other attributes that should be removed for now, until they are used somewhere and have been properly checked/updated. This includes the following attributes: minimumValence, maximumValence, commonValence, maximumCommonValence, and oxidationState. Since many elements have multiple oxidation states, etc. I think these values are of limited use. The only reason they are there since I used this class in another application, but they may not be useful in the context of BioJava.

3.       hillOrder, valenceElectronCount, and coreElectronCount are well defined and can stay. The source for paulingElectronegativity is mentioned in the code, so I think that can stay as is as well.

-Peter

From: Sergio Pulido [mailto:spulido99 at gmail.com]
Sent: Monday, May 09, 2011 12:49 PM
To: Andreas Prlic
Cc: biojava-dev; Rose, Peter; Chuan Hock Koh; Scooter Willis
Subject: Re: [Biojava-dev] Introducing the GSoC project


2.       The precision of some of the numbers may exceed float. If so,
should we use double?

I would suggest to use BigDecimal, given that you will use it for very precise calculations, no one wants the java floating point error making damages.