[Biojava-dev] Vecmath in biojava

Fri Nov 29 18:29:35 UTC 2013

>
>
> It should be quite straight forward then to replace JAMA stuff by vecmath.

I need to take a look at that. Jama is getting used all over the place for
the 3D structure alignment algorithms. I am worried this would mean that a
lot of code needs to be re-written.

> Vecmath can do everything that JAMA can do, I could not find EVD in
> vecmath but if I understand, it simply is a subcase of SVD (available in
> vecmath.GMatrix). I'd say that solves the JAMA problem in a better way by
> simply eliminating the need for another library.

Fewer dependencies is better. However since Jama is used extensively at the
internals, probably a dual dependency on both vecmath and jama is the way
to go for now.

We can provide utility methods such as Atom.getPoint3D(),
StructureTools.getPoint3dCAArray(structure) , etc. if people think that
would be helpful.

When I've had to use it in the past, I always needed to add a vecmath.jar
> to the classpath. Can't vecmath be added as a maven dependency?
>

Yes you can and need to. In prob. 85% of all situations that will go
perfectly as expected. However if the Java VM has vecmath bundled with it,
it will load the JVM's vecmath.jar instead of your application's and then
there is a high chance that there will be conflicts due to API changes.
Since we try to run on a wide variety of systems and setups, we should
therefore assume an older vecmath version when writing biojava code.

> How is it done at the moment for other dependencies? For instance there's
> a dependency in log4j in biojava3-structure. If I were to use biojava by
> simply downloading the jar, how would log4j be resolved? would I need to
> download it myself manually?

Yes. Having said that, the goal is always to keep dependencies to a minimum
and only add new ones when we really need them. As such I just committed a
cleanup that removes the log4j dependency (it was only used in a few
files). The structure module now only depends on other biojava modules
(with the exception of the unit tests, but those are not part of a release).

Andreas

On 11/29/2013 01:13 AM, Amr AL-Hossary wrote:
>
>> I also needed VecMath for my M.Sc. Project, and am intending to use it in
>> my
>> PhD research; especially as it is already incorporated in JMol.
>> So I support depending on it.
>>
>> Regarding forcing a specific version of vecmath, I have two quick ideas:
>> 1) we can call a specific function that is present only in a base version
>> that we want. If it is not there, then an exception is thrown and refuse
>> to
>> run.
>> 2) If we can wait  until java 8 is released, it includes this feature
>> already. But that option has Several bad consequences (not suitable for
>> everybody).
>>
>> Regards
>>
>> Amr
>>
>> -----Original Message-----
>> From: biojava-dev-bounces at lists.open-bio.org
>> [mailto:biojava-dev-bounces at lists.open-bio.org] On Behalf Of Andreas
>> Prlic
>> Sent: Friday, 29 November, 2013 5:53 AM
>> To: Rose, Peter
>> Cc: biojava-dev at biojava.org
>> Subject: Re: [Biojava-dev] Vecmath in biojava
>>
>> 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
>>>
>>>  _______________________________________________
>> 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
>>
>
> _______________________________________________
> biojava-dev mailing list
> biojava-dev at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/biojava-dev
>