Update README.md

This commit is contained in:
Jean Sirmai 2021-03-28 14:23:21 +00:00
parent af55a1f053
commit 7224971850
1 changed files with 205 additions and 1 deletions

206
README.md
View File

@ -1,2 +1,206 @@
# gem-graph # gem-graph is for: GE-ometric directed M-ulti-GRAPH
A geometric graph is a graph whose nodes have coordinates in a space
A graph is directed if its bonds are arrows
It is a multigraph if several arrows can be stacked from one node to another one
Note that 'directed' does not means 'oriented': a graph is oriented if one of its nodes is its root
Geometric directed multigraphs have properties that make them suitable for the representation of complex phenomena,
especially those where numerous different objects and types of interactions are involved.
gem-graph is a software that enables modelling with a geometric directed multigraph.
today (28-03-2011) there are two main parts in this text:
> questions about the architecture: identification and naming of the main parts of this program
> and a more theoretical text : Rewritten Geometric Directed Multigraphs Properties. (JS dec 2017)
that could be a starting point for a publication
==============================================================================================================
il faut trouver des noms pour:
> la partie dont l'exécution est rythmée par le calcul du modèle ('engine' ?) qui comprend:
- > - le centre qui calcule le modèle (see below)
- > - les outils de détection et contrôle automatisables (supervisor ?)
(état chaotique, boucle infinie, répartition déséquilibrée entre threads de calcul,...)
> la partie dont l'exécution est rythmée par l'utilisateur ('interface' ?) qui comprend:
- l'initiation / la terminaison / l'interface OS
- les entrées / sorties / contrôles d'erreurs associés
- le déroulement du calcul et le contrôle temps réel
automaton > user (quel est l'état du modèle ? comment fonctionne l'automate ?)
user > automaton (stop, slow / speed, undo / redo, modify the nb of threads or the algorithm...)
- la gestion des vues (conformité à une view_type)
- les éditions
- des états
- des règles de transition
- des arbres de règles
- les mesures des états du modèle et de son histoire
- les aides (au moins une par vue) et leur édition
- les traductions, la gestion du vocabulaire
- des facilités (textes, vues, liens) vers :
- le contexte théorique, la bibliographie
- principes / justifications / limites du modèle
- licence, droits, auteurs, informations pratiques
- outils de présentation
---------------------------------------------------------------------------------------------------------------
le centre de calcul (engine) est un automate qui effectue des transitions locales sur un état global
les modifications successives de cet état global décrivent sa trajectoire dans son espace de phase
chaque transition locale est calculée indépendamment, en mode asynchrone, par un thread de calcul
tous les threads de calcul appliquent les mêmes règles selon le même algorithme
un processus principal (apportioner ? allocater ?) initie et termine ces threads
(scheduler ne convient pas car la répartition est spatiale)
il garantit la cohérence de l'état global et valide l'ensemble du calcul ou l'interrompt en cas d'erreur
il est seul à avoir accès à l'état global et à la liste des threads de calcul
il n'a pas accès aux règles de transition
il assure également (ou délègue) les fonctions de communications avec les modules périphériques
il exécute un cycle qui comporte deux étapes principales:
- recherche aléatoire d'un espace local
- si trouvé:
- arrêt de cette recherche
- préemption de cet espace local
- initiation d'un nouveau thread de calcul auquel est attibué cet espace local
- sinon arrêt de cette recherche en un temps fini
- recherche des threads de calcul en fin d'exécution
(ces threads se signalent dans une liste; leur temps de calcul est aléatoire)
- si trouvé(s):
- arrêt de cette recherche
- mise à jour de l'état global (insertion du ou des états locaux calculés)
- terminaison des threads de calcul concernés et libération des verrous associés
- sinon arrêt de cette recherche en un temps fini
- mesures / recueil des commandes / retour d'information
------------------------------------------------------------------------------------
chaque thread de calcul applique à un état local différent les mêmes règles de transition selon le même algorithme
il retourne un nouvel état local ou un message d'erreur
l'espace local est défini par un centre, une orientation et un rayon
(il peut être approché par un carré, un hexagone, un cube, ou toute autre forme le contenant)
le centre est une cellule contenant au moins une flèche (optimisation: elle pourrait ne pas en contenir)
l'algorithme de calcul de l'état local suit parallèlement un chemin partant du centre de l'espace local
et un chemin allant de la racine de l'arbre des règles vers l'une des feuilles et il compare, à chaque itération,
- le nombre de flèches présentes dans chaque site
- au nombre de flèches requis pour que la condition qui s'applique à ce site soit satisfaite
(un parcours séquentiel ou aléatoire des règles est possible mais donnerait des résultats différents)
ce chemin parcourt l'ensemble de tous les sites de toutes les cellules de l'espace local dans un ordre prédéfini
ce parcours est optimisé de façon à maximiser la probabilité d'intersection entre:
- les sites occupés dans l'état local
- les sites définis par les règles de transition
pour pouvoir effectuer ce parcours, il faut que les coordonnées (locales) des conditions et des actions des règles
soient préalablement superposées aux coordonnées globales (calculées d'après l'origine et l'orientation) de l'espace local
le parcours s'interrompt dès qu'une condition est fausse: ceci veut dire qu'aucune règle ne décrit cet espace local (to do)
sinon, il se termine lorque toutes les conditions d'une règle ont été satisfaites:
la région de l'espace global auquel cet espace local est superposé peut être modifié selon les indications de cette règle
----------------------------------------------------------------------------
le nombre de calculs pouvant être effectués en parallèle dépend donc:
- du rapport entre l'étendue de l'espace local et celui de l'espace global
- du temps de parcours moyen des règles
(si l'on néglige les opérations d'initiation et de terminaison des threads de calcul
et les opérations de communication de la boucle principale avec son environnement)
----------------------------------------------------------------------------
le processus principal (apportioner) peut donc être un serveur pour les threads de calcul
il doit également intercepter les demandes des utilisateurs et les déléguer a des threads ou processus dédiés
===============================================================
Rewritten Geometric Directed Multigraphs Properties. (dec 2017)
Space, objects.
Is a discrete space, whose cells have sites (syn: vessels, quivers, slots, locations, space holders) directed towards the neighboring cells. These sites may contain zero, one or several arrows that can be stacked and directed towards the same neighboring cell. Any distribution of arrows in the sites is a directed multigraph. It defines a state of the space.
The cell is the smallest unit of space. All cells are similar. All have the same number of sites. Each cell can have at most as many sites as there are other cells in space. The cells have no site directed towards themselves.
Each cell designated by an arrow can itself contain zero, one or several arrows.
An object is an isolated connex part of this graph. Each state space, unless the space is empty or saturated, describes at least one object. According to the number of dimensions of the space, objects of any shape can be drawn: monomers, polymers, strings, knots, surfaces, volumes, cavities, fluids, basic machines, etc ... They can be combined in the same space to describe situations.
Transition rules
A transition rule associates several elementary rules in any order. Each elementary rule associates a condition and an assignment. Both concern the same site in the same cell.
A condition associates the coordinates of a site in a cell to a number (c). If the number of arrows in this site is equal to (c), then the condition is satisfied. Else, it is not.
An assignment associates the coordinates of a site in a cell to a number (a). If the assignment is performed, then the number of arrows that contains this site becomes equal to (a).
An elementary rule can alter or not the state of space. A transition rule must have at least an elementary rule and must not involve more than one of them on the same site.
Each transition rule defines two states of the space: one initial and one final. It completely defines them if it combines as many elementary rules as there are sites in the space. Else, it defines them partially or locally.
Conversely, for any pair formed of any two states of the space there is always one rule and only one which describes the transition from the first one to the other.
Rewriting the graph allows to associate to each object or group of objects any motion, deformation, transport or transformation that gives it a variety of properties: strength, flexibility, elasticity, permeability, fluidity, viscosity, etc ... Directed arrows towards empty cells can be used to generate random connections that can mimick structural defects or mutations. Any objects interactions can be described.
Transition rules' properties
For any state, there is a single neutral transition rule that does not alter that state.
Any transition rule has a single inverse rule that produces its initial state from its final state.
Given two rules (a) and (b) with the final state of (a) equal to the initial state of (b), there exists a single rule (c) (said 'composed') from the initial state of (a) to the final state of (b). If this rule (c) is part of the automaton, passing through the state between (a) and (b) is optional. It is necessary otherwise. In this case, the rule (a) will always be executed before the rule (b). Therefore, the property modelized by the rule (a) can be interpreted as a cause of the property modelized by the rule (b).
Given three rules (a), (b) and (c) with the final state of (a) equal to the initial state of (b) and the final state of (b) equal to the initial state of (c) there is a single transition rule from the initial state of (a) to the final state (c). This rule can be produced by the successive compositions of (a * b) * c as well as of a * (b * c). (associativity)
The area of a rule consists in all the cells containing a site on which there is a condition provided that no cell will be amended by an assignment without first being tested by at least one condition.
Automaton
A spatial automaton is a set of transition rules associated with an initial state of space.
All the static information is in the space. All the dynamic information is in the rules. The automaton uses no other information. It must contain at least one transition rule and should not associate two identical ones.
The transitions are local and asynchronous. They may be performed in parallel if their areas do not overlap. They are Markov processes.
During a transition, all the transition rules are evaluated. If several can apply, one of them is selected at random or according any other algorithm.
Transitions tree
All transition rules of the same automaton can be grouped into a single tree: the transitions tree. This tree can be created automatically from a list of the rules. Each rule is written in the tree as a path from the root to a leaf. This path lists all the conditions that must be met for this transition rule to be applied. In each path, the conditions order is the same. It refers to an order previously defined on the set of all the sites of all the cells where an elementary rule can apply. This order is the same for all rules.
At each node, each transition rule follows the branch whose number equals the number of arrows that met its condition for that site. Two rules follow the same path starting from the root as long as they share the same conditions. When they differ on one condition, they then follow two different branches. To each site on which a rule has a condition corresponds at least one node. Each node may have as many branches as there may be arrows in a site (including zero) plus one. This branch, known as neutral, is followed by the rules that have no conditions on this site but still have some conditions further.
Performances
Speed depend on the average depth of the transitions tree and on number of neutral branches. If all the possible situations are each described by a rule, there are no neutral branches and the performance is proportional to the average depth of the transitions tree. The maximal depth of the tree cannot exceed the number of sites the the local space contains.
If some possible situations are not described by a rule, there are neutral branches. Then, exploring the local space may not lead to any change. The more neutral branches, the longer the exploration of the tree. This is because the nodes that have a neutral branch may need to be explored several times, if the exploration of their non-neutral branches fails.
Speed depends lesser on the size of the area covered by the set of transition rules. This size mainy limits the number of possible parallel processes in the space.
Granularity is not set once for all. It is possible to simultaneously manage both near and distant objects or parts of objects by combining arrows of short and long range. These allow to detail local areas of interest within a situation grossly described and to associate various levels of granularity within an approximation of a continuous space.
Using arrows, it is also possible to write in the space specific tags that can be associated to any objects or situations. This technique allows to keep a clear separation between static and dynamic information. This separation is the condition of an unique rules design which allows, in turn, their automatic rewriting.
Addition of automata
Several automata can be added under the condition that their spaces share the same dimension and the same paving. Objects coming from different models can then be drawn in the same space to build a new initial state. All the rules, as they use the same formalism, can be grouped in the same tree.
During the addition process, redundancies or conflicts can appear. Redundancies occur when two rules coming from different models do identical operations on identical situations, Only one instance of them should be kept. Conflicts appear when a rule of one model does an unwanted operation on some objects or situations of another model. This can be due to an inadequate description by the rules. Two kind of solutions are then possible and non exclusive: modify the objects shapes and / or add some new conditions to some rules in order to restrain their domain of application. If the model representations are correct, then the conflicts reveals a contradiction between the models themselves: an operation performed by one model is unwanted in the other. Conflicts can also appear when an unique object is associated to several different tags (tags can be used as keys)
Prospects
- Automatic production (by IA) of sets of transition rules from the graphic definition of initials and finals states.
- Graphic help for the edition of individual rules from schematic drawings of situations.
- Addition of objects and rules from multiple independent models.
This property could allow to integrate models designed or developed by different teams working in parallel on separate mechanisms involving the same objects.
Meta-rules could help to detect uncomplete or incompatible rules.
- The random production of rules may have an interest in learning models or evolution. Meta-rules can be used to eliminate poorly constructed rules before execution.
- Approximations of conservation laws.
-----------------------------------------------------------------------------------------------------------
Locos, formas modumque coherentiae omium rerum status depingit. Nihil aliud comprehendet.
Eas res praecepta movet aut transformat. Nihil aliud facit. Quaedam tranformationes in sua potestate sunt.
Aliae transformationes alii succedere debent.
Interpositus status inter illas et istas jacet.
Ab antecedente statu primarum ad sequentem statum secundarum iter nullius est nisi per suorum interpositum statum.