gem-graph/gem-graph-client
gem-graph
/
gem-graph-client
3
0
Fork 0
Code Issues 14 Pull Requests Projects Releases Activity
gem-graph-client/contributing.md

6.5 KiB
Raw Blame History

Gem-graph Client

A gem-graph client can be used to:

  • create or edit a gem-graph model
  • control a run of a gem-graph model by a gem-graph server
  • get and study the results of such a run

In order to execute these functions, it must be able to manage:

inputs / outputs

- load and save models
- use xml schemas to check the validity of models 
- connect to an instance of gem-graph server
- dialog with this instance

a GUI able to:

- render and edit the model
    - states
    - objects types
    - tags and references
    - transitions (edition 'de novo' or starting from a state copy)
    - transitions trees
    - users trees

- control a run using commands: 
    - run / stop
    - speed up / slow down
    - do / undo / redo
    - predefine run duration, sampling frequency and nature
    - predefine interruption parameters 
            (according to server performances and/or model results)
    - preselect the search algorithm in the conditions tree 

- monitor performances of the server
    
- view and analyse the results of a run
    - history
    - phase diagrams (structures / fluxes)
    - statistics
    - errors
    
- facilitate usage of the software
    - preferences
    - context info
    - help

Definitions (see also: gem graph README and gem graph server README)

  1. XML Schema

  • According to the model xml schema, a gem-graph model must include at least the following data groups:

    • identity (name, owner, creation date, version, references,...)
    • parameters (about simulation and space: dimension, size x y z,...)
    • objects: each object is a connex graph drawn as a set of arrows
    • savestates: each state (objects, situations, tags) is drawn as a set of arrows
    • transitions: each transition is defined as two sets of arrows
    • conditions: that are specified as nodes in a tree (see below)
  1. Automaton rewriting a geometric graph

  • A gem-graph is a geometric graph = a graph whose nodes have coordinates in a space.

  • A gem-graph model describes an automaton that can rewrite a gem-graph.

  • An automaton that can rewrite a gem-graph has to define states and transitions.

  • States belong to a unique global space in which all the transitions occur.

  • Each transition rewrites a part of the global space. This part is called the local space.

  • States are drawn in spaces (global or local) using arrows.

  • States can be combinations of objects, situations and/or tags.

  • Objects and tags are connex graphs (i.e. graphs whose nodes are all connected).

  • A situation describes the relative positions of several objects in the global space.

  • A tag is a part of an object or situation which encodes a human readable text (annotation, ref, value,...).

  • Several connex graphs can be used to describe the same object.

  • An instance of the class object groups all these graphs plus some comments or values.

  • Transitions are defined by an initial and a final local states.

  • The initial state of a transition can be evaluated by a set of conditions.

  • Each condition is defined as the association of:

    • a location (space unit (x, y, z) and site number)
    • an arrow number (or weight) as several arrows can be stacked at the same location

  • All the conditions can be ordered in a single tree: the 'tree of conditions' (see below).

  • In the XML model file, in order to write and read this tree, each condition has a node identifier (node_id) and a parent.

  1. Data structures

  • Arrows are represented (encoded) by numbers in sites.

  • In each space units is a finite number of sites.

  • The site 0 always points towards its own space unit.

  • Each other site points towards a neighbouring (not necessarily adjacent) state unit.

  • Each site of each space unit can 'contain' 0 or n arrows.

  • The set of states of all the sites of all the space units defines a space state.

  • A condition is satisfied if both following quantities are equal:

    • the number of arrows (or weights) specified by the condition
    • the number of arrows present in the space at the same location specified by the condition.

  • When conditions are evaluated by the automaton, these two values are compared.

  • These evaluations are done by threads (workers) managed by the scheduler of the server.

  • A transition rule associates several conditions to several assignments.

  • An assignment instruction assigns a number (n) of arrows to a site of a space unit of the global space.

  • The conditions of a transition rule must all be satisfied for this rule to be applied.

  • Several transition rules can have conditions that read the same site.

  • As all the transition rules share at least one common conditions on the local space origin, all the conditions of all the transition rules can be ordered as a single conditions tree.

  • In this conditions tree, each condition is a node and each set of assignments is a leave.

  • The root of this tree is the condition on the local space origin.

  • The other conditions are met by following a predefined path through all the locations of the local space.

  • This path is determined by the user according to the design and performances of the model.

  • In the XML model file, in order to write and read the conditions tree, each condition has a node identifier and a parent.

  1. Algorithms

  • The search of a transition rule in the conditions tree is done by the threads of the scheduler (see gem-graph-server README)

  • The result of these searches can be:

    • success (the founded rule is applied)
    • failure (there is no rule for this situation; the local situation is returned to the client)
    • error

  • The rules and the conditions tree are designed by the client and executed by the server scheduler threads. It is the responsability of the user to manage:

    • conditions deficit, conflicts and redundancy
    • rules deficit, conflicts and redundancy
    • optimisation of the conditions tree by design of an adequate path through all the locations of the local space
    • approximations of objects, situations and phenomena
  1. Meta-edition (future)

  • As mentionned above, several connex graphs can be used to describe the same object.

  • An instance of the class object, called a meta-object, then groups all these graphs plus some comments or values.

  • In future versions, the client should provide tools in order to help model designers to edit

    • objects from meta-objects. (vectorisation)
    • transitions from meta-transitions. (AI ?)

NB Adequate data structures should describe these meta-transitions and meta-objets.