make LORENE2 the default LORENE in the ET

Issue #2206 new
Roland Haas created an issue

We are currently shipping two versions of LORENE with the ET:

  • ExternalLibraries/LORENE
  • ExternalLibraries/LORENE2

which are different snapshots of LORENE which produce / read incompatible binary blobs as data files for the produced initial data. See ticket:1817#comment:28 .

Frank used to spearhead this effort (with me arguing for a new name to keep backwards compatibility).

By now LORENE2 should be made the default code used and LORENE the one downloaded but not compiled in (they cannot both be compiled due to linker conflicts).

This has become a bit more urgent since Debian (and hence Ubuntu soon) are including LORENE in the version from cvs20161116 in their stable release (stretch): https://packages.debian.org/stretch/liblorene-dev

CVS being what it is (and us not knowing which commit caused the change in binary format in the first place) it is not clear whether this is what the ET calls LORENE or LORENE2, but my guess would be it is LORENE2.

Ideally there would be a one release warning before this happens, unfortunately the release announcement mentioning LORENE2 does not do so: https://www.einsteintoolkit.org/about/releases/ET_2017_06_announcement.html

Having a LORENE copy present would speed up compilation a bit and is already being proposed on the wiki: https://docs.einsteintoolkit.org/et-docs/Simplified_Tutorial_for_New_Users#Speed_up_installation_by_using_native_packages

Keyword: None

Comments (1)

  1. Log in to comment