#LyX 1.6.7 created this file. For more info see http://www.lyx.org/ \lyxformat 345 \begin_document \begin_header \textclass article \use_default_options true \language english \inputencoding auto \font_roman default \font_sans default \font_typewriter default \font_default_family default \font_sc false \font_osf false \font_sf_scale 100 \font_tt_scale 100 \graphics default \paperfontsize default \use_hyperref false \papersize default \use_geometry false \use_amsmath 1 \use_esint 1 \cite_engine basic \use_bibtopic false \paperorientation portrait \secnumdepth 3 \tocdepth 3 \paragraph_separation indent \defskip medskip \quotes_language english \papercolumns 1 \papersides 1 \paperpagestyle default \tracking_changes false \output_changes false \author "" \end_header \begin_body \begin_layout Title Virtual Hadron Collider \begin_inset Newline newline \end_inset Conception \end_layout \begin_layout Author Jakob Odersky \begin_inset ERT status open \begin_layout Plain Layout \backslash and \end_layout \end_inset Christian Vázquez \end_layout \begin_layout Part* Introduction \end_layout \begin_layout Standard Lors du projet nous avons suivi en général les indications données. Quelques fois, nous avons tout de même suivi nos propres idées qui n'étaient pas compatibles avec les propositions officielles. Dans ce texte sont décris en bref nos propres idées et leur implication sur la conception du projet. Pour une documentation plus complète est détaillée, il est conseillé de voir les commentaires du code ou la documentation générée par les commentaires du code. \end_layout \begin_layout Part* Structure \end_layout \begin_layout Standard Le dosier du projet, nommé `vhc' (pour `Virtual Hadron Collider'), est structuré de la manière suivante: \end_layout \begin_layout Standard \begin_inset listings lstparams "basicstyle={\ttfamily}" inline false status open \begin_layout Plain Layout vhc \end_layout \begin_layout Plain Layout |-- bin \end_layout \begin_layout Plain Layout | |-- gui \end_layout \begin_layout Plain Layout | |-- main \end_layout \begin_layout Plain Layout | `-- test \end_layout \begin_layout Plain Layout |-- doc \end_layout \begin_layout Plain Layout |-- Doxyfile \end_layout \begin_layout Plain Layout |-- JOURNAL.txt \end_layout \begin_layout Plain Layout |-- Makefile \end_layout \begin_layout Plain Layout |-- CONCEPTION.pdf \end_layout \begin_layout Plain Layout |-- REPONSES.pdf \end_layout \begin_layout Plain Layout |-- README.txt \end_layout \begin_layout Plain Layout `-- src \end_layout \begin_layout Plain Layout |-- gui \end_layout \begin_layout Plain Layout |-- main \end_layout \begin_layout Plain Layout `-- test \end_layout \end_inset \end_layout \begin_layout Section* vhc \end_layout \begin_layout Standard Le répertoire principale (dit `de base') du projet est est `vhc'. Dans celui-ci se trouvent les fichiers expliqués dans la description officielle du projet. Notamment: \end_layout \begin_layout Itemize JOURNAL \end_layout \begin_layout Itemize REPONSES \end_layout \begin_layout Itemize README \end_layout \begin_layout Itemize Makefile \end_layout \begin_layout Standard Il contient de plus le fichier `Doxyfile' utilisé pour générer de la documentati on du code source. \end_layout \begin_layout Section* src \end_layout \begin_layout Standard Ce répertoire contient tout le code source, donc les fichiers les plus important s du projet! Le code source est lui-meme reparti dans les sous-répertoires suivantes: \end_layout \begin_layout Itemize main \begin_inset Newline newline \end_inset Contient le code source principale, c'est à dire tout les fichiers sources du simulateur. \begin_inset Newline newline \end_inset Exemples: Vector3D.cc, Vector3D.h, Particle.cc, etc... \end_layout \begin_layout Itemize gui \begin_inset Newline newline \end_inset Contient le code relatif à l'interface graphique. \end_layout \begin_layout Itemize test \begin_inset Newline newline \end_inset Contient le code source des tests. Les fichiers tests contenant une fonction `main' devraient se terminer avec `Test'. \begin_inset Newline newline \end_inset Exemples: Vector3DTest.cc, etc... \end_layout \begin_layout Section* doc \end_layout \begin_layout Standard Contient de la documentation générée automatiquement par un outil comme `doxygen'. \end_layout \begin_layout Section* bin \end_layout \begin_layout Standard Contient les fichiers binaires (i.e. executables, objets, librairies etc...) compilés du code source. La structure de ce répertoire est identique a celle de `src', c'est-à-dire que les tests seront compilés dans `bin/test/' et les sources principaux dans `bin/main/'. \end_layout \begin_layout Part* Makefiles \end_layout \begin_layout Standard Afin d'automatiser le processus de compilation, un Makefile est présent dans le répertoire de base. A cause de la compléxité du répertoire source, le Makefile est récursif. Cela signifie que ce Makefile ne fait que de déléguer les commandes à deux makefiles contenus dans les répertoires src/main et src/test. Ainsi, lorsqu'on ajoute/supprime des fichiers des répertoires précédents, il suffit de modifier le Makefile contenu dans le répertoire respectif. En général, il ne faut pas modifer le Makefile de base. \end_layout \begin_layout Standard Voici les commandes make de base: \end_layout \begin_layout Itemize clean - supprime les fichiers générés \end_layout \begin_layout Itemize build - compile les sources principaux \end_layout \begin_layout Itemize test - lance tous les tests \end_layout \begin_layout Itemize gui - compile et lance l'interface graphique \end_layout \begin_layout Itemize doc - genere la documentation avec doxygen \end_layout \begin_layout Standard Pour plus d'informations voir les commantaires des Makefiles. \end_layout \begin_layout Part* Vecteurs \end_layout \begin_layout Standard En commencant par la base. Nous avons choisi de garder un vecteur immuable. Il n'a donc pas de méthodes non-const. Ceci parait naturel pour un vecteur et facilite le raisonement sur la vie d'une de ses instances. \end_layout \begin_layout Standard Pour des raisons d'efficacité, nous avons tout de même implémenté un vecteur muable. Celui-ci hérite d'un vecteur et défini en plus des méthodes non-const (tel que +=). \end_layout \begin_layout Part* Eléments \end_layout \begin_layout Standard La hierarchie des éléments ressemble à celle proposée par la description officielle du projet: \end_layout \begin_layout Standard Tout en haut il y a un élément abstrait \emph on Element \emph default . De celui-ci héritent les différents éléments géométriques: un droit \emph on StraightElement \emph default , un courbé \emph on CurvedElement \emph default et un élément composé \emph on CompositeElement \emph default . Les éléments concrets sont donc définis en héritant d'un de ces trois éléments. \end_layout \begin_layout Standard Pour considérer les champs électriques et magnétiques, nous avons simplement déclaré des méthodes virtuelle \emph on getElectricFieldAt(const Vector3D& position) \emph default et \emph on getMagneticFieldAt(const Vector3D& position) \emph default dans la classe de base \emph on Element \emph default qui renvoyent zéro pour tout position. Les élements concrets peuvent donc redéfinir ces méthodes. \end_layout \begin_layout Standard Un autre aspect assez important est la détermination de la contenance d'un particule dans un élément. Comme nous avons décidés que nos éléments peuvent être décentrés (pas de centre commun avec l'accélérateur) la méthode de détermination de passage d'une particule, telle que proposée ne fonctionne plus. Nous avons donc décidé de créer un système de positionement des particules dans les élements. Une particule peut être testée si elle est après, avant ou a côté d'un élément. Ceci facilite aussi la possibilité des particules de tourner à contre-sens: ces particules n'ont qu'a vérifier si elles se situent avant leurs éléments respectifs pour passer aux suivants. \end_layout \begin_layout Part* Faisceaux \end_layout \begin_layout Standard En créant un faisceau, l'utilisateur n'a pas besoin de se soucier dans quelle élément se trouve une particule. Il ne doit que l'ajouter à un accélérateur et il s'occupe du reste. \end_layout \begin_layout Standard Cette simplicité est possible grâce a notre conception de faisceaux. Chaque faisceau à une méthode \emph on initializeParticles() \emph default qui initialise les particules du faisceau. Ainsi, lorsqu'on ajoute un faisceau à l'accélerateur, celui-ci appelle la méthode d'initialisation des faisceaux, positionne les particules dans leurs éléments respectifs et supprime tous ceux qui ne sont pas contenus dans un élément. \end_layout \begin_layout Part* Accélérateur \end_layout \begin_layout Standard Un accélérateur est l'objet principale d'un simulation. Il contient tous les éléments et faisceaux de la simulation. Afin de faciliter son utilisation, nous avons décidés q'un accélérateur contiendrait et sera responsable pour toutes ses composantes. Ainsi lorsqu'un élément ou une particule est ajoutée à un accélérateur, celle-ci est copiée dedans. \end_layout \begin_layout Standard Pour garantir la validité d'un accélérateur, celui-ci est \begin_inset Quotes eld \end_inset fermé \begin_inset Quotes erd \end_inset avant une simulation. Concrètement cela veut dire qu'après avoir ajouter des éléments dans un accélérateur, une méthode est appelée pour vérifier sa continuité. \end_layout \begin_layout Part* Forces inter-particules \end_layout \begin_layout Standard Pour ajouter les forces interparticules à la simulation nous avons instauré la notion d' \emph on interacteur \emph default . Un interacteur (classe abstraite \emph on Interactor \emph default ) est un objet qui gère les interactions entre particules. Chaque accélérateur en a un. Concrètement un interacteur possède une méthode \emph on applyInteractions() \emph default qui applique tous les forces interparticules entre les particules gérés. Or comme les particules d'un accélarateur varient sans cesse et sont souvant supprimés, il faudrait un système plus efficace pour connaître les particules à gérer que d'accéder directement aux particules de l'accélérateur. Pour ceci, nous avons introduits le design pattern (motif de programmation?) des publishers/listeners. \end_layout \begin_layout Standard Un \emph on publisher \emph default est une classe qui peut publier des évènements et un \emph on listener \emph default peut agir à la récéption d'un évènement. De plus, un listener doit se souscrire à un publisher pour être informé de ses évènements. Ainsi, dans notre projet, un faisceaux est un publisher et un interacteur un listener. Ceci implique que lorsqu'une particule est ajoutée à un faisceau, l'interacteur est informé et peut ajouter la particule à la collection des particules à gérer. \end_layout \begin_layout Standard Cette conception donne de nombreux avantages. Premièrement, il est facile de changer de type de détecteur. On peut par exemple remplacer un détecteur force-brute avec un détecteur plus sophistiqué en une ligne de code. Deuxièmenent, il est très facile de concevoire ses propres détecteurs. Il suffit de créer une classe héritant de \emph on Interactor \emph default . Troisièmement, grâce au motif publisher/listener, on peut créer un interacteur qui choisit les particules à gérer. Ceci permet doc de facilement transformer un interacteur gérant tous les interactions particules en un interacteur ne gérant que les interactions particules dans un faisceau. \end_layout \begin_layout Part* Interface graphique \end_layout \begin_layout Standard Notre projet utilise OpenGL et Qt pour l'interface graphique. Pour ne pas rendre l'entièreté du projet dépendant de ces deux frameworks nous avons utilisé une autre méthode que celle de la \begin_inset Quotes eld \end_inset spécialisation graphique \begin_inset Quotes erd \end_inset proposée. \end_layout \begin_layout Standard Nous avons créés des rendeur graphiques ( \emph on Renderer \emph default ). Ces rendeurs sont spécialisés pour dessiner des objets d'un certain type. Un rendeur de faisceaux, par exemple, peut dessiner des faisceaux. Or, pour des hiérarchies de classes nécéssitant un traitement différent pour chaque type concret d'instance (par exemple les éléments: un élément droit ne peut pas être déssiné comme un élément courbe!), cette méthode n'est pas très élégante et nécéssite une quantité énorme de code. \end_layout \begin_layout Standard Pour contourner cela nous avons donc implémenté le motif de programmation des visiteurs. C'est \begin_inset Quotes eld \end_inset une manière de séparer un algorithme de la structure d'un objet \begin_inset Quotes erd \end_inset \begin_inset Foot status open \begin_layout Plain Layout (http://fr.wikipedia.org/wiki/Visiteur_%28motif_de_conception%29) \end_layout \end_inset et s'avère particulièrement utile pour des structures récursives, telles que les éléments composés. Concrètement cela signifie qu'un rendeur d'éléments est un visiteur d'éléments. Voir les commentaires du code pour plus de detailles. \end_layout \begin_layout Part* Conclusion \end_layout \begin_layout Standard En conclusion, on remarque que nos déviations du projet ne sont pas dues à cause d'un incompréhension où une difficulté à suivre ce qui était demandé, mais uniquement pour ajouter de la fonctionalité et de faciliter l'extension de notre projet par des tiers. \end_layout \end_body \end_document