The integration of different FSPMs using the interface

After comprehensive introduction of the integrative middleware, i.e. the interface, we move to the application. Before we integrated the target FSPMs, we have performed several experiments which exhibit the practical usage of the interface and validate its implementations.

Figure 6.4 The identical results of the same GroIMP model directly run on GroIMP (left) and invoked from OpenAlea through a FSPM integrative RPC call (right).

We have firstly tried an experiment to test the interface by applying a simulation of a GroIMP model at the OpenAlea side, that means to just make a FSPM integrative RPC call by directly providing all the request members of message body including the model (i.e. XL code, it is possible also to have the it at server side).

Figure 6.4 shows the graphic views of the simulation results of a GroIMP model.

The right panel shows the graphic view of the simulation ‘executed’ at the OpenAlea side by making a FSPM integrative RPC call. The graphic view is identical with the graphic view of the simulation executed directly at the GroIMP side. Notice that an object of PlantGL TriangleSet type consists of two objects of PlantGL Triangle type and represents an object of Parallelogram type of IMP3D. It is also noticeable that the message structure members ‘graph’ and ‘model’ here are single scaled. Consequently, the experiment validates the implementations for the communication group at both client and server side, the ETL group at both sides, especially the transform process at client side including turtle commands and triangulation of Parallelogram, the extract and load processes at both sides for a topology of a ‘single’ scaled model and multiple plants.

A. FSP data representing a small apple tree

We tried a second experiment to test the interface by applying ETL processes to three MTGs generated by MAppleT simulations that encode a small apple tree with only internodes and leaves, a medium apple tree including flowers, and a large apple tree with apple fruit. Figure 6.5 shows the three virtual apple trees encoded in RGG Figure 6.5 FSP data in RGG graph (left)/MTG (right) after ETL processed

B. FSP data representing an apple tree with flowers

C. FSP data representing an apple tree with fruits

graph and MTG. All three virtual apple trees encoded in RGG graph are loaded from three XEGs generated by the ETL processes of ClientSideInterface in the direction of MTG to XEG. The virtual apple tree encoded in MTG at the right side of part A is the original result from the MAppleT simulation. The other two virtual apple trees encoded in MTG on the right side of part B and C are converted from the two corresponding virtual apple trees encoded in RGG graph on the left via XEGs (through an ETL process from RGG graph to XEG and an ETL process from XEG to MTG). Figure 6.6 shows partially the topology of the RGG graph converted from the XEG encoding the small apple tree (the topology embodying the decomposition scheme of ‘leaf’ metamer nodes M1 and M2 can be directly viewed).

Such an experiment geometrically validates the ETL processes at both client and server sides.

Figure 6.6 The topology of the RGG graph converted from an XEG encoding a small apple tree from MAppleT shown in 2D on GroIMP

Nodes at sub metamer scale

Nodes at metamer scale Nodes at GU

scale

A node at tree scale Successor edge

Branch edge

Decomposition edge

We tried a third experiment to test the interface by applying a simulation of a simple GroIMP model through ETL processes. We used a GroIMP model with a single production rule to change the color of plant modules representing internodes, then loaded the modified FSP data to XEG and sent them back to ClientSideInterface. Thus the XEG appears to correctly present the plant structure with modified color. Figure 6.7 shows that the plant structure is correctly represented in different MTGs and RGG graphs with modified color. This experiment approved that the FSP data passed through ETL processes by the interface can be further processed by a GroIMP model, and the processed results with updated data can be correctly re-encoded in MTG for MAppleT’s further simulation. One remark is that the nodes in a RGG graph are initially of a graphic type without functional properties, which is exactly the case for XEG as it is converted from MTG. It is necessary to allow the simulated functional properties Figure 6.7 Experiment to test the interface by a GroIMP color-changing model.

The arrow points to show the flow of data between different data models and FSPM.

to be stored in the RGG graph imported from XEG. We first came up with the approach to replace an original node by a module type that extends the type of the original node. This approach complies with the GroIMP method to define a plant module with functional properties but it brings some inconveniencies. In fact, after the GroIMP model simulation, the result needs to be converted back to XEG. At its finest scale, the nodes with functional properties are of extended module types. The interface converts the nodes to objects of PlantGL types to form an object of PlantGL Scene type. That means the properties need to be moved and added up to nodes at metamer scale. Therefore, we think it is appropriate to directly sum up the values of all properties of nodes at the finest scale that are decomposed from a metamer node to be summed to the corresponding properties of the metamer node.

Such a process avoids the type extension and is actually a property upscaling. It is necessary to have such property upscaling for the retroactive simulation because the simulated result needs to be converted back to MTG which has its properties carried not by graphic objects but by nodes at metamer or coarser scales. Figure 6.8 shows an example of property upscaling that sums up the property

‘interceptedLightAmount’ from four different nodes (G1, G2, G3 and G4) at growth unit scale to a node (T1) at tree scale. Notice that this particular method was chosen because it meets our specific needs. There are various other methods for property upscaling besides this method.

After the experiments, we can now perform a simulation of the integrated FSPM by using the interface. Through the interface, MAppleT and the GroIMP transport model were supposed to be integrated as one model that was supposed to be able to simulate apple tree growth by considering the water and sugar conditions. However, we have changed the simulation plan for internal reasons. The new plan was to integrate a GroIMP light model with MAppleT. MAppleT is a stochastic model that does not take any functional conditions except gravity to compute the structure of apple trees. An intermediate OpenAlea FSPM that takes light conditions to compute the photosynthesis is planned to do a pre simulation before that done by MAppleT.

MAppleT then takes over the tree structure with properties of assimilate content from photosynthesis to play with the size of each plant module. In such a way, the project can be validated and the concept of the integration of different FSPMs can be approved as well.

Figure 6.8 An example of property upscaling.

A Module that extends the ray tracer based GroIMP type SpotLight is used in the light model as the type of light source. We set up a particular position for the light, and varied the light energy (i.e. the power in Watt) and the number of rays. We want to compare the MAppleT simulated structure by different light energy (same numbers of rays), and by different numbers of rays (same light energy). The light model computes the amount of light being absorbed by the plant modules and we assumed that only green plant modules can intercept light.

So far, we are still working at the simulation of the integrated FSPM through the