Introduction - Within the FSPM community, different teams of researchers have specialized on different processes. Thus there is an increasing wish to re-use the diverse simulation packages which were already created but which are usually implemented within different software environments, often not directly compatible with each other. The OpenAlea platform (Pradal et al., 2008) was developed as an environment to connect and reuse components with specific functionality in a scientific workflow environment. However, not all widely-used FSPM-related tools are already available from OpenAlea. In our work, we created an interface between OpenAlea and the FSPM platform GroIMP (Kniemeyer, 2008). The latter contains some dedicated tools, among them a simulator for light distribution and interception, based on stochastic path tracing. This radiation model is interesting due to its accuracy, its spectral capabilities and because it is already used in different applications. To demonstrate the technical usability of our interface, we took an established simulator for the growth and structural development of apple trees, MAppleT (Costes et al., 2008), which is already accessible from OpenAlea but which does not include a radiation model on its own. By exporting the generated tree structures from MAppleT via OpenAlea to GroIMP, we were able to employ GroIMP's light model on them and to reimport the structures with added information on "absorbed light" at phytomer level. Within OpenAlea, photosynthesis was then calculated and tentatively assumed effects on organ sizes could be visualized. Our conceptual contributions are a generic web architecture and the bidirectional matching between two different multiscale formalisms for topology and geometry in FSPMs. OpenAlea - OpenAlea emphasizes modularity and reuse by using a central data structure, the MTG (Godin and Caraglio, 1998). This enables indirect communication between the components that are integrated in the platform, using a blackboard architecture. It captures the multiscale organization of plant canopies, particularly its topology. Various properties can also be stored at the different scales. MTG vertices are topological elements that represent modular parts of a plant (e.g., axis, phytomer, organ). The neighborhood of each element is stored in the MTG as well as its associated properties. Geometrical elements are stored separately in an external scene graph for efficiency but are available from a property of the MTG. GroIMP - In GroIMP, a scene, including virtual plants, is represented as a rooted graph which can be an MTG in the sense of Godin and Caraglio (1998). At the same time, it has the semantics of a scene graph (a well-known data model in computer graphics). In contrast to the MTG in OpenAlea, it contains all information about the scene including geometry. Its nodes can represent geometrical objects (e.g., standing for plant organs), light sources, spatial transformations (e.g., rotations), or they are abstract nodes used purely for replacement purposes during development. The development of scenes, including plants, is modelled by parallel graph rewriting: Rules are applied by substituting in every timestep all instances of graphs which occur as left-hand side of a rule by the corresponding right-hand side. L-systems, operating on strings, can be subsumed as special cases under this formalism. The Interface - Although the data models of OpenAlea and GroIMP were both derived from the same mathematical concept, the implemented data structures of both platforms differ in several aspects. To bridge the gap between them, a data extractor from OpenAlea to GroIMP has first to combine the topological (MTG) with the geometrical information and to build a scene graph where the global positional information of each object is split into the transformation matrices of its predecessors (in the graph) and of itself. Furthermore, the scale information, represented by an indexing of nodes in OpenAlea, must be evaluated to build decomposition edges between all node pairs where a direct "is-part-of" relationship shall exist in the GroIMP graph. An extractor for the reverse data flow, from GroIMP to OpenAlea, faces another problem: since the GroIMP graph can contain cycles in the general case, a spanning tree has first to be derived within each scale level to be able to form a valid MTG on OpenAlea. Our graph model for data exchange is a canonical data model that makes the interoperability infrastructure independent from any specific FSPMs. It is a rooted, directed graph with typed nodes and thus more generic than an MTG. Technically, our connecting software tool consists of a client-side interface on top of OpenAlea and a server-side interface on top of GroIMP. An XML based data exchange format called XEG specified from the generic data exchange graph model is provided for the integration. Details are given by Long (2019). Results and Discussion - In a case study, we have applied our interface to provide an integration of the MAppleT model (Costes et al., 2008), that simulates apple tree growth and development based on stochastics and biomechanics and which is accessible via OpenAlea, with a light interception model based on stochastic pathtracing implemented within GroIMP. The objective was to get a bi-platform FSPM that simulates growth by taking local light interception into account. The workflow is as follows: Through the client-side interface the MTG generated by MAppleT is translated to an XEG graph, which is then packed to a message for transmission to the light interception model which resides remotely (on GroIMP). Through the server-side interface, the message is received, unpacked and translated into a GroIMP graph, forming the input of the light interception model. Then, update rules are applied which change a property "absorbed light" of nodes representing geometrical objects, according to the raytracing results. Through the server-side interface, the result is translated to a data frame in XEG packed to be sent back to OpenAlea (respectively, MAppleT) to complete the cross-platform simulation. Through the client-side interface, the data is unpacked and translated to Open- Alea as an MTG. Here, as growth in MAppleT is originally not based on light, we have as a first attempt applied an ad-hoc computation of biomass based directly on the intercepted light. The growth of an apple fruit then depends on the new biomass and thus on the light values from GroIMP. Botanically, this scenario is certainly not realistic since it disregards any translocation of assimilates, but it proves technical usability of the interface. Acknowledgements - Parts of this work were funded by DFG and ANR in the joint project "Multiscale functional-structural plant modelling at the example of apple trees", DFG grant number KU 847/11-1.