The RNAFold package

[Tags: gpl, library, program]

RNAfold v2 using the ADPfusion library. The RNAfold algorithm is used to determine how fast we can be compared to a highly optimized C program.

Please use GHC 7.6 or newer.

NOTE I'd like to rename this package to RNAfold, like the C implementation. Do not install globally, especially if you normally use RNAfold from the ViennaRNA package, for obvious reasons.

[Skip to ReadMe]


Change logNone available
DependenciesADPfusion (>=, base (==4.*), BiobaseTurner (>=, BiobaseVienna (>=0.3), BiobaseXNA (>=0.7), cmdargs (>=0.10), containers, deepseq (>=1.3), lens (>=3.8), primitive (>=0.5), PrimitiveArray (>=0.5), repa (>=3.2), RNAFold, strict (>=0.3.2), vector (>=0.10) [details]
CopyrightChristian Hoener zu Siederdissen, 2010-2013
AuthorChristian Hoener zu Siederdissen (Haskell), Ivo L. Hofacker et al (ViennaRNA), 2010-2013
Home page
Source repositoryhead: git clone git://
ExecutablesRNAEval, RNAFold
UploadedFri Dec 6 23:47:37 UTC 2013 by ChristianHoener
Downloads1417 total (66 in last 30 days)
0 []
StatusDocs available [build log]
Successful builds reported [all 1 reports]




Maintainers' corner

For package maintainers and hackage trustees

Readme for RNAFold-

ViennaRNA RNAfold v2, MFE variant using the ADPfusion library


This algorithm is the second, and much larger, test case for ADPfusion. We implement "RNAfold v2" in the MFE variant using "-d2" dangles. Both a library version and an executable are created. The "RNAFold" binary expects single sequences, one per line. Backtracking tracks all co-optimal structures.


A simple "cabal update && cabal-dev install RNAFold" should be enough.

Runtime notes

Using Haskell and ADPfusion, we come to within x3-x4 for this package. Between the initial test case / submission (in I have traded in some performance improvements for much better readability in BioInf.RNAfold.Energy. The C version of RNAfold employs some other methods to improve performance. Consider:

base -~+ inner-1 +~- base base -~+ inner-2 +~- base

where it is advantageous to calculate the outer basepair only once, not twice as we are doing. It is probably better to try to improve the handling of fusioned code and/or final assembler generation than finding calculations common to different parts of CFG's.