@@ -156,7 +156,7 @@ où $\%$ veut est l'opération modulo.
Ce simulateur prendra en entrée le nombre de points de maillage sur
chacune des deux dimensions $n_x$ et $n_y$, les composantes de la force $\ug$
(qui doit être plus petite que $10^{-4}$),
(qui doit être plus petite que $10^{-5}$),
la valeur de $\tau$ (qui doit être dans l'intervalle $]1/2, 2]$).
Il faudra ensuite créer deux tableaux de nombres réels, `f_in` et
`f_out`, représentant
...
...
@@ -308,6 +308,10 @@ Finalement, à l'aide de la souris il faut que vous soyez capables
de créer des parois avec le clic gauche et de les effacer avec
le clic droit.
La gestion de la souris et du clavier étant un peu compliquée,
il faut tester les événements souris et clavier **indépendemment**.
Le clic souris en revanche est testé en une fois (clic gauche ou clic doit).
Vous trouverez sur `cyberlearn` quelques fonctions pouvant vous
être utiles utilisant la `SDL2` pour réaliser ces étapes.
Vous y trouverez également une petite vidéo de ce à quoi peut ressembler le résultat.
...
...
@@ -316,7 +320,58 @@ Vous y trouverez également une petite vidéo de ce à quoi peut ressembler le r
Écrire une version concurrente du projet.
Pour ce faire il faut un thread (le thread principal qui gère les
entrées-sorties et l'interaction avec le clavier et la souris).
Le programme est organisé de la manière suivante :
- Le thread principal (fonction `main`) s’occupe seulement de gérer les arguments de la ligne de commande, initialiser les structures de données, et créer les threads.
- Un thread est dédié à la gestion du clavier.
- Un ou plusieurs threads *travailleurs* sont dédiés au calcul de l'évolution temporelle du fluide (les étapes de collision-propagation). Il est **important** que tous les threads *travailleurs* se synchronisent après les étapes de collision et de propagation afin de pouvoir effectuer l'affichage. Faites en sortes que la quantité de travail soit aussi équitable que possible entre les threads.
- Un seul thread est dédié à **l’affichage**.
## Cahier des charges
- Le programme à développer sera nommé `lbm` et sa syntaxe est la suivante :
``` {.changelog}
lbm <width> <height> <tau> <gx> <gy> <workers>
- width et height sont des entiers représentant les dimensions du domaine
de jeu (>= 100).
- tau est le temps de relaxation ]0.5, 2].
- gy et gy sont les valeurs de chaque composante de la force [0.0, 0.00001].
- workers est un entier (>= 1) donnant le nombre de threads travailleurs.
Exemple : ./lbm 400 400 0.8 0.00001 0.0 10
```
- Un `makefile` devra être présent à la racine et aura comme première règle la compilation de votre programme produisant un exécutable nommé `lbm`.
- Le thread d’affichage s’occupera de créer le contexte graphique (fonction `gfx_create`) et d’afficher le domaine de simulation (fonction `gfx_present`). Attention à ce que l’affichage du domaine ne soit réalisé qu’une fois celui-ci **entièrement** mis à jour!
- L’affichage doit être réalisé avec les fonctions fournies (`gfx_create`, `gfx_present`, etc.); cf. section suivante.
- Le thread responsable de la gestion du clavier testera, si une touche a été pressée ou si un clic gauche/droite à été effecté. Le programme se terminera, proprement, une fois la touche d’échappement (`ESCAPE`) pressée.
- La division du travail entre les threads travailleurs doit être la plus équitable possible par rapport au nombre de cellules.
-**Toute attente active est prohibée.**
- Aucune variable globale n’est autorisée. À noter qu’il est permis d’utiliser des constantes globales (déclarées via la directive `#define` ou le mot-clé `const`).
## Informations utiles
### Options de compilation
Nous vous conseillons de compiler votre code avec gcc et les options de compilation suivantes :
De plus, si vous utilisez des barrières dans votre code, vous devez inclure cette directive :
```{.c}
#define _GNU_SOURCE
```
### Affichage graphique
Pour réaliser le rendu graphique de votre programme, vous **devez** utiliser la librairie `gfx` incluse dans le repository du TP.
# Travail à rendre
N’oubliez pas de lire attentivement le document "*Consignes Travaux Pratiques.pdf*" disponible sur la page CyberLearn du cours. Les consignes supplémentaires et spécifiques pour ce travail sont les suivantes :
- Ce travail sera réalisé par **groupes de deux**. Si le nombre d'étudiants est impair, il n'y aura qu'un seul groupe de trois.
- Vous serez forcés d'utiliser **git et gitedu.hesge.ch**. Vous devrez "forker" ce repository et suivre à la lettre la procédure contenue dans l'énoncé, sous peine de pénalités. Il est exigé qu'au minimum une version (donc un commit) soit réalisée par séance de TP, et ce jusqu'au rendu du travail.
- Vous devrez produire un schéma du fil d'exécution et synchronisation entre threads (dans un format d'images usuel), comme illustré à la figure \ref{schema}, qui vous servira de support pour l'interrogation orale (voir le point ci-après), mais qui vous aidera à clarifier le travail à effectuer pour rendre votre code concurrent.
- Le rendu du travail est fixé au **dimanche 9 juin 2019 à 23h30** (la version antérieure ou égale à cette date sera récupérée).
- Suite au rendu, vous devrez effectuer une présentation orale de votre travail le **11 juin 2019**. La note sera une combinaison du code rendu et de la présentation.
### Schéma du fil d'exécution et de synchronisation
Pour appuyer vos explications à l'oral, vous devrez produire un schéma du fil d'exécution du code et de la synchronisation entre threads, à rendre avec votre code. La figure \ref{schema} illustre un exemple d'un tel schéma. La syntaxe à utiliser est libre, mais les mécanismes de synchronisation doivent clairement apparaître.
Les autres threads (en nombre variable) font le calcul de l'évolution du fluide.
\ No newline at end of file
{#fig:schema width=65%}
