[Biojava-dev] Vecmath in biojava

Andreas Prlic andreas at sdsc.edu
Thu Nov 28 21:52:47 UTC 2013


Hi Jose,

Great that you want to join! Let's try to make this as easy as possible for
you.

The reason why we have not been using vecmath for the structure module so
far is that some Java VMs come with (usually an ancient version of) vecmath
bundled with the VM. As such it is hard to control for an application what
version gets executed. I definitely had bugs related to that when moving
code from the desktop into the server room and also when shipping code to
users via webstart.

Having said that, both your and Peter's use case are showing that we need
to add support for vecmath to BioJava.  We probably want to be a bit
conservative regarding what version of vecmath we are going to depend on,
though.

How can we make this most useful and where shall we add support for this?

Since we are discussing libraries, the other odd thing is that a long time
ago I integrated the Jama package. This was done at a time when it was not
easily accessible, and the whole fate of the library was unclear. Since
this is not original BioJava code, and it can get pulled via Maven
nowadays, I propose that for the next major release, we take this out
again. This means that a lot of package-imports will need to get changed,
but that should be fairly easy with some global search-and-replace. Any
thoughts on that?

Andreas











On Thu, Nov 28, 2013 at 12:35 PM, Rose, Peter <pwrose at ucsd.edu> wrote:

> Jose,
>
> I'm in a similar situation. I've also developed a significant amount of
> code for quaternary structure analysis based on BioJava that uses Vecmath
> extensively, which I'll contribute to the project in the near future.
>
> I frequently inter-convert between Matrix, AxisVector, and Quaternion
> representations. All of this works very naturally in Vecmath.
>
> There are a number of reasons I use Vecmath:
>
> * Why reinvent the wheel. Using Vecmath allows you to interface with other
> APIs that are also based on Vecmath. For example I can use the same classes
> in some our  BioJava application and our RCSB PDB viewers. So for example a
> surface area calculation that only needs Points and radii would be
> generally useful, even for developers that do otherwise not use BioJava.
> Vecmath removes the dependency on specific BioJava classes.
>
> * The entire library is well designed, very flexible, and highly
> efficient. It avoids allocation of  new objects and has hardcoded methods
> for transforming coordinates that are more efficient that using general
> purpose matrix operations, such as JAMA, that is used in BioJava.
>
> The only problem we've encountered with Vecmath is the question of
> distribution and versioning. We had problems with old Vecmath versions
> distributed on Mac and Linux, which are missing some methods, plus we found
> a bug in an old Vecmath implementation. We haven't figured out how to
> overwrite the class path. Have you had similar problem? How could Vecmath
> be distributed with BioJava so that we can ensure that the latest version
> of Vecmath is used, and not some old incompatible version that happens to
> be installed on a machine.
>
> -Peter
>
>
> ________________________________________
> From: biojava-dev-bounces at lists.open-bio.org [
> biojava-dev-bounces at lists.open-bio.org] on behalf of Jose Duarte [
> jose.duarte at psi.ch]
> Sent: Thursday, November 28, 2013 9:13 AM
> To: biojava-dev at biojava.org
> Subject: [Biojava-dev] Vecmath in biojava
>
> Hi biojava-ers
>
> I am a long-time follower of the biojava project but never wrote to the
> list or contributed to the project, so here is my official presentation.
>
> I work mainly in protein structure analysis and develop in java.
> Together with some colleagues we took the decision quite some time ago
> to go our way and developed our own library for structural
> bioinformatics ( http://www.bioinformatics.org/owl/). Which in general
> was a good idea and allowed for a lot of flexibility. Of course we knew
> that at some point joining a bigger project like biojava would always be
> a better option in the long term.
>
> After talking to Andreas at the PDBx workshop I think that this is the
> right moment to try joining in. For us that would mean a lot of code
> rewriting but surely it will be beneficial for us and hopefully also for
> the biojava project as we could contribute quite a lot of code back.
>
> The main project I am working on at the moment is protein interface
> classification in crystal structures (see our website
> http://www.eppic-web.org <http://www.eppic-web.org/>). It involves
> mainly structural calculations so it should be possible to do with the
> structural modules of biojava. For instance some things we do are
> reconstruction of the crystal lattice from the asymmetric unit or
> accessible surface areas (ASA) calculations.
>
> So for now I will try to do my first contribution into biojava by
> contributing the ASA code (an implementation of Shrake and Rupley's
> algorithm). So there I have my first question already:
>
> I see that the javax.vecmath library is not used in biojava. I find that
> strange since it is natural thing to use in dealing with 3D objects. For
> instance in our OWL framework we have used it extensively and it was
> very useful indeed. Our atom coordinates were represented as Point3d
> objects, which for instance allows for usage of built-in methods for
> transformations (represented as Matrix4d objects) and in general any
> kind of vector maths, necessary in almost any structural analysis.
>
> For instance in the context of ASA calculations I need to sample 3D
> points on the atoms' spherical surfaces (so these points are not atoms).
> There I used Point3d again and it seemed very natural. Of course one can
> instead use arrays or create a vecmath library ourselves but that seems
> overkill when a vecmath library exists already and is "almost" part of
> the core java libraries.
>
> So what is the opinion about using the vecmath library? could atom
> coordinates be represented as Point3ds? would it be a major issue to
> change that implementation? are there alternatives to that within the
> existing framework? I have only read some parts of the code and I'm not
> yet very familiar with it, so apologies in advance if I ask too obvious
> questions!
>
> Cheers
>
> Jose
>
>
> ---
> Jose Duarte
> Laboratory of Biomolecular Research
> 5232 Villigen PSI
> Switzerland
>
> _______________________________________________
> biojava-dev mailing list
> biojava-dev at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/biojava-dev
>
> _______________________________________________
> biojava-dev mailing list
> biojava-dev at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/biojava-dev
>



More information about the biojava-dev mailing list