Appendix A: Implementation Details
Previous LIMS Architecture for Communication with External Applications
In our previous work, the LIMS flow simulation was already coupled with additional programs. Primarily, this has been used for integrating the simulation into other software  and for optimization and control [19, 20, 27, 28]. The communication interface is shown in Fig.
14. This is used to pass the commands and communicate through textual printed lines through shared memory under Windows (used by LIMS interface (LimsUI) or, for example, Matlab through dynamic link library).
Additionally, there is available and tested extension that allowed passing of entire simulation state in the same way. It is not particularly efficient and is not currently supported in standard LIMS distribution. Note that this mechanism was used to couple the master program (LIMS or other programs) with other LIMS used as the worker process. There was no coupling with different simulation engine(s), although such steps were feasible. All the significant coupled physics model (dual scale flow , compliant reinforcement flow ) were implemented as LIMS scripts and ran within the simulation without a need for external communication.
Proposed Model Coupling Scheme(s)
The memory sharing scheme for commands was fairly successful in 1990s, but (1) It is based on low-level 32-bit windows implementation that is obsolete and (2) It never provided options to control other programs other than LIMS. The additional physics models run as scripts are feasible but inefficient hence the communication routines to standard MPI (Message Passing Interface) runtime were preferred and implemented. The necessary functionality to implement coupling as in Fig. 14 was obtained in simple, system-independent fashion by utilizing MPI to handle any shared buffers. For single CPU system it will likely be through shared memory as in the old implementation, but it should work over networks on clusters as well. New, more efficient way to pass the simulation state through the same interface was also implemented.
This approach allows LIMS to control other simulation processes including different instance(s) of LIMS, or to be executed and controlled by other executables. The messages passed through MPI simply replace the text typed on command line or in a script file.
Implementation Based on Basic MPI Functions
The implementation of coupling mechanism allows execution of all three possibilities in Fig.
15. Of these scenarios, (b) is the one we used to simulate additional transport phenomena. LIMS scripting is used to control the entire modeling and input/output sequence. The scenario (a) is more useful for process optimizations and development as it can run multiple flow simulations on multiple cores—option available on every modern workstation. Scenario (c) passes the control to a non-LIMS executable. It allows as much flexibility as the master program offers. As a part of its execution, master will request the flow simulation results as needed. This can work for both optimization and transport modeling, but it requires more coding unless the master program is MPI-enabled platform like Python.
Modified LIMS program can be executed as master, worker or both. It is executed through MPIrun or MPIexec and it is able to detect whether it runs as master (ID zero) or worker (ID 1 and higher).
When being executed as a master, LIMS reads its commands as self-standing and does print its output in the standard way. It can run as a self-standing flow simulation as well. However, it offers several commands in its scripting language to control the execution of workers. It can determine how many workers are available. It can communicate with its workers at any time with a line of text (as commands). Finally, it can determine if any worker sends a response and act accordingly.
If LIMS finds itself in worker’s role, there are no additions for control. It receives commands transparently from the MPI runtime when the master issues them. The output is delivered to the master. For other worker programs, such as the transport simulations presented above, the control communication involves receiving and sending MPI messages in plain text format. For transport modeling, C + + skeleton file (template) was built to:
Take care of the communication and synchronization details
Read LIMS simulation state at the beginning of each step
Evaluate some additional resin flow data, such as velocities, which are not evaluated within LIMS and are missing in its state
Evaluate geometry that is necessary for convective/conductive transfer
Create connectivity links to allow solution of equations such as Eq. (4) or (7) on element-by-element basis
The simulations presented were built using this template.
The state data exchange is straightforward but (for the sake of efficiency) it requires binary compatibility between programs. Regardless of whether LIMS acts as a master or worker, the simulation state can be sent to other processes (master or worker) and retrieved from them by a single function call from the script or the command line. LIMS will use its current state to export and update its current state on import. This uses several large binary blocks of data and it is quite efficient compared to the older approaches that transferred data based on node by node, element by element fashion even if in binary form.
There are several MPI calls needed to import the state, as size information must precede the entity blocks. The other simulation programs need to read and write a proper sequence of messages starting with counts and followed by blocks of nodal, elemental and inlet data. They will need to understand LIMS data structures to decode these. This approach puts some limitations on executables and architecture—essentially, all executables should be built with the same compiler and settings. However, it avoids the need to reformat and re-code large data structures which may be extremely slow compared to the actual solution of Eq. (8). Note that the skeleton file built for the transport models already contains this code and the same skeleton may be used for other conceivable transport problems.