make LORENE2 the default LORENE in the ET

Create issue
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 (9)

  1. Roland Haas reporter

    For reference: the copy of Loerene2 in Lorene.tar in git hash 8174ad4 "LORENE2: remove manual handling of OpenMP flags" of lorene is from 2016-05-10T12:57:18 GMT:

     cvs -z5 -d :pserver:anonymous@octane.obspm.fr:/cvsroot checkout -D '2016-05-10 12:57:18 GMT' Lorene
    

    and is patched wrt to that snapshot like this:

    diff -ur Lorene.orig/C++/Source/Eos/eos_tabul.C Lorene/C++/Source/Eos/eos_tabul.C
    --- Lorene.orig/C++/Source/Eos/eos_tabul.C  2014-03-06 09:53:35.000000000 -0600
    +++ Lorene/C++/Source/Eos/eos_tabul.C   2020-10-11 11:18:33.513925365 -0500
    @@ -208,6 +208,16 @@
     void Eos_tabul::read_table() {
    
       using namespace Unites ;
    +
    +  // If user specified another path for EOS tables, respect this
    +  char* user_table_path_c = getenv("LORENE_TABULATED_EOS_PATH");
    +  if (user_table_path_c != NULL) {
    +    std::string user_table_path(user_table_path_c);
    +    // Strip path from tablename in Lorene output file
    +    std::string filename = tablename.substr(tablename.find_last_of('/')+1);
    +    // Combine user-given path and filename from file
    +    tablename = user_table_path + '/' + filename;
    +  }
    
       ifstream fich(tablename.data()) ;
    

    The tarball contains the CVS control directories and the latest commit can (possibly there’s a CVS command):

    find . -path '*/CVS/Entries' | \
      while read i ; do
        gawk -vFS="/" 'NF>1{print $4}' $i | \
          while read j ; do
            date -d "$j GMT" +%s ;
          done ;
      done  | \
        gawk '{t1=$0+0;
               if(t1 > t0) {
                 t0 = t1;
                 print t1;system("TZ=GMT date -d @"t1)
               }
              }'
    

  2. Roland Haas reporter

    I dug up the old meeting minutes from when LORENE2 was first introduced (from 2016):

    http://lists.einsteintoolkit.org/pipermail/users/2016-October/005020.html

    basically we introduced LORENE2 to indicate the breaking change and left LORENE as the default version in the thornlist.

    At the very least we should be able to update LORENE2 to the current version (assuming no more breaking changes in between) and, if we want to deprecate LORENE1 and remove, possibly only in the release after the next one, switch defaults. The issue is that one cannot compile both thorns at the same time so switching from LORENE1 to LORENE2 will break existing parfiles (for example the gallery example).

    Making LORENE2 the default was a decision reached in the ET call on 2018-03-12:

    http://lists.einsteintoolkit.org/pipermail/users/2018-March/006122.html

    where it says:

    --8<--
    updating LORENE:

    • make LORENE2 the default after verifying that everything compiles and
      that gallery example works with LORENE2
    • check that BBH ID from Meudon group can still be read
    • create ticket for this
    • get this done within a month
      --8<--

    and from future minutes, nothing seems to have happened though in

    http://lists.einsteintoolkit.org/pipermail/users/2018-October/006610.html

    it says

    --8<--

    • update ET to LORENE2

      • need to check that files can still be read
      • old ticket stated that there would be an abort for some files written by old an read by new LORENE or vice versa
        --8<--

    and

    http://lists.einsteintoolkit.org/pipermail/users/2018-November/006634.html

    says

    --8<--
    LORENE2:

    • switch thornlist to have LORENE2 as the default
      --8<--

    and

    http://lists.einsteintoolkit.org/pipermail/users/2018-November/006661.html

    --8<--
    tasks for next Einstein Toolkit relelase trac listing:

    • LORENE2, should be enable in thornlist to compile, Zac wanted to provide a small data set to load it

    --8<--

    and the same note in

    http://lists.einsteintoolkit.org/pipermail/users/2018-November/006667.html

    However in 2018-02-03 an issue was raised by Zach

    http://lists.einsteintoolkit.org/pipermail/users/2018-December/006679.html

    --8<--
    WVUThorns:

    • Zach reported.  He has a small-ish but not well understood LORENE2
      initial data from his collaborator, has permissions to use it.
    • Working with Josh Faber (RIT) who is using LORENE2 for binary NS mergers, will have another small initial data set from him.
    • Discussion of a possible problem in LORENE2, a bug, that may make itincorrect.  In the translation from French to English a subroutine was not translated.  Also the LORENE1 initial data may not be useful in LORENE2.
    • Because of this Zach and Steve recommend proceeding with caution. 
      Last week the conclusion had been to replace LORENE1 with LORENE2...now not recommended until this is understood/explored further.
      --8<--

    this

    http://lists.einsteintoolkit.org/pipermail/users/2018-December/006691.html

    provides

    --8<--
    LORENE:

    • Josh reported on bugs existing in the English named classes in LORENE in the newer part of the codebase that do not yet exist in the French named classed
    • Josh expects to send bug fixes back to LORENE but will take a while to track them down
    • not sure if the ET's LORENE1 already has these bugs present that exist in LORENE2
      --8<--

    after which there is no more updates.

  3. Roland Haas reporter

    @Bruno Giacomazzo will someone of your group (given that you are using LORENE) be able to push this ticket forward? It seems to me that all that is required is checking with Josh about his concerns wrt to the English / French comment differences and possibly with Zach (though from the conversation it seems he was mostly looking for a LORENE example to include in a testsuite).

  4. Log in to comment