History of LIMS
Disclaimer: This is not a research paper but my personal recollection of what happen, when it happened and to what purpose it was done for. This tacitly assumes I ever understood that purpose.
Once Liquid Composite Molding was established, the need came to determine resin flow patterns and,indeed, the filling times for parts. This need manifested itself in granting some taxpayer money to develop proper tools, obviously after much more significant amounts were wasted in gung-ho trial and error approach in some doomed projects.
Now, modeling flow through truly stationary porous media seems quite simple, an elliptic equation for pressure, but as usually, the devil lies in details that tend to be unearthed only as you go on. Check the publications for incomplete list of these challenges. None the less, at the University of Delaware, S.G. Advani and M. Bruschke started from old (C.L. Tucker's and S.G. Advani's) code TIMS and LIMS was born. LIMS (Liquid Injection Molding Simulation) proved its usefulness in correctly, albeit too late, predicting the very failures that led to its development.
This came before my days on this project. LIMS in versions 1, 2 and 3 was Fortran code modeling flow in two-dimensional shells (2.5 D), with version 3 adding rudimentary pseudo-3D temperature evaluation, being the first not quite successful attempt to tackle the obvious differences in the solution domains for the flow and the energy transfer. The growth of LIMS, however, strained its provisional roots too much and by mid nineties the code needed overhaul.
LIMS 4 Arrival
Early LIMS was surprisingly good program. It accepted and handled anisotropic viscosity and, in rudimentary form, supported sequential injections, both features that some commercial products still ignore thirty years later.
The development stopped for several years as M. Bruschke left Delaware before we picked it up again. There were a few reasons for complete rewrite, some subjective, some objective, in some cases this was not that easy to determine and some reasons might be lost to posterity.
- The first reason which forced our hands was the work of Bob Maier and the ARL crew on solution methodology ( R.S. Maier, T.F. Rohaly, S.G. Advani, K.D. Fickie, K.D., A fast Numerical Method for Isothermal Resin Transfer Mold Filling, International Journal of Numerical Methods in Engineering 39, 1996 ). This replaced repetitive solution of pressure field for incremental matrix inversion, essentially changing the solution order for shell problems from N^3 to N^2, albeit with some sacrifice in bandwidth optimization.
- The second reason was the non-unique definition of anisotropic permeability that forced change in IO formats besides of the internal changes
- The third reason was the expansion of simulation controls to reflect the practice in RTM molding: Sensors, additional gates, vents and volatile pressure were to be modeled and non-trivial control options scripted.
- Finally, internal reorganization was necessary. With that, Fortran 77 was aborted and the revision was to become rewrite. And thus, LIMS 4.0 was born. Whether this was entirely successful is open to debate. LIMS became a child of 1997 with the obvious shortcoming or benefits, depending on the point of view. With C++ not being standardized yet, it was crafted in standard C of 89 vintage, making the program cross-platform. With scripting languages not yet dominated by Python or Lua, scripting engine was written from scratch. It looks like cut down Quick BASIC, though it is more like FORTH under the hood. With multiprocessing and process communication in early stages, the communication behavior became a source of some experimenting. The fast development came in early 2000 when none of the above looked that obsolete and the program performance based on Maier's algorithm was definitely thrilling. The structure of code was sound as the new functionality was actually expected within the modular system and it hopefully avoided at least the worst of C pitfalls. Later, none of the limits posed by algorithm, scripting engine or implementation language could be elevated. Only recently, more useful communication and data exchange based on MPI is being built. All the other left luggage is still on board, with the exception of some new support for old file formats.
The LIMS Expansion: Communication Routines
In the couple of years I taught in Sweden, the LIMS development continued. It all started with developing Windows shared memory concepts for the communication with other programs. This essentially meant that LIMS was compiled with code that replaced standard console input and output with reading and writing of buffers in windows shared memory. The same concept was applied to exchanging the simulation results as optimization requires forking of the simulation execution. The application to use LIMS needed to link a dynamic library and maintain the shared buffers.
The solution was essentially sound, and is still seen in action today whenever LIMS is run from LimsUI interface. The result exchange was flawed by sending the results through the node-by-node, element-by-element routines used for standard file input and output. This fit better to program design but it limited the performance to the degree that using standard binary files was not much worse. As a results there is not much use of this mechanism in the annals of LIMS, while the command control was quite successful and operated from within Matlab or Labview, not just LimsUI. That, by the way, came later and instead of using the dynamic library hard coded the controls in somewhat sub-optimal fashion.
This got the version number of 4.1.
The scheme was completely fine for a good decade. The problem came from using LIMS on other platforms. Linux - which obviously does not run Windows code - has been minor up to the point when we started running the optimization on clusters, but also 64 bit Windows which does not communicate with 32 bit processes that well. The current approach under development is to replace this mechanism with fairly simple MPI communication which is obviously cross platform and suitable for cluster execution - command line should pass even across different architectures. And the data exchange has added much lower level functionality that swaps directly memory blocks controlled by LIMS solver. As of this writing, the job is not quite finished.
The LIMS Expansion: 1D and 3D
After the abortive second attempt on non-isothermal solution (LIMS 4.2, see below), LIMS 5 of early 2000 was born from actual need to simulate thicker part infusion and parts with non-uniform permeability. These are common in larger scale VARTM manufacturing and that was a centerpiece of ONR project of that time. For that, LIMS was expanded to handle shells (2.5D), solids (3D) and runners (1D). These can be combined together in a single mesh, though to actually do so in rigorous way - read no mesh dependent artifacts - certain rules have to be followed.
The rules for element combinations were, after some blunders, established. Some natural steps are perfectly OK. Most importantly, adding 2D distribution media to the surface of 3D part or a 1D tube to the edge of 2D distribution media. But some, though commonly used, may introduce some issues. Most common of these is connecting 1D runner to 2D or 3D structure by its end. Then, it is no worse then setting single node inlet rather than modeling the inlet geometry as line or surface and you can do that to yourself without 1D elements.
Modeling of 3D layered structures is a tricky business, as the dimensions are uneven (planar dimensions in meters, thickness in cm) and the reinforcement permeability is very anisotropic. Sometimes, however, it is necessary to do full 3D model. In due time the way to mesh these problems were established and documented, proper toolkit of utility programs was developed and the necessary capability added to LIMS scripting commands.
At the same time, a steady stream of interns from Woelfenbuetel was playing the graphical user interface game and generated quite useful GUI for LIMS. The interface may not be very flashy, though it makes decent use of OpenGL and FLTK libraries, but it allows to read meshes, modify parameters, execute simulation and save and visualize output. Moreover, it embeds a number of features useful for RTM and VARTM simulation.
Generally, by 2008 or 2009 this was all closed and done. LIMS was useful tool, and we started working on how to actually use it. Applications turned to optimization, control and issues of variability, as well as some bleeding edge simulation of physical phenomena which are not built in but which the scripting interface proved capable of handling. Minor improvements and fixes were added here and then, but LIMS remained pretty stable in the last twelve years.
The LIMS Expansion: Non-Isothermal Solutions and Reacting Resins
The less said, the better. There is fundamental issue at stake here as the energy transfer rarely restricts itself into the same solution domain as flow. In other words, heat transfer happens in mold, air over bagged surfaces and other places. This is magnified by the fact that convective transfer equations are less stable than the elliptic equations for pressure and do not adapt to the large time steps that easily.
After version 3, the approximate solutions was attempted again in versions 4.2 and 6. None of these is in use. 4.2 used, instead of large number of temperature degrees of freedom through the shell thickness (as in LIMS 3.0) three-parametric temperature approximation. In theory, this works well for planar geometry as long as one can lump the heat transfer outside of the mold cavity into some boundary conditions on upper and lower surface. We did not get to verify this theory. We were adding 1D/3D geometry at the same time, and that was of higher importance and non-isothermal solution too limited for such an approach was temporarily postponed.
LIMS 6.0 built fully 3D solution. That, obviously, would not work with 2.5 D or, heaven forbid, 1D runners. Again, it kind of run but was not finalized and pressed into production. LIMS 6 never was.
Note: For uniformly reacting resin with transient viscosity at constant temperature, LIMS can provide solution quite well and very fast.