Coupled Process Modeling of Flow and Transport Phenomena in LCM Processing

Abstract

In Liquid Composite Molding (LCM) processes, dry fabric preforms are impregnated with a thermoset resin in a closed mold to fabricate a composite. The resin impregnation process is usually accompanied by other phenomena. In this work, we concentrate on transport phenomena such as convection of heat, cure and volatiles that impact the filling process and/or the quality of the manufactured part. Conventional approach to modeling such a flow is to integrate all the involved physics into the numerical solver. The complexity of integrated computational models will increase the computational time and complicate modification of transport and retention models once implemented. The latter particularly complicates the exploratory modeling attempts to uncover additional physics that require fast and easy code modification. We propose and provide an implementation methodology to separately couple transport and flow models. With this approach, one can couple flow simulation using highly specialized simulation tools with associated transport phenomena that use separate implementation. The emphasis is on transport of volatiles, both discrete bubbles and dissolved solvents, but it is equally applicable to other problems, such as particle transport and filtration or cure propagation. The challenge of this approach is to (1) formulate proper models and implement them and (2) solve the communication between models efficiently. In our case, the distinct models can be coupled through data exchange, via standardized message passing interface (MPI). A well-tested and optimized flow simulation tool LIMS (Liquid Injection Molding Simulation) is used to implement the coupled simulation processes and transfer the simulation state in an efficient manner to model other transport phenomena. Coupled models to track distinct particles and/or bubbles of volatiles and implement convected/diffused dissolved volatiles. The results are presented highlighting the feasibility and utility of this methodology.

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 [19] and for optimization and control [19, 20, 27, 28]. The communication interface is shown in Fig. 

Fig. 14

LIMS communication interface through Windows shared memory

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 [24], compliant reinforcement flow [18]) 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. 

Fig. 15

LIMS communication interface through MPI. a LIMS used to control other LIMS programs(s), for example, for multi-scenario simulation and optimization. Either LIMS can run simulation and simulation state can be sent as needed. b Use of LIMS to simulate the flow and to control coupled simulation models, for example transport. This is the layout used in this paper. c Use other programs to control LIMS. LIMS simulates the flow, the master program may aggregate data from LIMS to simulate something else

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.