Viablab

[Texte] Viablab - tous les paramètres du fichier .cpp

Niveau de difficulté

Thématique

Présentation formation

Cette page s'adresse aux utilisateurs de ViabLab qui souhaitent implémenter leur propre problème de viabilité dans ViabLab et qui ont donc à éditer deux fichiers , un .cpp et un json.

Nous décrivons ici toutes les fonctions à implémenter dans le fichier .cpp.

La liste suivante présente les différentes fonctions pouvant être utilisées pour décrire un modèle de viabilité dans VIABLAB. Selon les propriétés du problème à résoudre, seules les fonctions pertinentes doivent être définies.

IMPORTANT : les signatures des fonctions, telles que déclarées dans `WeakDeclarations.h` et décrites ici, doivent être strictement respectées pour que le code puisse compiler et s'exécuter correctement.

Contenu

Déclarations des fonctions à implémenter dans les fichiers de modèle .cpp

Les fonctions à implémenter dépendent des caractéristiques du calcul à effectuer spécifiées dans le .json, nous précisons donc les valeurs des clés pour lesquelles chaque fonction doit être implémentée.

Général
Fonctions

void loadModelData(const ParametersManager *PM);	Cette fonction est appelée au début de l'exécution du programme pour charger les données spécifiques au modèle. Elle peut servir à initialiser des paramètres, charger des données depuis des fichiers ou effectuer toute autre opération de configuration nécessaire avant le début des calculs.
void postProcess(const ParametersManager *PM);	Cette fonction est appelée à la fin de l'exécution du programme pour effectuer des opérations de post-traitement, telles que l'analyse des résultats, la génération de graphiques ou la libération des ressources allouées.

Systèmes continus non tychastiques : DYNAMICS_TYPE = "CC" (temps continu / état continu) ou "DC" (temps discret / état continu) et CONTROL_TYCHASTIC_DIMENSION = 0
Fonctions

void dynamics(const double x, const double u, double *image);	Cette fonction définit la dynamique du système. Elle prend en entrée l'état `x` et la commande `u`, et calcule l'image de la dynamique, c'est-à-dire la dérivée temporelle de l'état ("CC") ou l'état suivant ("DC")
double constraintsXU(const double x, const double u);	Cette fonction définit les contraintes sur la commande, c'est-à-dire l'ensemble U(x). Elle prend en entrée l'état `x` et la commande `u`, et renvoie une valeur de type `double` si les contraintes sont satisfaites, ou la constante `PLUS_INF` dans le cas contraire.	Uniquement si CONTROL_DIMENSION non nul
void jacobian(const double x, const double u, double **jacob);	cette fonction calcule la matrice jacobienne de la dynamique par rapport à l'état `x`. Elle est utilisée pour estimer la constante de Lipschitz de la dynamique lorsque l'option `"LIPSCHITZ_CONSTANT_COMPUTE_METHOD": "ANALYTICAL_CALC"` est sélectionnée. -	Uniquement si DYNAMICS_TYPE = "CC"
void localDynBounds(const double x, double res);	cette fonction calcule des bornes locales sur la dynamique à partir de l'état `x`. Elle est utilisée lorsque l'option `"DYN_BOUND_COMPUTE_METHOD": "ANALYTICAL_CALC"` est sélectionnée.	Uniquement si DYNAMICS_TYPE = "CC"
double constraintsX(const double *x);	Cette fonction définit les contraintes d'état, c'est-à-dire l'ensemble de viabilité K. Elle prend l'état `x` en entrée et renvoie un `double` si les contraintes sont satisfaites, ou la constante `PLUS_INF` dans le cas contraire.
double target(const double *x);	Cette fonction définit l'ensemble cible C. Elle ne doit être définie que pour les problèmes comportant une cible. Elle prend l'état `x` en entrée et renvoie un `double` si les contraintes sont satisfaites, ou la constante `PLUS_INF` dans le cas contraire.	Uniquement si SET_TYPE = "CAPT"
double l(const double x, const double u);	Cette fonction définit la fonction de coût instantané pour les modèles micro-macro. Elle prend en entrée l'état `x` et la commande `u`, et renvoie un nombre à virgule flottante (type `double`) représentant le coût associé au couple (x, u).	Uniquement si GRID_METHOD = "MM"
double m(const double x, const double u);	Cette fonction définit la fonction d'actualisation pour les modèles micro-macro. Elle prend en entrée l'état `x` et la commande `u`.	Uniquement si GRID_METHOD = "MM"

Systèmes continus tychastiques : DYNAMICS_TYPE = "CC" (temps continu / état continu) ou "DC" (temps discret / état continu) et CONTROL_TYCHASTIC_DIMENSION > 0
Fonctions

void dynamics_tych(const double x, const double u, const double v, double image);	Cette fonction définit la dynamique du système lorsque l'incertitude est représentée par une variable de bruit `v`. Elle prend en entrée l'état `x`, la commande `u` et la variable tychastique `v`, et calcule l'image de la dynamique.
double constraintsXU(const double x, const double u);	Cette fonction définit les contraintes sur la commande, c'est-à-dire l'ensemble U(x). Elle prend en entrée l'état `x` et la commande `u`, et renvoie une valeur de type `double` si les contraintes sont satisfaites, ou la constante `PLUS_INF` dans le cas contraire.	Uniquement si CONTROL_DIMENSION non nul
double constraintsXV_tych(const double x, const double v);	Cette fonction définit les contraintes sur l'état et la variable tychastique, c'est-à-dire l'ensemble K. Elle prend en entrée l'état `x` et la variable tychastique `v`, et renvoie un `double` si les contraintes sont satisfaites, ou la constante `PLUS_INF` dans le cas contraire.
void jacobian_tych(const double x, const double u, const double v, double *jacob);	Cette fonction calcule la matrice jacobienne de la dynamique par rapport à l'état `x` lorsque l'incertitude est représentée par `v`. Elle est utilisée pour estimer la constante de Lipschitz lorsque l'option `"LIPSCHITZ_CONSTANT_COMPUTE_METHOD": "ANALYTICAL_CALC"` est sélectionnée.	Uniquement si DYNAMICS_TYPE = "CC"
void localDynBounds(const double x, double res);	cette fonction calcule des bornes locales sur la dynamique à partir de l'état `x`. Elle est utilisée lorsque l'option `"DYN_BOUND_COMPUTE_METHOD": "ANALYTICAL_CALC"` est sélectionnée.	Uniquement si DYNAMICS_TYPE = "CC"
double constraintsX(const double *x);	Cette fonction définit les contraintes d'état, c'est-à-dire l'ensemble de viabilité K. Elle prend l'état `x` en entrée et renvoie un `double` si les contraintes sont satisfaites, ou la constante `PLUS_INF` dans le cas contraire.
double target(const double *x);	Cette fonction définit l'ensemble cible C. Elle ne doit être définie que pour les problèmes comportant une cible. Elle prend l'état `x` en entrée et renvoie un `double` si les contraintes sont satisfaites, ou la constante `PLUS_INF` dans le cas contraire.	Uniquement si SET_TYPE = "CAPT"
double l_tych(const double x, const double u, const double *v);	Cette fonction définit la fonction de coût instantané pour les modèles micro-macro avec incertitude tychastique. Elle prend en entrée l'état `x`, la commande `u` et la variable tychastique `v`, et renvoie un `double` représentant le coût pour le triplet (x, u, v).	Uniquement si GRID_METHOD = "MM"
double m_tych(const double x, const double u, const double *v);	Cette fonction définit la fonction d'actualisation pour les modèles micro-macro avec incertitude tychastique. Elle prend en entrée l'état `x`, la commande `u` et la variable tychastique `v`.	Uniquement si GRID_METHOD = "MM"

Systèmes discrets en temps et espace : DYNAMICS_TYPE = "DD"
Fonctions

void dynamics_fd(const unsigned long long int x, const unsigned long long int u, unsigned long long int *image);	Cette fonction définit la dynamique des systèmes discrets. Elle prend en entrée l'état `x` et la commande `u`, et calcule l'image de la dynamique, c'est-à-dire le nouvel état après application de la commande.
void dynamics_tych_fd(const unsigned long long int x, const unsigned long long int u, const unsigned long long int v, unsigned long long int image);	Cette fonction définit la dynamique de systèmes discrets soumis à une incertitude. Elle prend en entrée l'état `x`, la commande `u` et la variable tychastique `v`, et calcule le nouvel état après application de la commande et de la perturbation tychastique.	Uniquement si CONTROL_TYCHASTIC_DIMENSION>0
double constraintsXU_fd(const unsigned long long int x, const unsigned long long int u);	Cette fonction définit les contraintes de commande pour les systèmes discrets, c'est-à-dire l'ensemble U(x). Elle prend en entrée l'état `x` et la commande `u`, et renvoie un `double` si les contraintes sont satisfaites, ou la constante `PLUS_INF` dans le cas contraire.	Uniquement si CONTROL_DIMENSION>0
double constraintsXUY_fd(const unsigned long long int x, const unsigned long long int u);	????Cette fonction définit des contraintes intégrales sur la commande et l'état.	Uniquement si GRID_METHOD = "MM"
??? y a pas une fonction costraintsXV_fd ???
double constraintsX_fd(const unsigned long long int *x);	Cette fonction définit les contraintes d'état pour les systèmes discrets, c'est-à-dire l'ensemble de viabilité K. Elle prend en entrée l'état `x` et renvoie un `double` si les contraintes sont satisfaites, ou la constante `PLUS_INF` dans le cas contraire.
double target_fd(const unsigned long long int *x);	Cette fonction définit l'ensemble cible C pour les systèmes discrets. Elle prend en entrée l'état `x` et renvoie un `double` si les contraintes sont satisfaites, ou la constante `PLUS_INF` dans le cas contraire.	Uniquement si SET_TYPE = "CAPT"
double l_fd(const unsigned long long int x, const unsigned long long int u);	Cette fonction définit la fonction de coût instantané pour les modèles micro-macro avec des systèmes discrets. Elle prend en entrée l'état `x` et la commande `u`, et renvoie un `double` représentant le coût pour le couple (x, u).
double l_tych_fd(const unsigned long long int x, const unsigned long long int u, const unsigned long long int *v);	Cette fonction définit la fonction de coût instantané pour les modèles micro-macro avec des systèmes tychastiques discrets. Elle prend en entrée l'état `x`, la commande `u` et la variable tychastique `v`, et renvoie une valeur de type `double` représentant le coût associé au triplet (x, u, v).	Uniquement si CONTROL_TYCHASTIC_DIMENSION>0

Systèmes hybrides : DYNAMICS_TYPE = "HC" ou "HD"
Fonctions

Contenu à venir...

void dynamics_hybrid_c(const double x, const unsigned long long int xd, const double u, double image);	Cette fonction définit la partie continue de la dynamique pour les systèmes hybrides. Elle prend en entrée l'état continu `x`, l'état discret `xd` et la commande `u`, et calcule l'image de la dynamique continue.
void dynamics_hybrid_d(const double x, const unsigned long long int xd, const unsigned long long int u, unsigned long long int image);	Cette fonction définit la partie discrète de la dynamique pour les systèmes hybrides. Elle prend en entrée l'état continu `x`, l'état discret `xd` et la commande discrète `u`, et calcule l'image de la dynamique discrète.
void resetMap_hybrid(const double * xc, const unsigned long long int* xd, const unsigned long long int* resetControl, double * imagec, unsigned long long int* imaged);	Cette fonction décrit les « sauts » ou « transitions impulsionnelles » de l'état du système hybride. Elle prend en entrée l'état continu `xc`, l'état discret `xd` et la commande de réinitialisation `resetControl`, et calcule les états continu et discret résultant de la réinitialisation.
double constraintsXU_hybrid(const double x, const unsigned long long int xd, const double u, const unsigned long long int ud);	Cette fonction définit les contraintes de commande pour les systèmes hybrides, c'est-à-dire l'ensemble U(x, xd). Elle prend en entrée l'état continu `x`, l'état discret `xd`, la commande continue `u` et la commande discrète `ud`, et renvoie un `double` si les contraintes sont satisfaites, ou la constante `PLUS_INF` dans le cas contraire.	Uniquement si CONTROL_DIMENSION>0
void jacobian_hybrid(const double x, const unsigned long long int xd, const double u, double *jacob);	Cette fonction calcule la matrice jacobienne de la partie continue de la dynamique par rapport à l'état continu `x` pour les systèmes hybrides. Elle est utilisée pour estimer la constante de Lipschitz de la dynamique continue lorsque l'option `"LIPSCHITZ_CONSTANT_COMPUTE_METHOD": "ANALYTICAL_CALC"` est sélectionnée.
void localDynBounds_hybrid(const double x, const unsigned long long int xd, double *res);	Cette fonction calcule des bornes locales sur la partie continue de la dynamique à partir de l'état continu `x` et de l'état discret `xd`. Elle est utilisée lorsque l'option `"DYN_BOUND_COMPUTE_METHOD": "ANALYTICAL_CALC"` est sélectionnée pour les systèmes hybrides.
double constraintsX_hybrid(const double x, const unsigned long long int xd);	Cette fonction définit les contraintes d'état pour les systèmes hybrides, c'est-à-dire l'ensemble de viabilité K. Elle prend en entrée l'état continu `x` et l'état discret `xd`, et renvoie un `double` si les contraintes sont satisfaites, ou la constante `PLUS_INF` dans le cas contraire.

[Texte] Viablab - tous les paramètres du fichier JSON

Niveau de difficulté

Expert

Thématique

Viablab

Présentation formation

Cette page s'adresse aux utilisateurs de ViabLab qui souhaitent implémenter leur propre problème de viabilité dans ViabLab et qui ont donc à éditer deux fichiers , un .cpp et un json.

Les paramètres définis dans le fichier .json contrôlent l'exécution de ViabLab.

Nous décrivons ici toutes les possibilités paramétrées dans le fichier .json.

Contenu

Les paramètres spécifiés dans le fichier .json concernent 6 objets, les valeurs par défaut sont en gras :

ALGORITHM_PARAMETERS
Clés/Valeurs/Explications

Paramètres qui concernent le calcul à effectuer
Détails

SET_TYPE :	"VIAB" ou 1	Calcul de noyau de viabilité (suﬃxe de nom de ﬁchier en "-viab")
	"CAPT" ou 2	Calcul de bassin de capture (suﬃxe de nom de ﬁchier en "-capt")
	"VIABG" ou 3	Calcul de noyau de viabilité garanti (suﬃxe de nom de ﬁchier en "- viabG")
TARGET_OR_DEPARTURE :	"TARGET" ou 0	???
TARGET_OR_DEPARTURE :	"DEPARTURE" ou 1	???
COMPUTE_MIN_TIME :	true / false	Uniquement pour SET_TYPE vaut "CAPT", le problème à résoudre est-il un problème de temps minimal ?
COMPUTE_VIABLE_SET :	true / false	Faut-il calculer le noyau de viabilité ? Si false, le fichier OUPUT/[OUTPUT_FILEPREFIXE]-viab.dat est recherché pour être chargé comme approximation du noyau de viabilité déjà calculée. Cela permet de travailler sur l'ensemble sans avoir à le recalculer pour générer des trajectoires ou faire des coupes ou des projections
LEVEL :	entier - 0	Uniquement pour un GRID METHOD "MM". Seuil à partir duquel la valeur contenue dans la grille n'est pas conservée (considérée comme hors du noyau de viabilité). Ces valeurs ne sont conservées que si SAVE SUBLEVEL vaut true
GRID_REFINEMENTS_NUMBER :	entier - 0	Uniquement pour GRID_METHOD vaut "BS". Nombre de raﬃnements de grille souhaité. Un raﬃnement de grille est ici un doublement sur chaque axe du nombre de points de l'espace d'état. Permet d'approximer un noyau de viabilité avec maillage plus ﬁn par aﬃnage successifs de noyaux plus grossiers
ITERATION_STOP_LEVEL :	entier - 0	Seuil du nombre de points enlevés dans une itération de l'algorithme du calcul du noyau de viabilité à partir duquel on arrête l'algorithme (si cette valeur vaut 2 et que lors d'une itération on a enlevé 0, 1 ou 2 points de grille, l'algo s'arrête)
REAL_TIME_STEPS_PER_DISCRETE_STEP :	entier - 1	Nombre d'itérations de calcul de la trajectoire réelle à l'aide du schéma numérique de résolution d'équations diﬀérentielles par pas de temps discret.

Paramètres qui concernent les données à enregistrer dans les fichiers de sortie
Détails

SAVE_BOUNDARY :	true / false	Doit-on sauvegarder la frontière du noyau de viabilité dans une ﬁchier ? Le nom du ﬁchier sera OUTPUT/[OUTPUT FILEPREFIX ]-viab-bound.dat
SAVE_PROJECTION :	true / false	Booléen indiquant si la projection de l'ensemble viable choisie à l'aide PROJECTION_AXIS doit êre sauvgardé ou non
PROJECTION_AXIS :	int[STATE_DIMENSION] - [0,..0]	Liste d'entiers indiquant les axes de projection de l'ensemble viable
SAVE_SLICE :	true / false	Doit-on sauvegarder la coupe choisie à l'aide de SLICE_DIRECTIONS et SLICE_LEVELS dans un ﬁchier ? Le nom du ﬁchier sera OUTPUT/[OUTPUT FILEPREFIX ]-Slice.dat
SAVE_SLICE_BOUND :	true / false	Doit-on sauvegarder la frontière de la coupe du noyau de viabilité dans un ﬁchier ? Le nom du ﬁchier sera OUTPUT/ [OUTPUT FILEPREFIX ]-SliceBound.dat
INTERMEDIATE_SAVINGS :	true / false	Uniquement pour un GRID METHOD "BS" et GRID_REFINEMENTS_NUMBER >0. Doit-on sauvegarder tous les raffinements de grille ? Le nombre de raffinements est dicté par NB GRIDREFINEMENTS. Les ﬁchiers de sauvegarde auront la forme "../ OUTPUT/[OUTPUT FILEPREFIX ]- viab-[i].dat" avec i l'indice de la boucle de raffinement (partant de 0)
SAVE_SUBLEVEL :	true / false	????Uniquement pour un GRID METHOD "MM". Booléen indiquant si les sous-niveaux de l'ensemble viable doivent être sauvegardés ou non. Un sous-niveau correspond à l'ensemble des points supprimés lors d'une itération donnée de l'algorithme. Le nom du ﬁchier sera OUTPUT/[OUTPUT FILEPREFIX ]-subLevel.dat
LEVEL :	entier - 0	????Uniquement pour un GRID METHOD "MM". Seuil à partir duquel la valeur contenue dans la grille n'est pas conservée (considérée comme hors du noyau de viabilité). Ces valeurs ne sont conservées que si SAVE SUBLEVEL vaut true
SAVE_VIABSET_LIGHT :	true / false	Indique si l'on doit sauvegarder uniquement les points de grille qui sont dans le noyau de viabilité

GRID_PARAMETERS
Clés/Valeurs/Explications

GRID_METHOD :	"BS"	Représentation sous forme de Bit Set (tableau contenant des valeurs booléennes indiquant si la case se trouve dans le noyau)
	"MM"	Représentation sous forme de tableau de réels, dit "Micro Macro", adapté au calcul des fonctions valeurs
	"HBS"	"BS" hybride : représentation de l'ensemble par une fonction caractéristique avec une part continue et une part discrète
	"HMM"	"MM" hybride : représentation de l'ensemble par une fonction valeur avec une part continue et une part discrète
OUTPUT_PREFIXE :	chaîne de caractère - "Model-"	Préﬁxe utilisé pour les ﬁchiers de sortie du programme (par exemple, si aucun n'est donné, le ﬁchier de données de grille vaudra "Model–grid- data.dat"

Paramètres GRID_METHOD vaut "BS" ou "MM"
Détails

STATE_DIMENSION :	entier - 1	Dimension de l'espace d'états
STATE_MIN_VALUES :	réel[STATE_DIMENSION] - [0, ...,0]	Coordonnée minimale de l'état sur chaque dimension
STATE_MAX_VALUES :	réel[STATE_DIMENSION] - [1, ...,1]	Coordonnée maximale de l'état sur chaque dimension
STATE_GRID_POINTS :	entier[STATE_DIMENSION] - [2, ...2]	Nombre de coordonnées d'état diﬀérentes (de points de grille) sur chaque dimension. Les valeurs des points de grille sont donc les points de coordonnées pour chaque i valent STATE MINVALUES [i] + i*(STATE MAXVALUES [i]- STATE MINVALUES [i])/ (STATE GRIDPOINTS [i] - 1) avec i allant de 0 à n-1 (les tableaux sont indicés à partir de 0).
STATE_PERIODIC :	booléen[STATE_DIMENSION] - [false, .., false]	Indique pour chaque axe si la dimension de l'espace est périodique, c'est-à-dire, si dépasser le bord STATE MAXVALUES ou STATE MINVALUES implique boucler sur le côté opposé de l'espace sur cette dimension
UPPER_LIMIT_IS_NOT_CONSTRAINT :	booléen[STATE_DIMENSION] - [false, .., false]	Indique pour chaque axe si STATE MAX_VALUES n'est pas une contrainte du problème de viabilité mais une contrainte imposée sur la taille de l'espace d'états (si une case d'indice i vaut vrai, un point peut appartenir au noyau de viabilité même si sa coordonnée en i est supérieure à STATE_MAX_VALUES)
LOWER_LIMIT_IS_NOT_CONSTRAINT :	booléen[STATE_DIMENSION] - [false, .., false]	Indique pour chaque axe si STATE MIN_VALUES n'est pas une contrainte du problème de viabilité mais une contrainte imposée sur la taille de l'espace d'états (si une case d'indice i vaut vrai, un point peut appartenir au noyau de viabilité même si sa coordonnée en i est inférieure à STATE_MIN_VALUES)
GRID_MAIN_DIR :	entier - 0	Uniquement pour un GRID METHOD "BS" ou "HBS", entier entre 0 et STATE-DIMENSION - 1qui indique l'indice de la dimension à partir de laquelle sera stocké le tableau de tableaux de bits.
SLICE_DIRECTIONS :	booléen[STATE_DIMENSION] - [false, .., false]	Indique que l'on souhaite regarder une coupe du noyau en "ﬁxant" les valeurs des dimensions dont ce tableau est à true. La valeur ﬁxe peut être choisie à l'aide de SLICE_LEVELS
SLICE_LEVELS :	????[STATE_DIMENSION] - [0, .., 0]	Pour chaque dimension ﬁxée par la coupe, la valeur de la coordonnée qui nous intéresse. La valeur en i sera uniquement prise en compte si SLICE DIRECTIONS [i] vaut true
SLICE_LEVELS_DISCRETE :	????[STATE_DIMENSION] - [0, .., 0]	Identique à SLICE_LEVELS mais pour un espace d'état discret, uniquement lorsque DYNAMICS_TYPE vaut "DD"

Paramètres GRID_METHOD vaut "HBS" ou "HMM"
Détails

GRID_PARAMETERS.HYBRID_CONTINUOUS_SUBGRID :

STATE_DIMENSION :	entier - 1	Dimension de la part continue de l'espace d'états
STATE_MIN_VALUES :	réel[STATE_DIMENSION] - [0, ...,0]	Coordonnée minimale de l'état sur chaque dimension de la part continue de l'espace des états
STATE_MAX_VALUES :	réel[STATE_DIMENSION] - [1, ...,1]	Coordonnée maximale de l'état sur chaque dimension de la part continue de l'espace des états
STATE_GRID_POINTS :	entier[STATE_DIMENSION] - [2, ...2]	Nombre de coordonnées d'état diﬀérentes (de points de grille) sur chaque dimension de la part continue de l'espace des états. Les valeurs des points de grille sont donc les points de coordonnées pour chaque i valent STATE MINVALUES [i] + i*(STATE MAXVALUES [i]- STATE MINVALUES [i])/ (STATE GRIDPOINTS [i] - 1) avec i allant de 0 à n-1 (les tableaux sont indicés à partir de 0).
STATE_PERIODIC :	booléen[STATE_DIMENSION] - [false, .., false]	Indique pour chaque axe si la dimension de de la part continue de l'espace des états est périodique, c'est-à-dire, si dépasser le bord STATE MAXVALUES ou STATE MINVALUES implique boucler sur le côté opposé de l'espace sur cette dimension
UPPER_LIMIT_IS_NOT_CONSTRAINT :	booléen[STATE_DIMENSION] - [false, .., false]	Indique pour chaque dimension de la part continue de l'espace des états si STATE MAX_VALUES n'est pas une contrainte du problème de viabilité mais une contrainte imposée sur la taille de l'espace d'états (si une case d'indice i vaut vrai, un point peut appartenir au noyau de viabilité même si sa coordonnée en i est supérieure à STATE_MAX_VALUES)
LOWER_LIMIT_IS_NOT_CONSTRAINT :	booléen[STATE_DIMENSION] - [false, .., false]	Indique pour chaque dimension de la part continue de l'espace des états si STATE MIN_VALUES n'est pas une contrainte du problème de viabilité mais une contrainte imposée sur la taille de l'espace d'états (si une case d'indice i vaut vrai, un point peut appartenir au noyau de viabilité même si sa coordonnée en i est inférieure à STATE_MIN_VALUES)
GRID_MAIN_DIR :	entier - 0	Uniquement pour un GRID METHOD "BS" ou "HBS", entier entre 0 et STATE-DIMENSION - 1qui indique l'indice de la dimension de la part continue de l'espace des états à partir de laquelle sera stocké le tableau de tableaux de bits.
SLICE_DIRECTIONS :	booléen[STATE_DIMENSION] - [false, .., false]	Indique que l'on souhaite regarder une coupe du noyau en "ﬁxant" les valeurs des dimensions de la part continue de l'espace des états dont ce tableau est à true. La valeur ﬁxe peut être choisie à l'aide de SLICE_LEVELS
SLICE_LEVELS :	????[STATE_DIMENSION] - [0, .., 0]	Pour chaque dimension de la part continue de l'espace des états ﬁxée par la coupe, la valeur de la coordonnée qui nous intéresse. La valeur en i sera uniquement prise en compte si SLICE DIRECTIONS [i] vaut true
HYBRID_CONTINUOUS_SUBGRID :	???	???Uniquement pour les systèmes hybrides, DYNAMICS_TYPE vaut "CH" ou "DH", groupe les paramètres liés à la part continue de la grille
HYBRID_DISCRETE_SUBGRID :	????	???Uniquement pour les systèmes hybrides, DYNAMICS_TYPE vaut "CH" ou "DH", groupe les paramètres liés à la part discrète de la grille

GRID_PARAMETERS.HYBRID_DISCRETE_SUBGRID :

STATE_DIMENSION :	entier - 1	Dimension de la part discrète de l'espace d'états
STATE_GRID_POINTS :	entier[STATE_DIMENSION] - [2, ...2]	Nombre de coordonnées d'état diﬀérentes (de points de grille) sur chaque dimension de la part discrète de l'espace des états
GRID_MAIN_DIR :	entier - 0	????Uniquement pour un GRID METHOD "BS" ou "HBS", entier entre 0 et STATE-DIMENSION - 1qui indique l'indice de la dimension de la part continue de l'espace des états à partir de laquelle sera stocké le tableau de tableaux de bits.
SLICE_DIRECTIONS :	booléen[STATE_DIMENSION] - [false, .., false]	Indique que l'on souhaite regarder une coupe du noyau en "ﬁxant" les valeurs des dimensions de la part discrète de l'espace des états dont ce tableau est à true. La valeur ﬁxe peut être choisie à l'aide de SLICE_LEVELS
SLICE_LEVELS :	????[STATE_DIMENSION] - [0, .., 0]	Pour chaque dimension de la part discrète de l'espace des états ﬁxée par la coupe, la valeur de la coordonnée qui nous intéresse. La valeur en i sera uniquement prise en compte si SLICE DIRECTIONS [i] vaut true

SYSTEM_PARAMETERS
Clés/Valeurs/Explications

DYNAMICS_TYPE :	"CC" ou 1	Continue en temps et en espace. La dynamique est la dérivée du vecteur position.
	"DC" ou 2	Temps discret, espace continu. La dynamique renvoie la valeur du vecteur position en fonction de la valeur de l'itération précédente.
	"DD" ou 3	Discrète en temps et en espace. La dynamique renvoie la valeur du vecteur position en fonction de la valeur de l'itération précédente.
	"CH"	Dynamique hybride, continue en temps, avec des variables d'états continues et discrètes
	"DH"	Dynamique hybride, discrète en temps, avec des variables d'états continues et discrètes
TIME_HORIZON :	réel - 10	Horizon temporel pour les problèmes à horizon fini

Paramètres lorsque DYNAMICS__TYPE vaut "CC" ou "CH"
Détails

TIME_DISCRETIZATION_SCHEME : Méthode d’approximation de la trajectoire réelle	"NO_DISCRETIZATION_SCHEME" ou 0	???Aucune approximation n'est réalisée, la trajectoire réelle est identique à la trajectoire discrète
	"EL" ou 1	Méthode d'Euler
	"RK2" ou 2	Méthode de Runge-Kutta d'ordre 2
	"RK4" ou 3	Méthode de Runge-Kutta d'ordre 4
LIPSCHITZ_CONSTANT_COMPUTE_METHOD : Méthode de calcul de la constante de Lipschitz de la dynamique, utilisée pour déterminer le pas de temps en tout point	"ANALYTICAL" ou 0	La constante de Lipschitz vaudra toujours la valeur donnée pour LIPSCHITZ_CONSTANT possiblement majorée par COST_LIPSCHITZ_CONSTANT
	"ANALYTICAL_CALC" ou 1	????La constante de Lipschitz vaudra le coeﬃcient de valeur absolue maximale de la jacobienne donnée par l'utilisateur en chaque point au travers de la fonction jacobian possiblement majorée par COST_LIPSCHITZ_CONSTANT
	"NUMERICAL_CALC" ou 2 ???"NUMERIC"	La constante de Lipschitz sera calculée pour chaque point à partir des valeurs de la dynamique aux points voisins
LIPSCHITZ_CONSTANT :	réel - 1	Constante de Lipschitz de la dynamique. Celle-ci sera utilisée pour déterminer le pas de temps si LIPSCHITZ CONSTANT_COMPUTE_M ETHOD vaut "ANALYTICAL"
COST_LIPSCHITZ_CONSTANT :	???	Uniquement si GRID_METHOD vaut "MM" ou "HMM, constante de Lipschitz de la fonction de coût. Celle-ci sera utilisée pour déterminer le pas de temps si LIPSCHITZ CONSTANT_COMPUTE_M ETHOD vaut "ANALYTICAL"
DYN_BOUND_COMPUTE_METHOD : Méthode de calcul de la norme maximale de la dynamique en tout point	"ANALYTICAL" ou 0	La norme maximale de la dynamique est la valeur donnée pour DYN_BOUND, possiblement majorée par COST_BOUND_CONSTANT
	"ANALYTICAL_CALC" ou 1	La norme maximale de la dynamique est la plus grande norme inﬁnie renvoyée par localDynBounds parmi toutes les dimensions de l'espace, possiblement majorée par COST_BOUND_CONSTANT
	"NUMERICAL_CALC" ou 2 ???"NUMERIC"	La norme maximale de la dynamique est la valeur de plus grande norme inﬁnie des vecteurs de dynamique pour les contrôles testés, possiblement majorée par COST_BOUND_CONSTANT
DYN_BOUND :	réel - 1	Norme maximale de la dynamique. Celle-ci sera utilisée pour déterminer le pas de temps si DYN_BOUND_COMPUTE_METHOD vaut "ANALYTICAL"
COST_BOUND_CONSTANT :	?????	Uniquement si GRID_METHOD vaut "MM" ou "HMM, norale maximale du coût
IS_TIME_STEP_GLOBAL :	true / false	Si true, le pas d temps est le même pour tous les points de la grille. Sinon, il varie en fonction de la constante de Lipschitz locale
TIME_STEP_FACTOR :	????réel - 1	coefficient multiplicateur appliqué au pas de temps

Paramètres DYNAMICS__TYPE vaut "DC", "DD" ou "DH"
Détails

???J'ai l'impression qu'il n'y en a pas

CONTROL_PARAMETERS
Clés/Valeurs/Explications

CONTROL_DIMENSION :	entier - 1	Dimension de l'espace des contrôles
CONTROL_MIN_VALUES :	réel[CONTROL_DIMENSION] - [0, ..., 0]	Coordonnée minimale des contrôles testés sur chaque dimension
CONTROL_MAX_VALUES :	réel[CONTROL_DIMENSION] - [1, ..., 1]	Coordonnée maximale des contrôles testés sur chaque dimension
CONTROL_GRID_POINTS :	entier[CONTROL_DIMENSION] - [1,...,1]	Nombre de coordonnées de contrôles diﬀérentes testés sur chaque dimension. Les contrôles testé seront ceux ayant pour valeur sur l'axe i CONTROL MINVALUES [i] + i*(CONTROL MAXVALUES [i]- CONTROL MINVALUES [i])/ (CONTROL GRIDPOINTS [i] - 1) avec i allant de 0 à n-1 (les tableaux sont indicés à partir de 0)
CONTROL_TYCHASTIC_DIMENSION :	entier - 1	???? Dimension de l'espace des contrôles tychastiques
CONTROL_TY_MIN_VALUES :	réel[CONTROL_TYCHASTIC_DIMENSION] - [0, ..., 0]	Coordonnée minimale des contrôles tychastiques testés sur chaque dimension
CONTROL_TY_MAX_VALUES :	réel[CONTROL_TYCHASTIC_DIMENSION] - [1, ..., 1]	Coordonnée maximale des contrôles tychastiques testés sur chaque dimension
CONTROL_TY_GRID_POINTS :	entier[CONTROL_TYCHASTIC_DIMENSION] - [1,...,1]	?????Nombre de coordonnées de contrôles tychastiques diﬀérentes testés sur chaque dimension. Les contrôles testé seront ceux ayant pour valeur sur l'axe i CONTROL MINTYVALUES [i] + i*(CONTROL TYMAXVALUES [i]-CONTROL TYMINVALUES [i])/ (CONTROL TYGRIDPOINTS [i] - 1) avec i allant de 0 à n-1 (les tableaux sont indicés à partir de 0)
CONTROL_HYBRID_TRANSITION_DIMENSION :	entier - ???	Uniquement pour les systèmes hybrides ???dimension of the hybrid transition part of the control space,
CONTROL_HT_MIN_VALUES :	???réel[CONTROL_HYBRID_TRANSITION_DIMENSION] - [0, ..., 0]	Uniquement pour les systèmes hybrides ???? minimum values for each dimension of the hybrid transition part of the control space
CONTROL_HT_MAX_VALUES :	???réel[CONTROL_HYBRID_TRANSITION_DIMENSION] - [1, ..., 1]	Uniquement pour les systèmes hybrides ???? maximum values for each dimension of the hybrid transition part of the control space
CONTROL_HT_GRID_POINTS :	???entier[CONTROL_HYBRID_TRANSITION_DIMENSION] - [1, ..., 1]	Uniquement pour les systèmes hybrides ??? number of grid points per dimension of the hybrid transition part of the control space,

TYCHE_PARAMETERS
Clés/Valeurs/Explications

Contenu à venir...

TRAJECTORY_PARAMETERS
Clés/Valeurs/Explications

Contenu à venir...

[Texte] ViabLab (version >=4.0) : exécuter les calculs des applications de viability-theory.org

Niveau de difficulté

Débutant

Domaine

Informatique

Thématique

Viablab

Objectif

La section Applications du site propose des exemples de calculs de viabilité qui contiennent souvent les fichiers permettant de calculer les approximations dont des visualisations sont affichées sur le site.

Ce tutoriel propose la marche à suivre pour effectuer ses calculs en vous-mêmes.

Pré-requis

Avoir installé ViabLab.

Etre allé jusqu'au bout de la procédure qui se termine par les deux commandes cmake < suite à spécifier> puis make (tutoriel d'installation).

Contenu

Pour exécuter les calculs de viabilité associés à une application décrite dans le site :

Se rendre sur la page sui décrit cette application, par exemple : https://viability-theory.org/applications/julia
Au bas de la page, lire la partie Commentaires et télécharger le fichier .cpp et le fichier .json qui correspondent au calcul de viabilité que vous souhaitez effectuer (Attention : les applications de niveau intermédiaire et expert peuvent proposer plusieurs calculs de viabilité). Les noms de ces fichiers suivent la même syntaxe : à partir d'une chaine de caractère spécifique du problème traité, par exemple "modele1", les deux fichiers sont nommés data_modele1.cpp et modele1_params.json.
Copier le fichier .cpp dans le répertoire /source/data de ViabLab et le fichier .json dans le répertoire /INPUT.
Ouvrir un terminal (pour Windows : touche Windows + R, taper powershell)
- Aller dans le répertoire /build de VIABLAB :
```
cd <chemin à spécifier>/build/
```
- exécuter les commandes cmake et make pour compiler le code :
```
cmake ../source
make
```
Exécuter ViabLab en précisant le calcul que vous souhaitez effectuer. Si on garde l'exemple du calcul associé à la chaine de caractères "modele1" :
```
./viabLab data_modele1.so
```

Les fichiers résultats dont les noms commencent par "modele1" sont crées dans le répertoire /OUTPUT.

[Texte] Fichiers de sortie de ViabLab

Niveau de difficulté

Débutant

Thématique

Viablab

Objectif

Décrire la syntaxe des fichiers issus des calculs de ViabLab.

Contenu

Les fichiers issus de l'exécution de ViabLab sont enregistrés dans le répertoire /OUTPUT.

Un calcul génère plusieurs fichiers qui sont nommés avec le même préfixe.
Les suffixes correspondent aux types d'informations contenues dans les fichiers. Ainsi, tous les fichiers de même suffixe suivent la même syntaxe. Sont listés ci-dessous tous les types de fichiers qu'un calcul de ViabLab peut produire :

<prefixe>-grid_data.dat
Fichier de grille - lire le descriptif

Le fichier de grille est un fichier permettant de connaître les dimensions et paramètres de la grille régulière à partir de laquelle s'est effectué le calcul, et ainsi pouvoir lire les autres fichiers.
Ci-dessous l'exemple d'une sortie (du modèle SimplePopGrowth), la description est ajoutée en commentaires après un # :

2  # Dimension de l'espace d'états (STATE_DIMENSION)
# Valeurs minimales des coordonnées d'un état (STATE_MIN_VALUES)
# Il y a autant de valeurs que de dimension de l'espace des états (STATE_DIMENSION)
-2 # première coordonnée du point inférieur (dans toutes les dimensions) de la grille 
-2 # seconde coordonnée du point inférieur (dans toutes les dimensions) de la grille
# Valeurs maximales des coordonnées d'un état (STATE_MAX_VALUES)
# Il y a autant de valeurs que de dimension de l'espace des états (STATE_DIMENSION)
2  # première coordonnée du point supérieur (dans toutes les dimensions) de la grille
2  # seconde coordonnée du point supérieur (dans toutes les dimensions) de la grille
# Nombre de points de grille par dimension (STATE_GRID_POINTS)
4001 # nombre de points de la grille selon le premier axe
4001 # nombre de points de la grille selon le second axe
# Indice des dimensions à conserver pour la coupe (SLICE_DIRS)
0
0    
# Valeur souhaitée pour la dimension fixée (SLICE_VALUES) 
1
1

<prefixe>-viab.dat
Fichier de noyau de viabilité complet - lire le descriptif

Ce fichier contient des lignes représentant les coordonnées des points de grille et leur appartenance au noyau. Chaque ligne contient STATE_DIMENSION coordonnées de points de grille séparées par des espaces et en dernier une valeur.

La signification de la valeur en fin de ligne diffère selon le type de noyau de viabilité calculé (spécfié GRID_METHOD).

Si le noyau de viabilité est un ensemble quelconque (GRID_METHOD vaut “BS” (BitSet)), la dernière valeur vaut 1.0 si le point est dans le noyau de viabilité et 0.0 sinon.
(A noter qu'il est possible de ne pas écrire les valeurs non contenues dans le noyau en mettant SAVE_VIABSET_LIGHT à True, dans quel cas le fichier ne contiendra que les lignes se terminant par 1.0.)

Si le noyau de viabilité est l'épigraphe d'une fonction valeur (GRID_METHOD vaut MM (MicroMacro)), la dernière valeur indique la valeur de la grille en cette position. La dernière valeur vaudra alors PLUS_INF (constante du programme valant 10¹⁵) si la valeur n’est pas contenue dans le noyau et une valeur strictement inférieure si elle appartient au noyau. Tout comme pour un méthode BS, il est possible de ne conserver que les lignes contenues dans le noyau de viabilité.

<prefixe>-viab-bound.dat
Fichier de la frontière du noyau de viabilité - lire le descriptif

Ce fichier contient la liste des points représentant la frontière du noyau de viabilité, c'est à dire les coordonnées des points de la grille qui ont au moins un voisin qui n'appartient pas au noyau calculé. Ces points sont écrits sous forme de STATE_DIMENSION coordonnées séparées par des espaces. Il y a un point par ligne.

<prefixe>-traj-[i].dat et <prefixe>-traj-[i]-Discrete.dat
Fichiers de trajectoires - lire le descriptif

Les fichiers de trajectoire fonctionnent par paires. Chaque fichier de trajectoire “réelle” se terminant en -traj-[i].dat, avec i un entier, est accompagné d’un fichier de trajectoire discrète en traj-[i]-Discrete.dat.

Le fichier de trajectoire réelle est un ensemble de lignes représentant chacune un état, un temps (durée) depuis le début de la trajectoire et un contrôle. Chaque état est représenté par STATE_DIMENSION coordonnées et chaque contrôle par CONTROL_DIMENSION coordonnées.

Si jamais une trajectoire par stratégie est utilisée, et que le paramètre de trajectoire SAVE_PICKING_STRATEGY n’est pas false, la dernière colonne sera une liste de stratégies de la forme “NOM_STRATEGIE_1(indice_dans_liste_de_stratégies),NOM_STRATEGIE_2(indice_dans_liste_de_stratégies),…NOM_STRATEGIE_n(indice_dans_liste_de_stratégies)”. Chaque stratégie à l’intérieur de cette liste est alors une stratégie ayant contribué au choix (modifié la valeur) du contrôle retourné.

Une ligne est donc composée de:

STATE_DIMENSION coordonnées séparées par des espaces représentant un état.
Une durée depuis le début de la trajectoire.
CONTROL_DIMENSION coordonnées séparées par des espaces représentant un contrôle.
Optionellement, une liste de stratégies séparées par des virgules (,) au format “NOM(indice)”, avec “indice” un entier correspondant à l’indice dans la liste des stratégies et “NOM” le nom de la stratégie ayant cet indice dans le JSON.

Pour un schéma numérique donnée (Euler, Runge-Kutta d’ordre 2, Runge-Kutta d’ordre 4), il devrait être possible de retrouver la trajectoire obtenue à l’aide de la dynamique, notée $\Phi(x, u)$ avec $x$ l’état et $u$ le contrôle. On note $x_n$ l’état sur la ligne $n$, $t_n$ la durée en $n$ et $u_n$ le contrôle en $n$.

Pour la méthode d’Euler, on a par exemple que:

$$ x_{n+1} = x_n + (t_{n+1} - t_n)\Phi(x_n, u_n).$$

[Texte] ViabLab (version >=4.0) : première utilisation

Niveau de difficulté

Débutant

Thématique

Viablab

Objectif

Exécuter un des modèles déjà implémentés

En effet, vous avez peut-être remarqué qu'à la fin de l'installation en exécutant la commande

make

les lignes suivantes listent le nom des modèles déjà implémentés :

[ 50%] Built target ARKerU_data
[ 52%] Built target ExempleViabi2D_data
[ 55%] Built target Exemple_multiDim_data
[ 57%] Built target VALIUM
[ 59%] Built target VALIUM_2f
[ 61%] Built target VALIUM_Hybrid
[ 64%] Built target ValiumGaranti_2f
[ 66%] Built target data_Coeur
[ 68%] Built target data_Demo
[ 70%] Built target data_Julia2D
[ 73%] Built target data_Lac
[ 75%] Built target data_LakeCollective
[ 77%] Built target data_LotkaVolterra
[ 79%] Built target data_SimplePopGrowth
[ 82%] Built target data_circle
[ 84%] Built target data_hybridTest
[ 86%] Built target data_labyrinthe
[ 88%] Built target equilibres4D_data
[ 91%] Built target pareto_data
[ 93%] Built target resilience_data
[ 95%] Built target testPendule_data
[ 97%] Built target zermelo_Lmin
[100%] Built target zermelo_tmin

Pré-requis

Avoir installé ViabLab.

Etre allé jusqu'au bout de la procédure qui se termine par les deux commandes cmake < suite à spécifier> puis make (tutoriel d'installation).

Contenu

Pour exécuter un code de modèle déjà présent, une seule ligne de commande est nécessaire.

Pour le modèle SimplePopGrowth par exemple (qui utilise les fichiers data_SimplePopGrowth.cpp dans /source/data, et SimplePopGrowth_params.json dans /INPUT) :

Ouvrir un terminal (pour Windows : touche Windows + R, taper powershell).
Puis la commande :

./viabLab data_SimplePopGrowth.so

Les fichiers résultats dont les noms commencent par "SimplePopGrowth" sont crées dans le répertoire /OUTPUT.

[Texte] Désinstallation de ViabLab (version >=4.0)

Niveau de difficulté

Débutant

Domaine

Informatique

Thématique

Viablab

Objectif

Désinstaller ViabLab

Contenu

Pour désinstaller ViabLab, il suffit de supprimer le répertoire qui le contient.

Pour désinstaller les librairies dont ViabLab dépend que vous avez peut-être dû installer (MySys2, gcc, cmake, make, boost, dlfcn, spdlog pour Windows ; gcc, g++, cmake, boost-devel/libboost-all-dev, spdlog-devel/libspdlog-dev, libcurl-devel/libcurl4 pour Linux ; gcc, g++, cmake, boost, spdlog, libomp pour MacOs) il faut vous reporter à leur propre guide de désintallation.

[Texte] Installation de ViabLab (version>= 4.0 ) à partir de GitHub

Niveau de difficulté

Débutant

Thématique

Viablab

Présentation formation

Comment installer et compiler ViabLab à partir de GitHub.

Contenu

MAC OS
Lire la suite

Contenu à venir...

LINUX
Lire la suite

FEDORA :

Etape 1. Installation des dépendances

Mettre à jour le manager de paquets :

sudo dnf update

Installer les compilateurs C/C++:

Pour vérifier si gcc/g++ sont installés, dans un terminal :

gcc --version
g++ --version

Si gcc/g++ ne sont pas installés sur votre système :

sudo dnf install gcc
sudo dnf install g++

Installer Cmake (version >= 3.22.1) :

Pour vérifier si cmake est installé et connaitre sa version, dans un terminal :

cmake --version

Si ce n'est pas la bonne version , supprimer les versions existantes de CMake, dans un terminal :

sudo dnf remove cmake

Puis

sudo dnf install cmake

Installer git (optionnel - si on souhaite cloner la dernière version de travail du code)

sudo dnf install git

Installer les librairies externes open source

sudo dnf install boost-devel
sudo dnf install spdlog-devel
sudo dnf install libcurl-devel

Etape 2. Copier VIABLAB à partir de GitHub

Dans FileExplorer, créer un répertoire viablab qui contiendra le programme et les résultats

Pour copier ViabLab, trois possibilités :

Télécharger la dernière release à l'adresse https://github.com/lastre-viab/VIABLAB/releases. Dézipper l'archive dans le répertoire viablab.
A l'adresse https://github.com/lastre-viab/VIABLAB, cliquer sur le bouton Code et télécharger le fichier VIABLAB-main.zip.

Dézipper VIABLAB-main.zip dans le répertoire viablab.

Ouvrir un terminal dans le répertoire viablab et cloner le dépôt :

git clone https://github.com/lastre-viab/VIABLAB.git

Etape 3. Compiler VIABLAB

Vous êtes maintenant prêts à compiler le code de ViabLab.

D'abord, aller dans le répertoire build (le créer s'il n'existe pas) de VIABLAB-main dans un terminal (le chemin dépend de votre installation). Par exemple :

cd viablab/VIABLAB-main/build/

Ensuite, exécuter la commande cmake :

cmake ../source

En cas d'erreur pendant le cmake, aller dans le répertoire build et effacer complètement son contenu avant de relancer la commande cmake.

Exécuter ensuite la commande make ci-dessous pour compiler le code :

make

Lorsque la compilation est terminée, l'exécutable viabLab.exe est généré dans le répertoire build.

UBUNTU :

Etape 1. Installation des dépendances

Mettre à jour le manager de paquets apt :

sudo apt update

Installer les compilateurs C/C++:

Pour vérifier si gcc/g++ sont installés, dans un terminal :

gcc --version
g++ --version

Si gcc/g++ ne sont pas installés sur votre système :

sudo apt install gcc
sudo apt install g++

Installer Cmake (version >= 3.22.1) :

Pour vérifier si cmake est installé et connaitre sa version, dans un terminal :

cmake --version

Si ce n'est pas la bonne version , supprimer les versions existantes de CMake, dans un terminal :

sudo apt remove --purge cmake

Puis

sudo apt install cmake

Installer git (optionnel - si on souhaite cloner la dernière version de travail du code)

sudo apt install git

Installer les librairies externes open source

sudo apt install libboost-all-dev
sudo apt install libspdlog-dev
sudo apt install libcurl4

Etape 2. Copier VIABLAB à partir de GitHub

Dans FileExplorer, créer un répertoire viablab qui contiendra le programme et les résultats

Pour copier ViabLab, trois possibilités :

Télécharger la dernière release à l'adresse https://github.com/lastre-viab/VIABLAB/releases. Dézipper l'archive dans le répertoire viablab.
A l'adresse https://github.com/lastre-viab/VIABLAB, cliquer sur le bouton Code et télécharger le fichier VIABLAB-main.zip.

Dézipper VIABLAB-main.zip dans le répertoire viablab.

Ouvrir un terminal dans le répertoire viablab et cloner le dépôt :

git clone https://github.com/lastre-viab/VIABLAB.git

Etape 3. Compiler VIABLAB

Vous êtes maintenant prêts à compiler le code de ViabLab.

D'abord, aller dans le répertoire build (le créer s'il n'existe pas) de VIABLAB-main dans un terminal (le chemin dépend de votre installation). Par exemple :

cd viablab/VIABLAB-main/build/

Ensuite, exécuter la commande cmake :

cmake ../source

En cas d'erreur pendant le cmake, aller dans le répertoire build et effacer complètement son contenu avant de relancer la commande cmake.

Exécuter la commande make ci-dessous pour compiler le code :

make

Lorsque la compilation est terminée, l'exécutable viabLab.exe est généré dans le répertoire build.

WINDOWS
Lire la suite

Etape 1. Installer MSYS2

Suivre les instructions https://www.msys2.org/

Télécharger et lancer l'installateur :

Welcome to the MSYS2 Setup

Choisir le répertoire d'installation :

Installation folder

Suivre les étapes d'installation :

Installation steps

Patienter jusqu'à la fin du processus d'installation :

Wait...

Cliquer sur Finish :

Finish

Une fois installé, le script bash MinGW64 peut être lancé depuis le menu Windows :

Windows menu

MinGW64

Etape 2. Installer les outils de compilation et les dépendances

Msys fournit un gestionnaire de paquets, appelé pacman, qui peut être utilisé pour installer tous les outils de compilation et les dépendances nécessaires. La documentation est ici : https://www.msys2.org/docs/package-management/

Installer les paquets suivants (utiliser les commandes ci-dessous ou chercher dans https://packages.msys2.org/queue en choisissant Mingw64 binaries) :

GCC:
```
pacman -S mingw-w64-x86_64-gcc
```
CMake:
```
pacman -S mingw-w64-x86_64-ccmake
```
Make:
```
pacman -S mingw-w64-x86_64-make
```
Boost:
```
pacman -S mingw-w64-x86_64-boost
```
Dlfcn:
```
pacman -S mingw-w64-x86_64-dlfcn
```
Spdlog:
```
pacman -S mingw-w64-x86_64-spdlog
```

Pour finir l'installation, ajouter à la variable System Path le chemin d'accès aux binaires Mingw64

C:\msys64\mingw64\bin :

Add path variable

Cette opération peut nécessiter le redémarrage de votre ordinateur pour s'assurer que les modifications de la variable System Path ont bien été enregistrées.

Etape 3. Copier VIABLAB dans le répertoire de MSyS

A l'adresse https://github.com/lastre-viab/VIABLAB, cliquer sur le bouton Code et télécharger le fichier .zip VIABLAB-main.zip.

Par défaut, l'interpréteur de commandes MSyS est ouvert dans le dossier /home/nom_utilisateur. Vous pouvez le voir dans l'explorateur de fichiers.

Ouvrir ce dossier dans FileExplorer, créer le dossier dev-cpp qui contiendra le program et les fichiers de sorties et y dézipper VIABLAB-main.zip. Example :

Etape 5. Compiler VIABLAB dans le dossier MSyS

Retourner dans l'interface MSyS MINGW64 (le script bash MinGW64 peut être lancé depuis le menu Windows). Vous êtes prêt pour compiler le code de ViabLab.

First, go to the build folder (create it if it doesn't exist) of VIABLAB in bash (depending on your personal installation). With the example folder shown above :

cd dev-cpp/VIABLAB-main/build/

Then cmake command :

cmake -G"MinGW Makefiles" -D BUILD_LIB=OFF ../source
If you use Eclipse C++ IDE, you can use the cmake command below to generate Eclipse project settings and enable debugging in Eclipse :
```
cmake -G"Eclipse CDT4 - MinGW Makefiles" -D CMAKE_BUILD_TYPE=Debug -D BUILD_LIB=OFF ../source
```
After running CMake, the project is ready to be imported into Eclipse: the build directory (initially empty) contains the data generated by CMake.

In Eclipse, go to the File menu => Import and select the Existing Projects into Workspace option.

Click Next.

Then, in the following window, select the build directory.

Click Finish.

After the import, you will see the project tree in the left panel.

Note that cmake command must be executed only once, on first installation; further, only the make command below will be sufficient to build the code :

mingw32-make

Once the compilation process finished, the executable viabLab.exe is created in build folder.

Théorie mathématique de la viabilité

Université des Antilles, Pôle Martinique

27-04-2026

Niveau de difficulté

Présentation de l'atelier

Cet atelier propose une introduction appliquée à la théorie de la viabilité, notamment dans le cadre des écosystèmes soumis à des contraintes environnementales. Les participants exploreront comment formaliser des politiques durables de gestion à l’aide d’algorithmes de viabilité, et comment modéliser la résilience d’un système via des cas concrets comme l’eutrophisation d’un lac ou la gestion d'une population.

Pour consulter un compte-rendu de cet atelier : ici

Objectifs de l'atelier

Comprendre les bases mathématiques de la viabilité dynamique.
Utiliser des modèles simples pour représenter des contraintes écologiques.
Manipuler un simulateur interactif pour visualiser les trajectoires viables.
Favoriser les échanges entre chercheurs, étudiants et praticiens.

Programme

LUNDI 27 AVRIL

8h15 - Rendez-vous de l’ensemble des participants devant la Bibliothèque Universitaire

SESSION 1 : POSER UN PROBLEME EN VIABILITE

Animateurs : Bates - Lavallée - De Lapparent

8h30 - 8h50	La viabilité mathématique en question ? (Samuel Bates)
8h50 - 9h50	Formuler mathématiquement un problème de viabilité (François Lavallée)

Pause & discussion

10h00-10h30	Exercice sur l'art de poser un problème de viabilité (François Lavallée)
10h30-11h15	Cas de résolution analytique de la viabilité (François Lavallée)
11h15-12h00	Exercice sur la résolution analytique de la viabilité (François Lavallée)

Déjeuner

13h30-14h00	Cas de résolution numérique de la viabilité (François Lavallée)
14h00-15h15	Cas de résolution de viabilité en situation d’incertitude (François Lavallée)

Pause & discussion

15h30-16h00	Cas de résolution de viabilité avec cible terminale (François Lavallée)
16h00-17h00	Viabilité individuelle et collective : cas de résolution de viabilité multi-agent (François Lavallée)
17h00-17h45	Illustration d'un cas de viabilité multi-agent (Alice De Lapparent)
19h00	Diner d'accueil sur inscription (Fort-de-France)

MARDI 28 AVRIL

SESSION 2 : L’INFORMATIQUE DE LA VIABILITE

Animateur : Désilles - Lavallée - Gloglo - Andres-Domenech

8h00-9h00	Préparation à l’informatique de la viabilité (Anya Désilles)
9h00-10h30	Présentation du logiciel Viablab (Anya Désilles)

Pause & discussion

10h45-11h15	Enjeux informatiques sur les noyaux de viabilité (Anya Désilles)
11h15-12h00	Enjeux informatiques sur les trajectoires de viabilité (Anya Désilles)

Déjeuner

13h30-15h30

Atelier de manipulation du Logiciel autour d’un cas d’étude (1/2)
(François Lavallée & Anya Désilles)

Pause & discussion

15h45-17h45	Atelier de manipulation du Logiciel autour d’un cas d’étude (2/2) (François Lavallée & Anya Désilles)
18h00-19h00	Introduction à la Théorie Mathématique de la Viabilité (à destination du Master MBFA : Pablo Andres Domenech, Samuel Bates, Beringer Gloglo)

MERCREDI 29 AVRIL

SESSION 3 : ATELIERS THEMATIQUES D’APPLICATION

Animateurs Désilles - Bates - Gloglo - Andres-Domenech

8h00-10h00

Atelier autour de AgroViablab : Illustration vers une montée en complexité
(Anya Désilles & Samuel Bates)

Pause & discussion

10h15-12h15

Brainstorming autour d’AgroViablab (collectif)

Déjeuner

13h45-15h30	Atelier d’application sur un système monétaire : Illustration vers une simplification de complexité (Beringer Gloglo)
15h30-17h30	Brainstorming sur les applications (collectif)
18h00-19h00	Viabilité d'une union monétaire : le cas de l'UEMOA (à destination du Master MBFA : Béringer Gloglo, Pablo Andres Domenech, Samuel Bates)

JEUDI 30 AVRIL

SESSION 4 : MODELISATION EN VIABILITE

8h00-9h00	Brainstroming autour d’un 1er sujet de modélisation (collectif)
9h00-10h00	Brainstroming autour d’un 2e sujet de modélisation (collectif)

Pause & discussion

10h15-11h15	Brainstroming autour d’un 3e sujet de modélisation (collectif)
11h15-12h00	Brainstroming autour d’un 4e sujet de modélisation (collectif)

13h30 Déjeuner & clôture hors les murs sur inscription (Saint-Pierre)

Description localisation

L'atelier aura lieu à l'Université des Antilles, Pôle Martinique

Liste des participants

Science économique

- Pablo Andres-Domenech
- Valérie Angeon
- Samuel Bates
- Abdoul Cisse
- Issaka Dialga
- Beringer Gloglo
- Thaly Janloup
- Eric Kamwa
- Kevin Spinassou

Mathématique

- Severine Andouze/Bernard
- James Larrouy
- François Lavallée
- Loïc Louison
- Paul Silvere Nuiro

Géographie

- Etienne Delay
- Pastel Audrey

Agronomie

- Alice De-Lapparent

Informatique

- Anya Désilles

[Texte] Calculs de viability-theory.org dans ViabLab

Niveau de difficulté

Intermédiaire

Thématique

Viablab

Présentation formation

Reproduire les calculs des exemples de viability-theory.org :

Aller sur la page du cas d'usage choisi, par exemple l'exemple de Julia, et télécharger les deux fichiers .h et .json associés à l'implémentation dans Viablab.

Copier le fichier .json dans le répertoire ~/ViabLabGui/bin/VIABLAB/INPUT et le fichier .h dans le répertoire ~/ViabLabGui/bin/VIABLAB/source/data/

Editer le fichier ~/ViabLabGui/bin/VIABLAB/source/data/ModelDataInclusion.h

Remplacer la ligne qui commence par string paramsFile avec le nom du fichier .json que vous venez de copier. Par exemple, si ce fichier s'appelle toto .json, il faut écrire écrire :

string paramsFile = "toto.json";

Remplacer dans la ligne qui commence par #include, le nom du fichier .h par celui du fichier que vous venez de copier : si ce fichier se nomme data_toto.h, écrire

#include  "../data//data_toto.h"

Enregistrer le fichier ModelDataInclusion.h

Retourner dans le répertoire ~/ViabLabGui/bin/VIABLAB/build :

Pour Linux :

make

pour créer le fichier exécutable viabLabExe, puis, pour l'exécuter :

./viabLabExe

Pour MacOS :

Générer avec make (en utilisant tous les CPU du Mac pour accélérer la compilation)

make -j$(sysctl -n hw.logicalcpu)

Pour exécuter viabLabExe

 ./viabLabExe

Vous venez de lancer le calcul de noyau de viabilité identique à celui du site !

[Texte] Installation ViabLab with Gui v3.0

Niveau de difficulté

Débutant

Thématique

Viablab

Présentation formation

Sous MAC

Pas possible pour le moment, le fichier binaire n'est disponible que pour Linux et Windows, il faut cloner à partir d'un dépôt.

Sous LINUX

Prérequis :

Avoir installé g++ :

Pour vérifier si g++ est installé, dans un terminal :

g++ --version

Si g++ n'est pas encore installé sur votre système :

sudo apt install g++

Avoir installé cmake version 3.22.1 :

Pour vérifier si cmake est installé et connaitre sa version, dans un terminal :

cmake --version

Si ce n'est pas la bonne version , supprimer les versions existantes de CMake, dans un terminal :

sudo apt remove --purge cmake

Vérifier la version de votre Ubuntu, dans un terminal :

lsb_release -a

Si votre version est 22.04, installer CMake 3.22.1 automatiquement :

    sudo apt update
    sudo apt install cmake

Si votre version n’est pas 22.04, installer les dépendances nécessaires :

    sudo apt update
    sudo apt install -y build-essential libssl-dev

Télécharger CMake 3.22.1 :

       wget https://github.com/Kitware/CMake/releases/download/v3.22.1/cmake-3.22.1.tar.gz

Extraire l'archive :

    tar -zxvf cmake-3.22.1.tar.gz
    cd cmake-3.22.1

Construire et installer :

    ./bootstrap
    make -j$(nproc)      # Compiles using all available CPU cores
    sudo make install

Vérifier la version de cmake, dans un terminal :

cmake --version

Doit afficher cmake version 3.22.1.

Avoir installé l'IDE Eclipse (facultatif)
```
sudo apt-get install -y eclipse-cdt
```

Installation de Viablab :

A l'adresse, https://github.com/lastre-viab/VIABLAB/releases/tag/v3.0
Télécharger InstallerViabLabGui_v1_linux.run
Pour rendre le fichier exécutable

chmod +x InstallerViabLabGui_v1_linux.run

Pour exécuter l'installeur

./InstallerViabLabGui_v1_linux.run

Next - Next - Next - Install - Finish
Puis se placer à l’aide de la commande cd dans le répertoire build : ~/ViabLabGui/bin/VIABLAB/build
puis, pour une utilisation sans l'IDE Eclipse :

cmake -G "Unix Makefiles" ../source
make

L'exécutable viabLabExe apparaît dans le répertoire build !

ou, pour une utilisation avec Eclipse :

cmake -D_ECLIPSE_VERSION=4.5 -DCMAKE_BUILD_TYPE=Debug ../source -G"Eclipse CDT4 - Unix Makefiles" -DCMAKE_ECLIPSE_GENERATE_SOURCE_PROJECT=TRUE

Sous WINDOWS :

Prérequis :

Avoir installé MinGW, une distribution de compilateurs C/C++ GNU pour Windows :

A l'adresse https://sourceforge.net/projects/mingw/files/latest/download , téléchargez l'application MinGW Installation Manager.

Ouvrir cette application

Dans le panneau gauche, développer All packages => MinGW, sélectionner MinGW Base System. Sélectionner dans la liste des packages tous les packages dont le nom contient « pthread », choisir Mark For Installation. Faire de même pour les packages gcc, omp, g++, libstd, mingw s’ils ne sont pas sélectionnés.

Une fois les packages sélectionnés, dans le menu Installation, cliquer sur Apply changes et attendre la fin d’installation.

Ajouter l’emplacement de l’installation MinGW dans la variable PATh du système :

Dans paramètres/settings du système, on cherche environmental/environnement et on clique dans «edit environment variables for your account »

Aller dans Path, edit, new et on copie colle : C:\MinGW\bin

Eteindre et redémarrer l'ordinateur.

Avoir installé cmake version 3.31.7:

Pour vérifier si cmake est installé et connaitre sa version, dans un terminal :

??

Si ce n'est pas la bonne version , supprimer les versions existantes de CMake, dans un terminal :

??

Aller à l'adresse https://github.com/Kitware/CMake/releases/download/v3.31.7/cmake-3.31.7-windows-x86_64.msi pour télécharger le Windows x64 installer.

Vérifier la version de cmake, dans un terminal :

????

Doit afficher cmake version 3.31.7.

Avoir installé Eclipse Environnement de développement intégré) (facultatif) :

Aller à l'adresse https://www.eclipse.org/downloads/packages/release/kepler/sr2/eclipse-ide-cc-developers

Cliquer sur download, à nouveau sur download.

Une fois téléchargé, cliquer sur l’installeur et chosir Eclipse IDE for C/C++ developers

On ‘’launch’’ par la suite (première exécution pour voir que tout fonctionne)

On ‘’launch’’ de nouveau.

Installation de Viablab :

A l'adresse, https://github.com/lastre-viab/VIABLAB/releases/tag/v3.0
Télécharger InstallerViabLabGui_Win.exe
Pour rendre le fichier exécutable

??

Pour exécuter l'installeur

??

Next - Next - Next - Install - Finish
Puis ouvrir un PowerShell, se placer à l’aide de la commande cd dans le répertoire build : ~/ViabLabGui/bin/VIABLAB/build
puis, pour une utilisation sans l'IDE Eclipse :

cmake -G "MinGW Makefiles" ../source
make

L'exécutable viabLabExe apparaît dans le répertoire build :

ou, pour une utilisation avec Eclipse :

cmake -G"Eclipse CDT4 - MinGW Makefiles" -D CMAKE_BUILD_TYPE=Debug ../source

Après l’exécution de cmake le projet est prêt pour être importé dans Eclipse : le répertoire build ( vide au début) contient les données générées par cmake.

Dans Eclipse, aller dans le menu File => Import et sélectionner l’option Existing Projects into Workspace

Cliquer sur Next

Ensuite dans le fenêtre suivante sélectionner le répertoire build

Cliquer sur Finish

Après l’import on voit l’arborescence du projet dans le panneau gauche

S'abonner à Viablab

Viablab

Déclarations des fonctions à implémenter dans les fichiers de modèle .cpp

Exécuter un des modèles déjà implémentés

FEDORA :

Etape 1. Installation des dépendances

Mettre à jour le manager de paquets :

Installer les compilateurs C/C++:

Installer Cmake (version >= 3.22.1) :

Installer git (optionnel - si on souhaite cloner la dernière version de travail du code)

Installer les librairies externes open source

Etape 2. Copier VIABLAB à partir de GitHub

Etape 3. Compiler VIABLAB

UBUNTU :

Etape 1. Installation des dépendances

Mettre à jour le manager de paquets apt :

Installer les compilateurs C/C++:

Installer Cmake (version >= 3.22.1) :

Installer git (optionnel - si on souhaite cloner la dernière version de travail du code)

Installer les librairies externes open source

Etape 2. Copier VIABLAB à partir de GitHub

Etape 3. Compiler VIABLAB

Etape 1. Installer MSYS2

Etape 2. Installer les outils de compilation et les dépendances

Etape 3. Copier VIABLAB dans le répertoire de MSyS

Etape 5. Compiler VIABLAB dans le dossier MSyS

Sous MAC

Sous LINUX

Sous WINDOWS :