Merge branch 'nina' of mmg-gitlab.fjfi.cvut.cz:mmg/tnl-dev into nina

                -DWITH_EXAMPLES=${WITH_EXAMPLES}

                -DWITH_TOOLS=${WITH_TOOLS}

                -DWITH_PYTHON=${WITH_PYTHON}

#        - make

#        - make test

        # "install" implies the "all" target

#        - make install

        - ninja ${NINJAFLAGS}

#        - make test

        - ninja ${NINJAFLAGS} install

        - ninja test

        - ninja install

        - popd

    variables:

        <<: *default_cmake_flags

# Cuda builds are specified first because they take more time than host-only builds,

# which can be allocated on hosts whitout GPUs.

# Similarly, release builds are launched first to avoid the tail effect (they take

# significantly more time than debug builds).

cuda_base_Debug:

cuda_full_Release:

    <<: *build_template

    tags:

        - openmp

        - gpu

    variables:

        <<: *default_cmake_flags

        WITH_OPENMP: "yes"

        WITH_CUDA: "yes"

        BUILD_TYPE: Debug

        BUILD_TYPE: Release

        WITH_BENCHMARKS: "yes"

        WITH_EXAMPLES: "yes"

        WITH_TOOLS: "yes"

        WITH_PYTHON: "yes"

cuda_base_Release:

    <<: *build_template

        WITH_CUDA: "yes"

        BUILD_TYPE: Release

cuda_mpi_Debug:

    <<: *build_template

    tags:

        - openmp

        - gpu

        - mpi

    variables:

        <<: *default_cmake_flags

        WITH_OPENMP: "yes"

        WITH_CUDA: "yes"

        WITH_MPI: "yes"

        BUILD_TYPE: Debug

cuda_mpi_Release:

    <<: *build_template

    tags:

        WITH_TOOLS: "yes"

        WITH_PYTHON: "yes"

cuda_full_Release:

cuda_base_Debug:

    <<: *build_template

    tags:

        - gpu

    variables:

        <<: *default_cmake_flags

        WITH_CUDA: "yes"

        BUILD_TYPE: Debug

cuda_mpi_Debug:

    <<: *build_template

    tags:

        - openmp

        - gpu

        - mpi

    variables:

        <<: *default_cmake_flags

        WITH_OPENMP: "yes"

        WITH_CUDA: "yes"

        BUILD_TYPE: Release

        WITH_BENCHMARKS: "yes"

        WITH_EXAMPLES: "yes"

        WITH_TOOLS: "yes"

        WITH_PYTHON: "yes"

        WITH_MPI: "yes"

        BUILD_TYPE: Debug

default_base_Debug:

    <<: *build_template

## How to configure git

It is important to [configure your git username and email address](

https://mmg-gitlab.fjfi.cvut.cz/gitlab/help/gitlab-basics/start-using-git.md#add-your-git-username-and-set-your-email),

since every git commit will use this information to identify you as the author:

    git config --global user.name "John Doe"

    git config --global user.email "john.doe@example.com"

In the TNL project, this username should be your real name (given name and

family name) and the email address should be the email address used in the

Gitlab profile. You should use the same configuration on all computers where

you make commits. If you have made some commits with a different email address

in the past, you can also add secondary email addresses to the Gitlab profile.

## How to write good commit messages

Begin with a short summary line a.k.a. message subject:

- Use up to 50 characters; this is the git official preference.

- Finish without a sentence-ending period.

Continue with a longer description a.k.a. message body:

- Add a blank line after the summary line, then write as much as you want.

- Use up to 72 characters per line for typical text for word wrap.

- Use as many characters as needed for atypical text, such as URLs, terminal

  output, formatted messages, etc.

- Include any kind of notes, links, examples, etc. as you want.

See [5 Useful Tips For A Better Commit Message](

https://robots.thoughtbot.com/5-useful-tips-for-a-better-commit-message) and

[How to Write a Git Commit Message](https://chris.beams.io/posts/git-commit/)

for examples and reasoning.

## How to split commits

Extensive changes should be split into multiple commits so that only related

changes are made in each commit. All changes made in a commit should be

described in its commit message. If describing all changes would not result in

a good commit message, you should probably make multiple separate commits.

Multiple small commits are better than one big commit, because later they can be

easily [squashed](https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History)

together, whereas splitting a big commit into logical parts is significantly

more difficult.

> __Tip:__ Use `git add -p` to stage only part of your working tree for the next

> commit. See [git add -p: The most powerful git feature you're not using yet](

https://johnkary.net/blog/git-add-p-the-most-powerful-git-feature-youre-not-using-yet/).

## Rebase-based workflow

The development of new features should follow the rebase-based workflow:

- Create a new _feature_ branch based on the main branch (`develop`).

- Make commits with your work in the feature branch.

- When there are other new commits in the `develop` branch, you should do a

  [rebase](https://git-scm.com/book/en/v2/Git-Branching-Rebasing) to rewind your

  commits on top of the current develop branch.

    - If there are conflicts, you will need to resolve them manually. Hence, it

      is a good practice to rebase as often as possible (generally as soon as

      the changes appear in the `develop` branch) and to split commits into

      logical parts.

- When your work is ready for review, you can open a [merge request](

  https://mmg-gitlab.fjfi.cvut.cz/gitlab/tnl/tnl-dev/merge_requests/new).

    - If the branch is not ready for merge yet, prepend `[WIP]` to the merge

      request title to indicate _work in progress_ and to prevent a premature

      merge.

    - This is also a good time to squash small commits (e.g. typos, forgotten

      changes or trivial corrections) with relevant bigger commits to make the

      review easier.

- When reviewed, the feature branch can be merged into the develop branch.

The main advantages of this workflow are linear history, clear commits and

reduction of merge conflicts. See [A rebase-based workflow](

https://brokenco.de/2010/04/02/a-rebase-based-workflow.html) and

[Why is rebase-then-merge better than just merge](https://stackoverflow.com/a/457988)

([complement](https://stackoverflow.com/a/804178)) for reference.

 No newline at end of file

if [[ ${WITH_CLANG} == "yes" ]]; then

   export CXX=clang++

   export CC=clang

else

   export CXX=g++

   export CC=gcc

fi

if [[ ${WITH_MPI} == "yes" ]]; then

#       if [ -n "$CXX" ]; then

#          export OMPI_CXX="$CXX"

#       fi

       export CXX=mpicxx

       export CUDA_ARCH_HOST_COMPILER="$CXX"

       export CUDA_HOST_COMPILER=mpicxx

       export CXX=mpicxx

    fi

    if [[ ! -x  "$(command -v mpicc)" ]]; then

       echo "Warning: mpicc is not installed on this system." 

   typedef Containers::Array< Real, Devices::Cuda, Index > CudaArray;

   using namespace std;

   double datasetSize = ( double ) ( loops * size ) * sizeof( Real ) / oneGB;

   double datasetSize = (double) size * sizeof( Real ) / oneGB;

   HostArray hostArray, hostArray2;

   CudaArray deviceArray, deviceArray2;

   const int elements = setHostTestMatrix< HostMatrix >( hostMatrix, elementsPerRow );

   setCudaTestMatrix< DeviceMatrix >( deviceMatrix, elementsPerRow );

   const double datasetSize = ( double ) loops * elements * ( 2 * sizeof( Real ) + sizeof( int ) ) / oneGB;

   const double datasetSize = (double) elements * ( 2 * sizeof( Real ) + sizeof( int ) ) / oneGB;

   // reset function

   auto reset = [&]() {