Copyright © 2024 Jean 'jean' Sirmai

     Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.3 or any later version published by the Free Software Foundation; with no Invariant Sections, with no Front-Cover Texts, and with no Back-Cover Texts.  A copy of the license is included in the section entitled ``GNU Free Documentation License''.

Introduction
************

Welcome to Gem-graph!

Gem-graph lets you move and transform drawn objects using an automaton. It's an ideal tool for describing the evolution of a situation through drawing. By providing you with automatic transformation tools, it allows you to conceive and apply the rules that create new drawings from the previous ones. Your design is no longer frozen: you can also decide how you want it to evolve! You can use gem-graph to make a game. You can use it to tell a story. You can use it to make a model of a phenomenon that interests you. You can represent any scene simply or in more realistic detail. Simple parts and more detailed parts can coexist in the same design. You can do it in two or three dimensions. You can watch what you've created evolve without intervening, or guide it by modifying your initial rules towards what you want to achieve. You can even mix several drawings and animations. You can observe them in detail, modify them, go back, start again, measure, compare and keep the sequences and other results that interest you so that you can play them again.

However, a certain amount of effort will be required to achieve this. A complicated model will require more work than a simpler one, but it is possible to start with something quite simple and develop it step by step. In any case, you must draw what you want to see and say how you want it to be transformed. Gem-graph cannot do that for you. However, it does have powerful tools to help you. Gem-graph - short for 'geometric graph' - is a redrawing system. Its strength lies in the fact that it deals only with very simple drawing elements, all of which are similar. All the static information - your initial drawing - is an arrangement of these elements in the space. All the dynamic information - your redrawing rules - transform what you draw as you wish. All the gem-graph rules, whatever their complexity, are only associations of an unique simple pattern: one condition on one element of the drawing triggers one action on the same element. Due to this very simple structure, any set of complex rules, no matter how many there are, can always be processed automatically by the gem-graph automaton. The tools provided by gem-graph give you access to this power to create and animate your drawings, and this manual is here to help you learn how to master them.

intro_hello_world Reproducing very simple examples, such as when a programming language asks you to write "Hello world", is one way of learning. For gem-graph, the equivalent of "Hello world" will be to move a small line on your screen. This example and other simple ones that follows will progressively give you an approach of what gem-graph can do and enable you to build and animate much more complex drawings that suit your desires. node_gem_graph_by_example, Gem-graph by example, Hello world, Gem-graph by example if you like learning this way. If you prefer to learn by reading what the commands you see on the screen are doing, they have been detailed here (_learn_commands). The table of contents is another way to learn. It goes from the simplest to the most complicated. How to set up a simple model (_simple_model), observe it (_simple_observation), measure what it does (_simple_measurements) and display the results (_simple_results), then transform it by changing what you see (_simple_state_edition) and how it reacts (_simple_rule_edition). You can directly deal in with the details of gem-graph mechanism itself (_gem_graph_mechanism). You may also whish to compare gem-graph to other classes of automata that do quite similar things (_spatial_automata_classification), and examine what it can and cannot actually do and what its scope of application is (_gem_graph_theory).

Gem-graph by example
********************

Hello world
===========

hello_world Our "Hello world" is the simplest program that gem-graph can execute. It consists of a single short arrow, which moves in a straight line in a single direction. To do this, we first had to draw this little arrow and then make it move. The result is certainly not very exciting, but this example is enough to show how a gem-graph drawing is made and how it is animated. One rule and one state are enough. The rule only says: if an arrow is drawn here, I erase it and redraw it on the next square. For the moment, you can ignore how the automaton works (the details are in _gem_graph_mechanism). The model is assumed to evolve in a small flat space which is described here (_hello_world_space). All that gem-graph needs to know to execute such models is written in the "Hello world" file (_hello_world_file). Note that all the gem_graph models will have basically the same structure, making them easy to copy and share. How to execute this example is explained here (_hello_world_exec). To go back to the Introduction: intro_hello_world, Back to Gem-graph Introduction, Reproducing simple examples

Random walk
===========

random_walk From this first model, it is possible to give the arrow the possibility of moving in two directions: forwards or backwards, and to ensure that these movements occur randomly. This second model therefore describes a "random walk". To do this, we need to add a second rule which only says: if an arrow is drawn here, I erase it and redraw it on the previous square. A random draw is now necessary to determine whether the first or second rule applies. With these two rules and the random draw, the arrow now sometimes advances and sometimes retreats at random. The detailed description is here: (_random_walk).

Multiple random walks
=====================

multiple_random_walks The next example shows how these two rules can be applied to a several states. To test this, we start by populating the space by randomly distributing in it a large number of arrows all with the same orientation. We now need to adapt our rules by checking that the square where an arrow can go is free. If not, the arrow will not be moved. Once the rules have been modified in this way, they can be applied to any arrow in the space. When you set the model in motion, you will see all these small lines moving at random towards left or right (_horizontal_random_walks). This shows that the gem-graph automaton is constantly exploring the whole space to see where the rules you have designed can be applied.
By adapting this example, it's easy to create another model where the arrows are vertical and move randomly from bottom to top or top to bottom (_vertical_random_walks).

Pendulum
========

pendulum In the previous random walk models all the states were similar (one arrow) even if there were many of them and there were only two rules (forward/backward). Now here's a model with two states and two rules: the "pendulum" (_pendulum). This time, the arrow can be drawn either tilted forwards or tilted backwards and the two rules switch the drawn arrow from one state to the other or vice versa. The pendulum does not change places. It only moves from left to right and vice versa. You can slow down the programme to observe the movements better (_gem_graph_commands). It could be a good starting point to draw a complete clock or a solar system.

Random walks plus pendulum
==========================

random_walks_plus_pendulum An amazing feature of gem-graph is that it is possible to add the three previous models and make them work together (_random_walks_plus_pendulum). Their addition is immediate because these three models are independent. If they were not, i.e. if a rule in one applied to a state in another, you would have to change it or slightly modify one of the states. Gem-graph can't do this for you, but it can detect such situations and provide you with tools that automate or at least facilitate the merging operation (_gem_graph_addition).

Once the addition automatically operated, we see little lines moving simultaneously and at random from left to right or vice versa if they are horizontal, and from top to bottom or vice versa if they are vertical. Their number is constant. They don't change shape or direction. There seems to be no accident when they cross. The pendulum is here also, who continues to come and go, oblivious to all the commotion. Nothing else happens (_random_walks_plus_pendulum). Although the system is constantly changing, something always seems to remain the same (_ergodicity, _gem_graph_theory). Note that we could have drawn several clocks, but without guaranteeing their synchronisation as long as they remained independent. This is because the automaton randomly selects the targets to which it applies the rules. (more on this here: _pendulums_synchronisation, _gem_graph_theory).

This resulting model, because it shows a multitude of diverse and simultaneous movements, perhaps gives the impression of a more complex system. It would be easy to make it even more complex, by trying to represent, for example, the traffic of a city in all its diversity, a video game or the metabolism of a cell, but the value of the gem-graph is the way in which it can be used to analyse and control this complexity. At this point, it's time to take a look at the mechanism (_gem_graph_mechanism) and theory (_gem_graph_theory) of gem-graph and compare gem-graph to other classes of automata that do quite similar things to better understand how the profound simplicity of its automaton allows it to embrace such a wide range of situations and behaviours simultaneously but also what it can and cannot do easily and what its scope is (_spatial_automata_classification).

Gem-graph Commands
******************

commands Gem-graph opens with an overview that lets you see at a glance the current state of your model, the rules at your disposal and some measurement results if you have selected any.

Your first desire may be to see how the model behaves in motion. A panel contains all the commands you need to do this: run/stop, slow down/speed up, step by step, do/undo/redo.

Another group of controls lets you rotate your model, zoom in, etc. to view it from the best angle. These controls are grouped together in a 'camera' panel.

Gem-graph opens in "run" mode. The only other mode available is "edit" mode. These two modes are incompatible: you can either run the model or edit it, but not both at the same time. The command for switching from one state to the other is at the top left of the title bar.

Other more specific commands are possible, but they can only appear if you have first defined the objects or situations that are of particular interest to you in your model. You can then colour them in or change their relative transparency so that you can see them clearly.

From the overview panel, you can move to the state, rules, measurements or results panels. Only one of these panels/screens is visible at a time. The buttons that allow you to move from one to the other are in the left-hand title bar, just next to the exec/edit button, which is furthest to the left.

Rules panel
===========

rules_panel The rules panel is in fact a combination of two panels: one devoted to the rules tree, the other to a rule you may have selected to study or modify. As it is often useful to switch from one view to the other, it's nice to have one next to the other and to be able to enlarge either one easily.

Open / Close / Save
===================

Open/Close/Save Open / Close / Save

Help
====

help Help

Simple models
*************

simple_model The aim of this chapter is to make it easier to learn gem-graph by working in more detail on very simple models.

It is very easy to complicate a model. Sometimes all you need to do is add an object or a rule and the complexity increases exponentially.

Gem-graph Mechanism
*******************

mechanism

Randomization
*************

randomization

Gem-graph Theory
****************

theory To calculate, you first have to represent. In an equation, the letters represent the objects. The other symbols are the operators. In gem-graph, the objects - or rather the situations - are drawn. The operators are the rules that modify these drawings.

Models addition
===============

models_addition Trois conditions doivent être réunies pour pouvoir additionner des modèles :
- Ils doivent être dessinés dans des espaces de même dimension. Il serait possible de copier des objets 2D dans un espace 3D mais l'inverse supposerait une opération et le plus souvent une perte d'information. Dans tous les cas, les règles devraient être réécrites. * Une unité d'espace d'un modèle (un 'grain') peut représenter des objets de taille très différente. Pour pouvoir additionner deux modèles, il faut que les objets décrits soient de même taille dans les deux modèles. Deux familles de solutions sont possibles : * modifier la taille des objets de l'un des modèle ou des deux, au prix éventuel d'une perte de définition du modèle résultant. * encourager la production de modèles compatibles dès leur conception lorsqu'une 'unité naturelle' (ex: atome, individu,...) peut servir d'unité de représentation et pourrait faire l'objet d'un consensus. Les outils d'addition des modèles seraient améliorés par la définition préalable de ces standards. - Ils doivent être indépendants. Les modèles indépendants peuvent être additionnés automatiquement. models_independence Def indépendance: No rule in one is applied to a state in another. Le client gem-graph devrait fournir des outils (analyse et possibilités d'action) facilitant l'addition de modèles interdépendants (merge).

Tags
====

tags (cf. https://forge.a-lec.org/gem-graph/Gem-graph/issues/17)
Un graphe géométrique peut être interprété comme un objet (graphe connexe), une situation (objets proches les uns des autres) ou un 'tag' (ou balise). Un tag est un objet (graphe connexe) particulier qui a l'apparence d'une chaine de caractères (lisibles par un humain ou non) et qui peut être le support d'une information de nature différente d'un dessin. Un nombre non prédéfini de tags peut être associé à un dessin d'un objet ou d'une situation. le concepteur d'un modèle peut souhaiter ajouter des informations d'intérêt à un dessin (valeur, référence, lien, identifiant, addresse, annotation, commentaire, date, auteur,...). Il est essentiel que ces informations soient écrites dans l'état et non dans les transitions car le maintien de l'homogéneité du format d'écriture des transitions garantit qu'elles peuvent être traitées automatiquement. Le client gem-graph devrait fournir des outils facilitant l'édition de tags. Définir des normes faciliterait leur édition.

Models coupling
===============

Models coupling to flows
------------------------

models_coupling_to_flows (cf. https://forge.a-lec.org/gem-graph/Gem-graph/issues/19)
Certains phénomènes participant à des phénomènes complexes sont décrits de façon optimale par des équations continues représentant des flux. Ces modèles utilisent des gradients de variables intensives (ex: pression, température, densité,...) pour décrire les états et calculer leurs évolutions. Chaque modèle gem-graph devrait pouvoir être couplé à de tels modèles. L'idée d'un couplage entre modèles de nature différente a déjà été proposée (ref 1). Ce couplage suppose remplies au moins toutes les conditions suivantes:
-   superposition des espaces et des temps des deux modèles
-   lecture des valeurs d'une variable d'intérêt du modèle continu par le modèle gem-graph au moyen d'une condition spécifique
-   écriture dans le modèle continu des modifications effectuées par le modèle gem-graph au moyen d'une action ('assignment') spécifique.
A cette date (nov 2024), cette technique n'a jamais été testée.

References Smith, A., P. Turney, et al. (2002). JohnnyVon: self-replicating automata in continuous two-dimensional space. NRC Publications Archive. Wishart, D. S., R. Yang, et al. (2005). Dynamic cellular automata: an alternative approach to cellular simulation. In Silico Biol 5(2): 139-161.

Models coupling to waves
------------------------

models_coupling_to_waves (cf. https://forge.a-lec.org/gem-graph/Gem-graph/issues/18)
Certains phénomènes participant à des phénomènes complexes sont décrits de façon optimale par des équations continues représentant des ondes.

Chaque modèle gem-graph devrait pouvoir être couplé à de tels modèles.

Ce couplage suppose remplies toutes les conditions suivantes:

superposition des espaces et des temps des deux modèles lecture des valeurs d'une variable d'intérêt du modèle décrivant les ondes par le modèle gem-graph au moyen de conditions spécifiques prenant en compte l'orientation, la section efficace, l'énergie, la phase,... écriture dans le modèle continu des modifications effectuées par le modèle gem-graph au moyen d'une action ('assignment') spécifique A cette date (nov 2024), cette technique n'a jamais été testée.

Spatial automata classification
===============================

spatial_automata_classification Spatial automata classification. Scope definition...

History
=======

history (cf. https://forge.a-lec.org/gem-graph/Gem-graph/issues/11)
La conception d'une modélisation par réécritures de graphes géométriques s'est faite par étapes. L'élaboration de gem-graph a été un processus incessant qui ne peut être considéré comme achevé. L'étude de cette évolution pourrait aider à la conception des développements à venir et -peut-être ! - économiser des réécritures.

De 1992 à 2020, chaque étape du développement a entraîné la réorganisation partielle ou complète du logiciel (structures de données, nommage et algorithmes) (ref) en réponse à des contextes historiques particuliers:

1974 Le concept d'autopoièse (Francisco Varela & Humberto Maturana) (ref) Redéfinition de l'autopoièse : persistance + liaison entre constituant d'un même individu Isoperformance (relation complexité / efficience de tous les composants d'un individu) Christopher Langton: 'Life as it is' versus 'Life as it could be' Le 'jeu de la vie' John Horton Conway en 1970 :un système formel Turing-complet Le paradigme des automates cellulaires (ref) Les modèles orientés-objets insuffisants face aux phénomènes complexes (ref) 1994 Premier poster à Heidelberg. Critiques: 'pas réaliste'. Quelle granularité et quelle définition choisir ? Conclusion : les structures représentées doivent déterminer les fonctions. Rien de plus. Toute l'information nécessaire à la reconnaissance de la fonction doit se trouver dans l'état. 1995 premier génome complet (Haemophilus influenzae 400 gènes seulement mais parasite) (ref) la connaissance de l'intégralité des génomes ouvre l'ère de l'exhaustivité: Le nombre de parties d'un être vivant est fini. Toutes sont ou peuvent être connues et totalement décrites (atome par atome) Comment reconstituer le tout à partir des parties ? La recherche d'une théorie biologique et le développement des modèles (Artificial Life) Peut-on définir la vie ? Comment ? Le débat naturalisme / vitalisme. L'exobiologie Les modèles 'set of keys' and 'bag of chemicals'. Conséquences sur le "milieu intérieur". Un arbre logique du vivant distinct du graphe historique. Postulat: la représentation optimale des connaissances biologiques nomologiques (non-historiques) ? Postulat: l'auto-production condition nécessaire de l'auto-re-production. Une proposition de démonstration : si une structure était dédiée à la reproduction mais non auto-productrice d'elle-même, c'est une *autre* structure qui devrait la reproduire. Ceci conduirait à une récurrence infinie donc impossible. Une chimie des symboles : Gem-graph peut convertir des états en règles de transition et des règles de transition en états.

Principales innovations successives:

Transitions locales (pas globales) (à la différence des automates cellulaires) Initialement, tous les objets de l'espace global étaient des symboles (des caractères 'M' ou 'E', par exemple) identifiés chacun individuellement par le programme qui opérait leurs déplacements ou transformations. Puis ils sont devenus des dessins mais, même s'ils avaient la même forme, ils restaient identifiés par un code non inscrit dans l'espace. Désormais, leur identité est inscrite dans l'espace même, localement, et pas dans la règle. Leur forme doit être reconnue reconnue par la règle (pattern recognition) pour qu'ils puissent être manipulés. Des objets complexes: chaque case de l'espace est munie de liens pour s'accrocher à d'autres Les objets peuvent être complexes: composés de combinaisons de plus d'une case (à la différence des automates cellulaires) Ceci permet à la forme des objets d'indiquer leur fonction. Ceci permet aussi de transformer, trasporter et combiner les objets du modèle facilement. Les processus combinatoires (polymérisations) sont indispensables en biologie Gem-graph ne peut pas représenter (la conservation de) l'énergie, mais on peut convenir qu'à des formes d'objets identiques sont associées des énergies potentielles identiques (énergie potentielle = énergie que l'objet peut libérer ou stocker en étant transformé) Mouvement aléatoire de tous les objets = modèle d'une solution (sans le solvant) Un seul format de règles pour décrire des mouvements et / ou des transformations Qu'importent les structures, pourvu qu'elles représentent des fonctions ! Les conditions ne reconnaissent plus que des formes dessinées et deviennent uniformes. Séparation systématique des états et des règles de transition Séparation des conditions et des actions des règles sous des formats standards Espace plan enroulé sur un tore; matrice hexagonale Plusieurs sites par 'particule'. Plusieurs flèches superposées. Conditions d'une règle connectées par des 'ET' Règles connectées par des 'OU' Deux types de conditions: sur une cellule, sur une flèche Deux types d'actions: translation, rotation Condition de probabilité Addition de modèles compatibles Association possible de modèles gem-graph à de modèles décrivant des flux et/ou des ondes Un seul type de règle élémentaire (1 condition et 1 action, 1 seul symbole) Commutativité Un même moteur pour 1D, 2D et 3D Les modèles et les préférences des utilisateurs sont stockés sous format XML Des règles locales, aléatoires et asynchrones respectent les relations de causalité Parallélisme (premiers tests) Arbre des conditions Séparation des projets gem-graph (nommé fin 2020) et des projets biologiques (aXoris, nommé vers 1995) gem-graph est adapté à la représentation de tous les phénomènes complexes

Fin 2020, Adrien 'neox' Bourmault a eu connaissance de ce travail et s'y est intéressé. Son analyse et ses recommandations ont impulsés une réécriture complète du code mais surtout une profonde réorganisation des méthodes. Ce qui était jusque là une recherche artisanale a pu s'orienter, grâce à son expérience et à sa rigueur, vers un travail d'équipe avec l'objectif d'atteindre une qualité suffisante pour attirer de nouveaux développeurs (et la labellisation GNU Project ?). Cette première version témoigne à tous les niveaux de son implication. Ses principaux apports ont été théoriques (choix d'une architecture modulaire client-serveur, conception 'système' et non plus seulement objet, méthodologie de développement, planification) et pratiques (choix d'une palette d'outils libres, actualisés et de qualité garantissant la cohérence de l'ensemble du développement: Guix, langage C, git, langage C, Libxml, Makefile, GTK4, OpenGL, Doxygen, Texinfo, LaTeX).

Les principales étapes de cette réorganisation on été: En 2021, Architecture modulaire client-serveur Redéfinition du fichier XML avec notation des règles sous forme d'arbre de conditions. GIT Début 2023 langage C, LibXML, OpenGL, Automne 2024 Doxygen, Texinfo

Cette réorganisation a mis en évidence :

Le sous-ensemble des flèche-origine (éligibles comme origine de l'espace local); Les autres modes d'écriture possible des flèches (départ-arrivée, départ + module + angle); Le parcours de l'espace local (espace de travail) encodé par l'ordre des conditions dans l'arbre => abandon des parcours séquentiels de listes de règles => plusieurs parcours possibles (auparavant : le seul parcours spirale) => optimisation souhaitable (par le client) du parcours pour chaque modèle (dans tous les cas, la fabrication de l'arbre que le serveur utilisera incombe au client) Le cycle de vie du modèle : correction des erreurs reproductibles puis aléatoires; Les outils nécessaires pour ces deux phases de la conception du modèle; Fixation (en cours) du vocabulaire / création d'un glossaire.

Réferences: (_bibliogaphie, _méthodologie)

Sirmai, J. (2011). A Schematic Representation of Autopoiesis Using a New Kind of Discrete Spatial Automaton. Advances in Artificial Life, ECAL 2011, MIT Press.

Sirmai, J. (2012). Autopoiesis Facilitates Self-Reproduction. Advances in Artificial Life, ECAL 2012, MIT Press.

Remerciements

Sébastien Boisard que j'ai rencontré début 1994 a contribué à ce projet en construisant, en C, un premier parseur des règles (efficace). Il pensait en avoir "pour quelques jours" (sic). Il a entrepris ce travail à l'automne 1996 et l'a achevé en février 1998. Puis il est parti 'monter sa boite' et est devenu ingénieur au CNRS.

Notre collaboration a été un bonheur et je le remercie profondément pour tout ce qu'il m'a appris.

Ce parseur a permis de manipuler jusqu'à 500 règles et a été un indice qui nous a guidé vers de nouveaux développements possibles. Il a notamment mis en évidence le fait qu'il fallait pouvoir manipuler automatiquement de très grands nombres de règles et donc que la structure des règles devait toujours permettre leur lecture et leur écriture par des algorithmes. Au début de son travail, ni la forme des règles, ni celle des états, ni les méthodes de modélisation, ni même le but des modèles, n'étaient clairement définis. Le choix du langage oscillait entre Pascal, C et Java. L'auto-production (mais pas l'auto-re-production) avait été (imparfaitement) représentée dès 1993. Les règles étaient lues séquentiellement. Leur grammaire s'est stabilisée une première fois grâce à ce parseur fin 1995. Plusieurs parseur Java ont été construits par le suite.

Gem-graph as a medium for artistic expression
=============================================

medium_for_artistic_expression (cf. https://forge.a-lec.org/gem-graph/Gem-graph/issues/10)
La réécriture de graphes géométriques est aussi une expression artistique. Les créateurs sauront s'en saisir pour associer librement formes, mouvements, couleurs et sons. Gem-graph est une aventure ouverte ! Il n'y aura jamais trop de poésie dans ce monde !...

L'auteur de ces lignes a dégagé les principes de gem-graph et réalisé ses premiers prototypes de 1992 à 2020. Il s'est autorisé à rêver et à publier ses rêves, sans avoir réalisé que la réalisation de chacun d'eux coûterait des années d'effort. Puissent-ils cependant encourager l'expression et la liberté de chacun ! Il espère que ses erreurs seront fécondes et qu'aussi longtemps qu'il sera porté par l'enthousiasme, l'audace et la patience, le projet gem-graph éclairera ceux qui lui font confiance.