Update tutorials to the new API

Author: AleMorales

Algae/Algae.jl

@@ -1,7 +1,8 @@
-#=
-Algae growth
+#= Algae growth
+
+Alejandro Morales
 
-Alejandro Morales - May 2023
+Centre for Crop Systems Analysis - Wageningen University
 
 In this first example, we learn how to create a `Graph` and update it
 dynamically with rewriting rules.
@@ -12,10 +13,11 @@ Lindermayer as one of the first L-systems.
 
 First, we need to load the VPL metapackage, which will automatically load all
 the packages in the VPL ecosystem.
-=#
-using VPL
 
+=#
+using VirtualPlantLab
 #=
+
 The rewriting rules of the L-system are as follows:
 
 **axiom**:   A
@@ -29,23 +31,25 @@ type `A` or `B` and inherit from the abstract type `Node`. It is advised to
 include type definitions in a module to avoid having to restart the Julia
 session whenever we want to redefine them. Because each module is an independent
 namespace, we need to import `Node` from the VPL package inside the module:
+
 =#
 module algae
-    import VPL: Node
+    import VirtualPlantLab: Node
     struct A <: Node end
     struct B <: Node end
 end
 import .algae
-
 #=
+
 Note that in this very example we do not need to store any data or state inside
 the nodes, so types `A` and `B` do not require fields.
 
 The axiom is simply defined as an instance of type of `A`:
+
 =#
 axiom = algae.A()
-
 #=
+
 The rewriting rules are implemented in VPL as objects of type `Rule`. In VPL, a
 rewriting rule substitutes a node in a graph with a new node or subgraph and is
 therefore composed of two parts:
@@ -68,21 +72,23 @@ objects that inherit from `Node`. The operation `+` implies a linear
 relationship between two nodes and `[]` indicates branching.
 
 The implementation of the two rules of algae growth model in VPL is as follows:
+
 =#
 rule1 = Rule(algae.A, rhs = x -> algae.A() + algae.B())
 rule2 = Rule(algae.B, rhs = x -> algae.A())
-
 #=
+
 Note that in each case, the argument `rhs` is being assigned an anonymous (aka
 *lambda*) function. This is a function without a name that is defined directly
 in the assigment to the argument. That is, the Julia expression `x -> A() + B()`
 is equivalent to the following function definition:
+
 =#
 function rule_1(x)
     algae.A() + algae.B()
 end
-
 #=
+
 For simple rules (especially if the right hand side is just a line of code) it
 is easier to just define the right hand side of the rule with an anonymous
 function rather than creating a standalone function with a meaningful name.
@@ -92,45 +98,55 @@ from the REPL.
 With the axiom and rules we can now create a `Graph` object that represents the
 algae organism. The first argument is the axiom and the second is a tuple with
 all the rewriting rules:
+
 =#
 organism = Graph(axiom = axiom, rules = (rule1, rule2))
-
 #=
+
 If we apply the rewriting rules iteratively, the graph will grow, in this case
 representing the growth of the algae organism. The rewriting rules are applied
 on the graph with the function `rewrite!()`:
+
 =#
 rewrite!(organism)
-
 #=
+
 Since there was only one node of type `A`, the only rule that was applied was
 `rule1`, so the graph should now have two nodes of types `A` and `B`,
 respectively. We can confirm this by drawing the graph. We do this with the
 function `draw()` which will always generate the same representation of the
 graph, but different options are available depending on the context where the
 code is executed. By default, `draw()` will create a new window where an
 interactive version of the graph will be drawn and one can zoom and pan with the
-mouse.
+mouse (in this online document a static version is shown, see
+[Backends](../../manual/Visualization.md) for details):
+
 =#
 import GLMakie
 draw(organism)
-
 #=
+
 Notice that each node in the network representation is labelled with the type of
 node (`A` or `B` in this case) and a number in parenthesis. This number is a
 unique identifier associated to each node and it is useful for debugging
 purposes (this will be explained in more advanced examples).
 
 Applying multiple iterations of rewriting can be achieved with a simple loop:
+
 =#
 for i in 1:4
     rewrite!(organism)
 end
+#=
 
-# And we can verify that the graph grew as expected:
+ANd we can verify that the graph grew as expected:
+
+=#
 draw(organism)
+#=
 
-# The network is rather boring as the system is growing linearly (no branching)
-# but it already illustrates how graphs can grow rapidly in just a few
-# iterations. Remember that the interactive visualization allows adjusting the
-# zoom, which is handy when graphs become large.
+The network is rather boring as the system is growing linearly (no branching)
+but it already illustrates how graphs can grow rapidly in just a few iterations.
+Remember that the interactive visualization allows adjusting the zoom, which is
+handy when graphs become large.
+=#

Algae/Algae.md

@@ -1,6 +1,8 @@
 # Algae growth
 
-Alejandro Morales - May 2023
+Alejandro Morales
+
+Centre for Crop Systems Analysis - Wageningen University
 
 In this first example, we learn how to create a `Graph` and update it
 dynamically with rewriting rules.
@@ -12,8 +14,8 @@ Lindermayer as one of the first L-systems.
 First, we need to load the VPL metapackage, which will automatically load all
 the packages in the VPL ecosystem.
 
-```{julia}
-using VPL
+```julia
+using VirtualPlantLab
 ```
 
 The rewriting rules of the L-system are as follows:
@@ -30,9 +32,9 @@ include type definitions in a module to avoid having to restart the Julia
 session whenever we want to redefine them. Because each module is an independent
 namespace, we need to import `Node` from the VPL package inside the module:
 
-```{julia}
+```julia
 module algae
-    import VPL: Node
+    import VirtualPlantLab: Node
     struct A <: Node end
     struct B <: Node end
 end
@@ -44,7 +46,7 @@ the nodes, so types `A` and `B` do not require fields.
 
 The axiom is simply defined as an instance of type of `A`:
 
-```{julia}
+```julia
 axiom = algae.A()
 ```
 
@@ -71,7 +73,7 @@ relationship between two nodes and `[]` indicates branching.
 
 The implementation of the two rules of algae growth model in VPL is as follows:
 
-```{julia}
+```julia
 rule1 = Rule(algae.A, rhs = x -> algae.A() + algae.B())
 rule2 = Rule(algae.B, rhs = x -> algae.A())
 ```
@@ -81,7 +83,7 @@ Note that in each case, the argument `rhs` is being assigned an anonymous (aka
 in the assigment to the argument. That is, the Julia expression `x -> A() + B()`
 is equivalent to the following function definition:
 
-```{julia}
+```julia
 function rule_1(x)
     algae.A() + algae.B()
 end
@@ -97,15 +99,15 @@ With the axiom and rules we can now create a `Graph` object that represents the
 algae organism. The first argument is the axiom and the second is a tuple with
 all the rewriting rules:
 
-```{julia}
+```julia
 organism = Graph(axiom = axiom, rules = (rule1, rule2))
 ```
 
 If we apply the rewriting rules iteratively, the graph will grow, in this case
 representing the growth of the algae organism. The rewriting rules are applied
 on the graph with the function `rewrite!()`:
 
-```{julia}
+```julia
 rewrite!(organism)
 ```
 
@@ -117,9 +119,9 @@ graph, but different options are available depending on the context where the
 code is executed. By default, `draw()` will create a new window where an
 interactive version of the graph will be drawn and one can zoom and pan with the
 mouse (in this online document a static version is shown, see
-[Backends](../../manual/Visualization/index.qmd) for details):
+[Backends](../../manual/Visualization.md) for details):
 
-```{julia}
+```julia
 import GLMakie
 draw(organism)
 ```
@@ -131,15 +133,15 @@ purposes (this will be explained in more advanced examples).
 
 Applying multiple iterations of rewriting can be achieved with a simple loop:
 
-```{julia}
+```julia
 for i in 1:4
     rewrite!(organism)
 end
 ```
 
 ANd we can verify that the graph grew as expected:
 
-```{julia}
+```julia
 draw(organism)
 ```
 

Context/Context.jl

@@ -1,8 +1,9 @@
-#=
 
-Context sensitive rules
+#= Context sensitive rules
+
+Alejandro Morales
 
-Alejandro Morales - May 2023
+Centre for Crop Systems Analysis - Wageningen University
 
 This examples goes back to a very simple situation: a linear sequence of 3
 cells. The point of this example is to introduce relational growth rules and
@@ -29,10 +30,11 @@ the right hand side, we replace the cell with a new cell with the state of the
 parent node that was captured. Note that that now, the rhs component gets a new
 argument, which corresponds to the context of the father node captured in the
 lhs.
+
 =#
-using VPL
+using VirtualPlantLab
 module types
-    using VPL
+    using VirtualPlantLab
     struct Cell <: Node
         state::Int64
     end
@@ -48,46 +50,57 @@ end
 rule = Rule(Cell, lhs = transfer, rhs = (context, father) -> Cell(data(father).state), captures = true)
 axiom = Cell(1) + Cell(0) + Cell(0)
 pop = Graph(axiom = axiom, rules = rule)
-
 #=
+
 In the original state defined by the axiom, only the first node contains a state
 of 1. We can retrieve the state of each node with a query. A `Query` object is a
 like a `Rule` but without a right-hand side (i.e., its purpose is to return the
 nodes that match a particular condition). In this case, we just want to return
 all the `Cell` nodes. A `Query` object is created by passing the type of the
 node to be queried as an argument to the `Query` function. Then, to actually
 execute the query we need to use the `apply` function on the graph.
+
 =#
 getCell = Query(Cell)
 apply(pop, getCell)
+#=
 
-# If we rewrite the graph one we will see that a second cell now has a state of 1.
+If we rewrite the graph one we will see that a second cell now has a state of 1.
+
+=#
 rewrite!(pop)
 apply(pop, getCell)
+#=
+
+And a second iteration results in all cells have a state of 1
 
-# And a second iteration results in all cells have a state of 1
+=#
 rewrite!(pop)
 apply(pop, getCell)
-
 #=
+
 Note that queries may not return nodes in the same order as they were created
 because of how they are internally stored (and because queries are meant to
 return collection of nodes rather than reconstruct the topology of a graph). If
 we need to process nodes in a particular order, then it is best to use a
 traversal algorithm on the graph that follows a particular order (for example
-depth-first traversal with `traverseDFS()`). This algorithm requires a function
+depth-first traversal with `traverse_dfs()`). This algorithm requires a function
 that applies to each node in the graph. In this simple example we can just store
 the `state` of each node in a vector (unlike Rules and Queries, this function
 takes the actual node as argument rather than a `Context` object, see the
 documentation for more details):
+
 =#
 pop  = Graph(axiom = axiom, rules = rule)
 states = Int64[]
-traversedfs(pop, fun = node -> push!(states, node.state))
+traverse_dfs(pop, fun = node -> push!(states, node.state))
 states
+#=
 
-# Now the states of the nodes are in the same order as they were created:
+Now the states of the nodes are in the same order as they were created:
+
+=#
 rewrite!(pop)
 states = Int64[]
-traversedfs(pop, fun = node -> push!(states, node.state))
+traverse_dfs(pop, fun = node -> push!(states, node.state))
 states

Context/Context.md

@@ -1,7 +1,9 @@
 
 # Context sensitive rules
 
-Alejandro Morales - May 2023
+Alejandro Morales
+
+Centre for Crop Systems Analysis - Wageningen University
 
 This examples goes back to a very simple situation: a linear sequence of 3
 cells. The point of this example is to introduce relational growth rules and
@@ -30,9 +32,9 @@ argument, which corresponds to the context of the father node captured in the
 lhs.
 
 ```julia
-using VPL
+using VirtualPlantLab
 module types
-    using VPL
+    using VirtualPlantLab
     struct Cell <: Node
         state::Int64
     end
@@ -82,7 +84,7 @@ because of how they are internally stored (and because queries are meant to
 return collection of nodes rather than reconstruct the topology of a graph). If
 we need to process nodes in a particular order, then it is best to use a
 traversal algorithm on the graph that follows a particular order (for example
-depth-first traversal with `traverseDFS()`). This algorithm requires a function
+depth-first traversal with `traverse_dfs()`). This algorithm requires a function
 that applies to each node in the graph. In this simple example we can just store
 the `state` of each node in a vector (unlike Rules and Queries, this function
 takes the actual node as argument rather than a `Context` object, see the
@@ -91,7 +93,7 @@ documentation for more details):
 ```julia
 pop  = Graph(axiom = axiom, rules = rule)
 states = Int64[]
-traversedfs(pop, fun = node -> push!(states, node.state))
+traverse_dfs(pop, fun = node -> push!(states, node.state))
 states
 ```
 
@@ -100,6 +102,6 @@ Now the states of the nodes are in the same order as they were created:
 ```julia
 rewrite!(pop)
 states = Int64[]
-traversedfs(pop, fun = node -> push!(states, node.state))
+traverse_dfs(pop, fun = node -> push!(states, node.state))
 states
 ```