Summer School „Modelling and Simulation with
GroIMP“ / Tutorial for beginners
University of Göttingen (Germany), 27-28 September, 2010
Winfried Kurth
Some basic examples in XL (part 4)
related material: XL code files sm09_e??.rgg
URL http://www.uni-forst.gwdg.de/~wkurth/
and drive T:\rgg on CIP pool stations
Representation of graphs in XL
● node types must be declared with „module“
● nodes can be all Java objects.
In user-made module declarations, methods (functions) and
additional variables can be introduced, like in Java
● notation for nodes in a graph:
Node_type, optionally preceded by: label:
Examples: A, Meristem(t), b:Bud
● notation for edges in a graph:
-edgetype->, <-edgetype● special edge types:
successor edge:
-successor->, > or
branch edge: -branch->, +> or [
refinement edge: />
(blank)
Notations for special edge types
>
successor edge forward
<
successor edge backward
---
successor edge forward or backward
+>
branch edge forward
<+
branch edge backward
-+-
branch edge forward or backward
/>
refinement edge forward
</
refinement edge backward
-->
arbitrary edge forward
<--
arbitrary edge backward
--
arbitrary edge forward or backward
(cf. Kniemeyer 2008, p. 150 and 403)
user-defined edge types
const int xxx = EDGE_0;
// oder EDGE_1, ..., EDGE_14
...
usage in the graph: -xxx->, <-xxx-, -xxx-
Notation of graphs in XL
example:
is represented in programme code as
(the representation is not unique!)
( >: successor edge, +: branch edge)
derived relations
relation between nodes connected by several edges (one
after the other) of the same type:
„transitive hull“ of the original relation (edge)
Notation for the transitive hull in XL:
(-edgetype->)+
reflexive-transitive hull („node stands in relation to itself“
also permitted):
(-edgetype->)*
e.g., for the successor relation: (>)*
common transitive hull of the special relations
„successor“ and „branch“, in reverse direction:
-ancestor->
interpretation: this relation is valid to all „preceding nodes“
in a tree along the path to the root.
nearest successors of a certain node type:
-minDescendants-> (nodes of other types are skipped)
successor edge
branch edge
minDescendants
relation
„ancestor“
The current graph
GroIMP maintains always a graph which contains the
complete current structural information. This graph is
transformed by application of the rules.
Attention: Not all nodes are visible objects in the 3-D view of
the structure!
- F0, F(x), Box, Sphere: yes
- RU(30), A, B: normally not (if not derived by „extends“
from visible objects)
The graph can be completely visualized in the 2-D graph
view (in GroIMP: Panels - 2D - Graph).
Load an example RGG file in GroIMP and execute some
steps (do not work with a too complex structure).
Open the 2-D graph view, fix the window with the mouse in
the GroIMP user interface and test different layouts (Layout
- Edit):
Tree
Sugiyama
Square
Circle
Random
SimpleEdgeBased
Fruchterman
Keep track of the changes of the
graph when you apply the rules
(click on „redraw“)!
which parts of the current graph of GroIMP are visible
(in the 3-d view) ?
all geometry nodes which can be accessed from the root
(denoted ^) of the graph by exactly one path, which consists
only of "successor" and "branch" edges
How to enforce that an object is visible in any case:
==>> ^ Object
Derivation modes in XL
default: parallel application of rules (like in L-systems)
to switch into sequential mode (then, in each step at most
one rule is applied at one match):
setDerivationMode(SEQUENTIAL_MODE)
to switch back to parallel mode:
setDerivationMode(PARALLEL_MODE)
test the example sm09_e32.rgg
a further type of rules:
actualization rules
often, nothing at the graph structure has to be changed, but
only attributes of one single node are to be modified (e.g.,
calculation of photosynthesis in one leaf).
For this purpose, there is an extra rule type:
A ::> { imperative code };
Test the examples sm09_e25.rgg, sm09_e16.rgg,
sm09_e17.gsz, sm09_e18.rgg
and concerning the access to node attributes: sm09_e26.rgg
necessary for the distribution of assimilates:
modelling of transport processes
approach: substrate flows from elements with high
concentration to neighbour elements with low concentration
(principle of diffusion)
example:
sm09_e41.rgg
(concentration of substrates is here
visualized by diameter)
module Internode(super.diameter) extends F(100, diameter);
protected void init()
[
Axiom ==> P(14) Internode(1) P(2) Internode(1)
P(4) Internode(1) P(15) Internode(60);
]
(two reverse successor edges, one after the other)
public void transport()
[
i_top:Internode < < i_bottom:Internode ::>
{
float r = 0.1 * (i_bottom[diameter] - i_top[diameter]);
i_bottom[diameter] :-= r;
i_top[diameter] :+= r;
}
]
Modelling diameter growth in plants
frequently used approaches:
- regression diameter ~ length for new growth units
- then, diameter increment dependent from age, branch order,
etc.
e.g., use rule with fixed annual growth
Shoot(l, d) ==> Shoot(l, d+delta_d);
interpretive rule for Shoot: Shoot(d) ==> F(l, d);
- or: “pipe model“ assumption
“pipe model“
(SHINOZAKI et al. 1964) :
parallel
“unit pipes“
cross section area
~ leaf mass
~ fine root mass
conclusion:
„Leonardo rule“ (da Vinci, about 1500)
di
In each branching node
we have
d2 =  di2
d
(invariance of cross
section area)
A1
A = A1 + A2
d 2 = d12 + d22
A
A2
realization in an XL-based model:
see examples sm09_e33.rgg, sm09_e34.rgg
there, first the structural and length growth is simulated, then
in separate steps the diameter growth, calculated top-down
(also a – more realistic – combination is possible)