Understanding Fluid Flow in Microchannels 

Last March, in the context of the UberCloud CAE Experiment, a joint team of researchers from the Rutgers Discovery Informatics Institute (RDI2) – Javier Diaz-Montes, Manish Parashar, Ivan Rodero, Jaroslaw Zola (Rutgers Discovery Informatics Institute) and Baskar Ganapathysubramanian, Yu Xie (Computational Physics and Mechanics Laboratory at Iowa State University) launched a large scale computational experiment aimed at understanding how to control fluid streams using a novel technique based on the idea of appropriately placing pillars to disrupt the flow. This experiment used a dynamically federated and geographically distributed HPC-Cloud infrastructure enabled by CometCloud to gather the most comprehensive information to date on the effects of pillars on microfluid channel flow.

The ability to control fluid streams at microscale is of great importance in many domains such as biological processing, guiding chemical reactions, and creating structured materials. Recently, it has been discovered that placing pillars of different dimensions, and at different offsets, allows fluid transformations to “sculpt” fluid streams. As these transformations provide a deterministic mapping of fluid elements from upstream to downstream of a pillar, it is possible to sequentially arrange pillars to obtain complex fluid structures.

To understand how the flow is affected by the pillar, the team from Iowa State University has developed a parallel MPI-based Navier-Stokes equation solver, which can be used to simulate flows in a microchannel with an embedded pillar obstacle. The solver takes four parameters, namely microchannel height, pillar location, pillar diameter, and Reynolds number, and captures the characteristics of the flow (see Figure 1). Using this solver, the fluid flow control problem can be formulated as interrogating the resulting 4D parameter space, in which a single point is equivalent to a parallel Navier-Stokes simulation with a specific configuration.

Figure 1: Example flow in a microchannel with a pillar. Four variables characterize the simulation: channel height, pillar location, pillar diameter, and Reynolds number.

The search space consists of tens of thousands of points, and an individual simulation may take hundreds of core-hours even when executed on a state-of-the-art HPC system. In particular, in this experiment the team determined that to interrogate the parameter space at the satisfactory precision level 12,400 simulations (tasks) would be required. While this number is already challenging, it should be noted that approximately 300,000 tasks would be required to provide a fine-grained view of the parameter space. Moreover, the tasks are very heterogeneous in terms of their hardware requirements and computational complexity. For instance, some tasks require a minimum of 512 GB of RAM, while many can execute with only 64 GB. Finally, because the non-linear solver is iterative, it may fail to converge for some combinations of input parameters, in which case fault-tolerance mechanisms are required.

The computational requirements of the problem suggest that solving this problem using standard computational resources is practically infeasible. Thus, the team from Rutgers University developed a novel federation framework, based on CometCloud, aimed to enable an average user to dynamically aggregate HPC and Cloud resources as services, much like how volunteer computing assembles cycles on desktop computers. The proposed federation model offers a unified view of heterogeneous resources, and exposes them using cloud-like abstractions, as illustrated Figure 2. At the same time the model remains user-centered, and can be used by any user without special privileges on the federated resources. The experiment federated 10 different resources provided by six institutions from three countries, lasted 16 days, 12 hours, 59 minutes, consumed 2,897,390 core-hours, and generated 398~GB of the output data.

Figure 2: Multi-layer design of the proposed federation model. Here, the federation overlay dynamically interconnects resources; the service layer offer services such as associative object store or messaging; the programming abstractions offers APIs to easily create user applications; and the autonomic manager is a cross-layer component that based on user data and policies provisions appropriate resources.

 As a result of this experiment we obtained the most comprehensive data on the effect of pillars on microfluid channel flow. Although we are still in the process of analyzing this massive output, we already gained several interesting insights regarding fundamental features of the flow. Figure 3 shows how different flow modes are distributed in the parameter space. Here, each mode corresponds to one or two vortices generated. When describing the problem we hinted that by arranging pillars into a specific sequence it is possible to perform basic flow transformations. Thanks to the library of flow configurations that we generated in this experiment, we can now investigate the inverse problem and, for example, ask questions about the optimal pillar arrangement to achieve a desired flow output. This in turn will have far reaching applicability in many real world problems such as medical diagnostics and smart materials engineering.

Figure 3: The phase diagram showing how different flow modes are distributed in the parameter space. Here, pillar offset is 0, D is a pillar diameter, h is a channel height, w is channel width, and Re is Reynolds number.

 The success of this experiment clearly demonstrates the capability, feasibility, and advantages of such a user-centered computational federation. In the experiment, a regular user was able to solve a large scale computational engineering problem, within just two weeks. More information about the experiment can be found at http://nsfcac.rutgers.edu/CometCloud/uff/. To join the UberCloud CAE Experiment one can register at http://www.caeexperiment.com.