include RePriMand in the ET

Create issue
Issue #2551 new
Roland Haas created an issue

RePrimAnd https://github.com/wokast/RePrimAnd implements and advanced con2prim scheme and EOS that could be used in the ET.

This will most likely be a multi-step process with first only the library and its C++ interface being available followed eventually by a Cactus native interface and possible wrappers for existing codes that use EOS_Omni. There is also a design challenge in defining, once more, the set of primitives that ID thorns provide and con2prim must compute.

Comments (8)

  1. Wolfgang Kastaun

    The public RePrimAnd repository contains a prototype for an external libraries thorn. It is located in the folder

    ET_interface/thorns/RePrimAnd

    The thorn already contains an archive of the library. It built successfully with the latest ET release (Lorentz). It depends on other external libraries: BOOST and GSL (the latter is likely to be dropped in the future). For the time being, it also requires the meson build system to be installed on the build host. This could be replaced by a make with moderate effort.

    The only documentation of the thorn so far is a README file pointing to the repository, which links to the latest online documentation of the library.

  2. Roland Haas reporter

    I would note that the non-commercial CC licenses are incompatible with GPL, since GPL compatibility requires that commercial use is allowed. This is not much of an issue for us since we never distribute a derived object, but eg the compiled Cactus executable (or a tarball of the full source code) cannot be distributed if it contains both CC-NC and GPL code since the licenses conflict (but one can still use it internally of course). See https://www.gnu.org/licenses/license-list.en.html#CC-BY-NC

  3. Roland Haas reporter

    We currently state (http://einsteintoolkit.org/contribute.html) that

    All components must be distributed under an open source licence so that others can use these components without restrictions (except as mandated by scientific integrity), can modify and improve them as necessary, and can pass on these modifications to their collaborators as they see fit.

    We suggest GPL compatible and link to the the OSI’s definition page (https://opensource.org/licenses/category). I do not think that the issue has come up before. So for not I will take note and bring it with in some initial review for discussion in the ET call (the questions whether this is problem). It certainly would be problem if this was intended to be a “Cactus*” thing since all “Cactus*” must be LGPL so that explicitly derived object can be distributed without exposing all code. This is for example why AEILocalInterp is in Numerical and not CactusNumerical (the author explicitly requires it to be GPL and not LGPL). The ET however does not have that LGPL requirement.

  4. Log in to comment