Alien provides two API move and ref. However they are not compatible.
Linking with both at the same time results in weird behavior. For example, objects are defined in both libraries and their dtors can collide.

To solve this, we can either:

1. Find a way to forbid linking with both libraries at the same time;
2. Putting APIs in their own namespace.

The first solution forbids an user to exploit both APIs which may be interesting on a large code.

make install is not properly tested.

The goal is for Alien to load third party library plugins dynamically.
As a consequence, Alien libraries are not any more known at compile time and the template way to dispatch across plugin is not possible.

Base features:

• #141
• #142
• #143

Advanced features:

• #144
• #145
• Dynamic loading for Windows

Alien needs a more robust error handling.

C++ exceptions are notoriously hard to make work in parallel, so return values might be a better way.

std::expected might be a solution but it is not standard yet (https://wg21.link/P0323R10).
In some places, we can use std::optional which is supported.

This way to deal with error has been proven successful in Haskell and Rust.

We need to explain how Alien works:

• Space, Distribution, ...
• Different APIs
• Adding functionalities by adding new objects (builders, ...)

We can use CMakePresets files for configuring different flavors of Alien.

Describe the bug
Some functions in Alien are not implemented. As they are also not tested, it does not fail in our tests.

Expected behavior
No unimplemented functions.

Additional context
Interface simplification can also help to solve this issue.

Unit tests must access and stress internal components of Alien. Currently, to access these objects, they have to be exported, so they can be called by the consumer test program.

This leads to exposing a lot of internal objects to end-user.

We should rethink the way we make these tests, to integrate them deeper in Alien and avoid leaking private API.

Simplify build system by avoiding the framework overcost.

Describe the bug
The test in plugins/petsc/test/test_petsc.cpp failed with an out of range error in solve. A vector (x or b) is not allocated.

To Reproduce
OS : archlinux ; GCC 12 ; PETSC 3.18

Expected behavior
Test works.

Add tutorial for move API

Describe the bug
Symbols are not properly defined for linking on windows

To Reproduce
Steps to reproduce the behavior:

https://github.com/arcaneframework/framework-ci/runs/3027682774?check_suite_focus=true

Expected behavior
Correct linking on windows.

Additional context
Is AlienExport.h missing in some headers ?

Thanks @grospelliergilles for reporting.

Using #47 we can design a small test library that works with all Alien plugins.

Alien should provide efficient builder to fill and update a matrix during Newton iterations where the matrix nnz pattern does not change.

Documentation should be at the top of the project, overseeing core concepts as well as plugins and usage.

Ensure that we can export matrices and vectors from both apis

utils directory contains a lot of code that looks either useless or at least easy to replace.

To review:

• parameter_manager
• ArrayUtils.h
• Precomp.h: too many includes
• VMap.h: unordered_map should be a good replacement
• AlienTypes.h : see #36
• Remove unneeded stl header includes such as iostream

The way move API is implemented should be improved.
Code relies too much on inheritance and implementation uses bad C++ practices such as calling virtual member functions from constructors.

• Remove MoveObject pattern
• Do not rely on inheritance to access core functions, use composition instead.

Use of composition will allows to control and choose what methods can be accessed from the interface instead of exposing all prototypes, some of which having been designed for other APIs.

Implement a simpler DirectMatrixBuilder using DoKMatrix.

When packaging Alien it should be great to disable all optional dependencies, making their use explicit (and mandatory when selected).

Generic solver parameters

Alien currently has options to specify solver parameters, but these options are specific for a given solver lib. The goal of this request is to design and implement a way to have generic options that works with all libraries.

• list solver and preconditioner options that we want to share between libraries,
• choose names for these options,
• describe an implementation to pass these options to solver libraries.

Solver options

Algorithms

• CG
• BiCGStab (which order ?)
• GMRES (size of the basis ? orthogonalization method ?)

Control

• maximum number of iterations
• residual tolerance (in which norm ? explicit ?)

Preconditioners

• Diagonal
• Incomplete factorization (IC, ILU [ILU(k) or ILU(t) ?])
• AMG (cycle, smoother, ?)

Implementation proposal: using converters

It would be great to handle parameters like we do with matrices and vectors. We do not need to specify a common parameters interface that would be inherited by solver libraries: we can write, in each plugin a specific converter that handle how to express the generic parameters with the specific option object.

If so, we can have very specific solver options in plugins (that match the external solver interface) and a common way to call solvers with very high level parameters.

Notes

Needs were formulated by end-users for direct use from C++, but it might be also a good way to provide a C API (see #35) and thus derive Alien's API for different languages like Python or Rust.

Install tutorials and examples and make them ready to compile

Add a CI with upstream libraries to anticipate breaking API changes.

CMake is not able to correctly find PETSc installed from Ubuntu's packages.

Describe the bug
IFPEN foss images cannot properly pass tests due to timeouts in mpi.
So pipeline overall status is not relevant.

To Reproduce
Random

Additional context
Same for Arcane

DoK objects have now more functionalities and nice end-user properties (being able to fill up any nnz), it should be great to not have to convert to SimpleCSR before using hypre or PETSc plugins.

On the long run, it can also simplify Builders and IndexManagers as remote matrix's rows can be filled.

Hi the team !

A guide to contributions would be very helpful. Actually done in the README which would be a show case of the lib.

For instance

• Quickstart guide for first-time contributors (Create a fork, send a PR, etc.)
• Code development (Codebase structure, formating, run tests, etc.)
• Writing documentation
• Etc.

Being able to export matrices and vectors to file system is an important need for:

1. studying linear problem behavior
2. performing store/load of artifacts

We can use existing file format, such as MatrixMarket, Harwell-Boeing, ...
Or, we can design our own and provide converters. One way to do this should be to have a json output. Furthermore, we can have binary exactness using floating point literals, and small file sizes using file compression.

Describe the bug
hypre plugin tests rely unconditionnaly on googletest and are always enabled. So when no googletest is found, cmake fails.

To Reproduce
Simply compile without any googletest available.
See #57 .

Expected behavior
googletest should not be mandatory to build hypre plugin.

Error
error when linking alien_core targer blas not found

To Reproduce
On archlinux (6.0.9.arch1-1), gcc 12.1, CMake 3.25

Expected behavior
Link ok

Additional context
To solve the problem, a find_package and an add to alien_core target_link_libraries must be done for blas

file
alien/standalone/src/core/alien/kernels/simple_csr/algebra/alien_cblas.h
redefines some function prototypes for cblas which conflict with cblas API provided by mkl 2021 cblas.
Proposal:
#ifdef ALIEN_USE_CBLAS
#include <mkl_cblas.h>
#elifdef ALIEN_USE_OPENBLAS.....

When dumping a non parallel matrix the code exit with a petsc error:
*I-Internal Converting DoKMatrix: 0x784e50 to SimpleCSRMatrix: 0x7887b0
*I-Internal Converting SimpleCSRMatrix: 0x7887b0 to PETScMatrix 0x785be0
*I-Internal Matrix range : [0:99]
[0]PETSC ERROR: --------------------- Error Message --------------------------------------------------------------
[0]PETSC ERROR: Argument out of range
[0]PETSC ERROR: Comm must be of size 1

It can be reproduced with (in RedistributorAlgebraTestFramework)

Alien::RedistributedMatrix Aa(A, redist);
if(Environment::parallelMng()->commRank() == 0)
    dump(Aa);

PETSc_initialize must be called by user, should be hidden in Alien.

If user does not call if builder.reserve(size) and builder.allocate() adding elements can lead to segfault.

We should at least return a error and never segfault.

Allowing to not call the reserve nor the allocate routines should be a better interface.

Should be integrated directly into Alien directory.

Discussed in #90

The installed file include/alien/kernels/simple_csr/algebra/C_BLAS.h refers to alien_cblas.h which is not installed.

A+
Thomas

Redistributor and DoK objects can redistribute their data across MPI processors.

However, the current implementation is not very efficient:

1. It performs several communications of the same pattern (rows, then cols, then values). This is related to Arccore's MessagePassing that only support Arcane's scalar types.
2. It copies and moves even local data.

As acted in today meeting, we will remove framework directory.

This means:
Alien will no longer compile without having Arccon and Arccore installed first.

Expected gain is for people who install both Alien and Arcane to be forced to have coherent a Arccore between the two.

No change for tarball users.

• Update README for Alien developers
• Simplify CMake

We have several MatrixMarket readers, one that groups all functionalities should be a lot better.

@guignont @gratienj

Alien should provide a stable C API, not based on string parsing.

This API should be used to:

• Allow calls from other languages Fortran, Python, Rust, ...
• Implement some parts of Alien using other language than C++

AlienTypes.h was designed to be able to switch between Arcane arrays and STL.
It is not necessary now that Arccore is a mandatory dependency.

Describe the bug
Install phase also copies test binaries in /bin directory.

To Reproduce
make install

Expected behavior
Unit tests and tutorial binaries should not be installed!

Additional context
Related to #4

Use action to build and upload base container when specification is modified