Summer School „Modelling and Simulation with GroIMP“ / Tutorial for beginners

1. 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 filessm09_e??.rgg URL http://www.uni-forst.gwdg.de/~wkurth/ and driveT:\rggon CIP pool stations

2. 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 (blank) branch edge: -branch->, +> or [ refinement edge: />

3. 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)

4. 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)

5. derived relations relation between nodes connected by several edges (one after the other) of the same type: „transitive hull“ of the original relation (edge)

6. 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)

7. successor edge branch edge minDescendants relation „ancestor“

8. 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).

9. 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“)!

10. 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

11. 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

12. 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

13. 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)

14. 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); ] 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; } ] (two reverse successor edges, one after the other)

15. 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

16. “pipe model“ (SHINOZAKI et al. 1964) : parallel “unit pipes“ cross section area ~ leaf mass ~ fine root mass

17. conclusion: „Leonardo rule“ (da Vinci, about 1500) di  In each branching node we have d2 = di2 (invariance of cross section area)  d

18. 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)