Index of /pub/ecola

[ICO]NameLast modifiedSizeDescription

[PARENTDIR]Parent Directory  -  
[DIR]tugo/2014-07-23 19:38 -  
[DIR]tools/2021-02-23 16:11 -  
[   ]to-delete2016-09-22 11:48 141  
[DIR]pocvip/2020-06-05 14:37 -  
[DIR]poc-solvers/2020-06-04 17:06 -  
[DIR]onguene/2017-02-21 23:55 -  
[DIR]data/2015-07-21 13:41 -  
[DIR]bathymetry/2021-02-10 17:55 -  
[DIR]SpEnOI/2017-02-23 15:04 -  
[DIR]SWOT/2023-03-25 19:55 -  
[DIR]SHOM/2023-02-02 17:14 -  
[DIR]RadarIroise/2017-02-23 15:03 -  
[TXT]README.html2019-07-26 11:45 6.3K 
[DIR]NEMO/2017-02-23 15:02 -  
[DIR]NEMO-TIDES/2020-06-24 17:19 -  
[DIR]KL/2020-05-28 10:41 -  
[DIR]IUGG-2019/2019-07-10 15:26 -  
[DIR]FOAM/2020-09-29 12:22 -  
[DIR]FESDAC/2020-06-24 10:21 -  
[DIR]FES2022/2022-10-20 16:16 -  
[DIR]FES2014/2021-06-02 14:48 -  
[DIR]Comodo/2015-04-01 15:46 -  
[DIR]CarlWunsch/2017-02-23 15:02 -  
[DIR]BOY/2017-02-23 15:02 -  
[   ]3-2N2DTU10.nc2016-09-22 11:48 95M 
[   ]2-2N2DTU10.nc2016-09-22 11:49 95M 

ÉCôLa software

ÉCôLa software

You must have a basic knowledge of file management with GNU/Linux command-line to use these softwares and to understand this document. If you get a problem, make sure you read the last section of this document before reporting it.

Dependencies

These softwares:

The poc-solvers need: - bash, wget, ed, automake, g++, gfortran, cmake 2.8 or above - the development files for lapack and suitesparse - optionally the development files for scotch, for TUGOm to run faster - and, if you want to use these with TUGOm, the development files for arpack or parpack to compile. The SIROCCO Tools need: - optionally the developpment files for shp for Shapefiles (.shp) support - flex, bison, a late version of the poc-solvers and the developpment files for: - proj-4.8 or above (preferably proj-4.9.0b2 or above) - gsl, netcdf and lapack to compile. TUGO needs: - a late version of the poc-solvers with : - at least umfpack support - preferably scotch support - and, for the MPI version, hwloc, metis and zdhips (see the documentation of INSTALL.sh in the poc-solvers for this) - the developpment files for gsl, netcdf and, for TUGO-GUI, gtk2 to compile. POCViP (POC VIewer and Processing) needs: - optionally the development files for readline to properly handle command lines and do completion - a late version of the SIROCCO Tools and the development files for gtk2 to compile.

If you have openSUSE, you may need to run the following command:

bash -cx 'sudo zypper addrepo http://download.opensuse.org/repositories/science/`lsb-release -sd |sed -re "s/ /_/g;s/\"//g"`/science.repo'
and also see http://software.opensuse.org/search for other repositories.

For Ubuntu :

sudo apt install mercurial lib{lapack,scalapack-mpi,suitesparse,scotch,arpack2,parpack2,hwloc,proj,gsl,netcdf,gtk2.0,readline6}-dev cmake autoconf flex bison

You will also need lftp and mercurial to easily access the repositories.

You must have a basic understanding of mercurial to keep your repositories up-to-date.

Repositories

The repositories are available from https://hg.legos.obs-mip.fr. To access the repositories you must:

You can then clone the content of all the repositories with this command, preferably from an empty directory:
bash -cx 'for r in poc-solvers tools tugo pocvip;do hg clone https://hg.legos.obs-mip.fr/$r;done'

Compilation instructions are all in a README in each repository.

You should also regularly update at least your sources!
  1. Back-up your changes, if any, with:
    bash -cx 'hg diff -g > `hg parent --template "{rev}:{node|short}.patch"`'
  2. Update your repository with:
    hg pull
  3. Update your sources with:
    hg up
  4. Update your binaries as explained in the then updated README.

Bug or crash reports

We know they are bugs. The important question is “Where are the bugs that affect you ?

You are kindly reminded to:

  1. read the constantly updated help
  2. check you are correctly using the executables
A help should be displayed by running the executable with the --help option.
If: then this is a bug that should be reported!

The only reasonable way to report a bug is to give enough information to reproduce it. If you run an executable, it all boils down to this, in decreasing order of preference:

  1. if we share an access on the same machine
    • email us
      • the full command line
      • with the directory where it was launched from
      • preferably also with the path of the file where the standard output and error have been redirected
      • and with as little irrelevant information as possible
    • and make sure we have read access to at least the input files and the standard output and error
  2. otherwise email us
    • the full command line
    • with, in decreasing order of preference:
      1. if they are not too big, the input files
      2. if they are too big and if it is possible to make a subset, a subset of the input files
      3. otherwise at least the last 50 lines of output.
    • and with as little irrelevant information as possible.

Failure to do as above will almost always result in your report being deprioritised!

If you do not update your sources, you will also have to: