* Package name    : oxdna-cuda
  Version         : 3.4.2
  Upstream Author : Lorenzo Rovigatti <lorenzo.rovigatti@uniroma1.it>
* URL             : https://dna.physics.ox.ac.uk/
* License         : GPL-3
  Programming Lang: C++, Python
  Description     : coarse-grained simulation software for DNA, RNA, and related systems

oxDNA is a simulation code that was initially conceived as an
implementation of the coarse-grained DNA model introduced by
T. E. Ouldridge, J. P. K. Doye and A. A. Louis. It has been since
reworked and it is now an extensible simulation+analysis framework. It
natively supports DNA, RNA, Lennard-Jones and patchy particle
simulations of different kinds on both single CPU cores and NVIDIA
GPUs.
----

oxDNA is research software, but is reasonably established (around
since 2010), stable, and widely used within DNA nanotechnology and
related fields, not just within the authors' research groups (for
example, I'm not connected to them, there are around 200 papers listed
on their website, and there is oxdna.org that provides cloud-based
simulations using it).

I currently maintain the oxDNA installations on a Debian (11) research
group server, where oxDNA used by a few people, and on my own Arch and
Debian (sid) systems; maintaining this more general package would not
add too much to what I am already doing, as keeping an unmanaged
installation on a long-term, multi-user system would be asking for
trouble.

oxDNA has CUDA and CPU simulation backends. I've only made a package
so far including CUDA support, which would thus need to go in
contrib, because I primarily use the CUDA backend, and have mostly
seen others using it and presenting results with it.  It also has two
python libraries, oxpy and oxDNA_analysis_tools, which I have packaged
as separate binary packages.

I have not made a serious Debian package before, and would need a
sponsor for this; I'd plan to upload it to mentors.  Like much
research software, it was not built with standard system-wide
installation as a priority, and has needed some tweaking to its
build process in that regard, but it is reasonably simple, and the
upstream authors are responsive to changes to make things easier.

Note that above, I have listed the maintainer of the current
repository.  The core developers are more generally listed at
<https://dna.physics.ox.ac.uk/index.php/Contact_information> as Thomas
Ouldridge, Petr Šulc, Flavio Romano, and Lorenzo Rovigatti.  The
current upstream codebase is at
<https://github.com/lorenzo-rovigatti/oxDNA>, and current license at
<https://github.com/lorenzo-rovigatti/oxDNA/blob/master/LICENSE>.

Hi Constantine,

This sounds interesting. oxDNA could be a great addition to DebiChem or
Debian Med teams.

I have never worked with packaging CUDA software. Since it cannot be
built on buildd, I suppose all uploads will have to source+binary. It is
interesting how this works with sponsoring, in particular who (you or
sponsor) will have to build the binaries for upload.

By the way, what would be the binary compatibility of the CUDA package?
I.e., what is the range of CUDA versions that could use the binary
package without rebuilding it from source?

Best,
Andrius

Pbuilder has no problem (with non-free enabled, with no GPU) building
the binary packages for amd64, and that's the only architecture I know
of where the non-CUDA-enabled version works, much less the CUDA-enabled
one.  I *can* certainly build the binaries, but I don't know whether
that's appropriate, as the sponsor would not be able to ensure that they
were safe.  So I'd assume the sponsor would need to build.

I know there is some active effort on arm64 support now upstream
(https://github.com/lorenzo-rovigatti/oxDNA/issues/31), but that is for
the CPU-only version, and still isn't fully working, so this would
presumably only be amd64 for now.

That's a good question; CUDA compatibility seems to be rather complex,
and I'm not that familiar with it.

 From an architecture side, the upstream build system has an option,
CUDA_COMMON_ARCH, to compile for nvcc-version-supported common
architectures, and my package turns this on.  This should result in
support for 5.0, 5.2, 6.0, 6.1, 7.0, and 7.5 in the same binary package.
I expect 7.5 being the latest architecture is outdated upstream code in
select_compute_arch.cmake, and is not intentional, so that could be
changed.  I'm also not sure about what this would mean for running on a
newer (>=8) or other (eg, 7.2) architecture (not at all without
rebuilding? or just slower?).  I don't have shiny new GPUs to test it
with, but I suppose I could try installing the binary packages on an AWS
instance with a new GPU and seeing what happens.

Best,
Constantine