Exhaust after-treatment

 

 
 
Introduction

 

The subject of the automotive end-user test case from CERTH/CPERI is the exhaust after-treatment system of a light-duty (Euro III) direct injection Diesel engine. The motivation for the automotive application lies in the increasing market share of Diesel powered passenger automobiles and in the stricter emissions levels planned for both light- and heavy-duty Diesel vehicles, particularly in Europe and the USA. A Diesel exhaust after-treatment system is called upon to handle a number of pollutants, including nitrous oxides (NO, NO2), unburned hydrocarbons and particulate matter. The latter pollutant poses particular difficulties to the exhaust after-treatment system design which itself is constrained by the requirement of not adversely affecting engine operation and of maintaining the Diesel engine’s fuel economy advantage. A number of exhaust after-treatment devices such as catalytic converters and filters, based on porous and/or honeycomb-structured materials, are placed along the exhaust line in order to remove/convert the aforementioned pollutants. The function of these components and their interaction is strongly affected by exhaust gas flow field at many physical scales, from the scale of the exhaust system to the scale of the material features (honeycomb structure, pore microgeometry). At the same time, the ever increasing complexity of the Diesel exhaust after-treatment system dictates that isolated optimisation of component devices is not sufficient. The approach taken here to achieve the needed system-level optimisation is to use the FlowGrid environment as the computational engine providing the exhaust gas flow field at the larger physical scales, while flow and mass/heat transfer phenomena at the smaller scales are handled by pre-existing models, which will be coupled to the flow solution.

 
 
Detailed descriptions

 

The exhaust after-treatment system which forms the basis of the automotive test case is an experimental system installed in the engine test cell of the Aerosol & Particle Technology Laboratory (CERTH/CPERI). The system is connected to the exhaust flow of a 1.9 litre turbo-Diesel engine attached to an electronically controlled chassis dynamometer. The exhaust system is modular and can assume many configurations. The configuration selected for the current test case (shown in the figure) is one used for a series of tests within the year 2001. As this is a light duty system, it is based on standard 2 inch (internal) diameter pipe.



Geometry and components positioning for Diesel exhaust system installed in the engine test cell of the Aerosol & Particle Technology Laboratory (CERTH/CPERI). Small scale features / components of experimental instrumentation have been omitted.

The Diesel particulate filter (DPF) is composed of a ceramic square channel honeycomb with alternate channels plugged (see Figure 1.2). The material considered for the test case is porous silicon carbide with the following properties:

 

intrinsic porosity 45%
intrinsic density 3100 kg/m^3
permeability 5.4 x 10^(-13) m^2
effective heat capacity 690 J/kg/K (25ºC)
effective thermal conductivity 70 W/kg/K (25ºC)

 

The porous silicon carbide honeycomb, used for the experiments from which data will be used, has the following geometric features:

cell density 181 channels/in.^2
wall thickness 0.36 mm
plug length 4 mm
monolith diameter 144 mm
monolith length(L) 152 mm


The Diesel oxidation catalyst DOC also consists of a monolithic square channel honeycomb made of cordierite material (alumina) which is coating with a platinum catalyst. The DOC has the following geometric characteristics:

channel density 400 channels/in.^2
wall thickness 0.15 mm
monolith length (L) 100 mm
monolith diameter 150 mm

 

The above properties and characteristics can be translated into bulk properties (e.g. flow resistance) by analytic expressions, or are otherwise used in modelling the bulk behaviour of the honeycomb material regions. An indication of overall system dimensions is given in the figure



Overall dimensions of the experimental exhaust system modelled.

Description of relevant parameters to be observed

The primary objective of an automotive end-user in the current context is the use of the FlowGrid system in conjunction with application-specific models for the optimisation of the after-treatment system design. With the use of a simulation tool based on 3-D CFD modelling, this optimisation is primarily concerned with the system shape/configurationand with the sizing of the devices. With respect to device sizing, the prior art is the use of area-averaged values for the flow parameters within the after-treatment devices being modelled or, one level further, the modelling of an axisymmetric variation. Hence, the focus in the current context is in the additional information which a 3-D flow solver can provide:

  1. exhaust gas velocity and temperature profiles entering the DPF and DOC devices,
  2. temperature distribution within the devices due to 3-D internal heat transfer and non-axisymmetric heat losses to the exterior.


The aim is for the above parameters to be used as realistic boundary conditions for the application-specific models of the after-treatment devices. Specifically, within the DPF, coupling with the 3-D flow solver is expected to improve the predictive capability of the DPF regeneration model which will in turn be assessed by observation of:

  1. time response of the DPF pressure drop (flow resistance)
  2. time response of the DPF (internal) temperatures and outflow temperature,
  3. distribution of soot mass loading within the filter during and after the regeneration sequence.

    Available experimental data

In line with the intended benefit (for the automotive application) from the FlowGrid system, the experimental data provided originates from tests carried out to measure the performance of the after-treatment system devices, the more critical of which is the DPF.


The validation test for the DPF model coupled to the FlowGrid solver will be to capture the thermal response and pressure drop history of a regeneration event. This reponse data is shown in the figures below for two different DPFs subjected to the same regeneration sequence. The regeneration process is performed with the DPF previously loaded using exhaust from the same engine. DPF Pressure drop and internal temperature is measured at three centrally and three perimetrically placed thermocouples. The data shown is obtained from the exhaust system described under steady engine operation (1600 RPM, 75 Nm torque). After a stabilisation period, the regeneration process begins with a step-wise variation in the rate of post-injection of Diesel fuel. The post-injection is performed at the 90º bend upstream of the bypass junction. The effect of the post-injection has been characterised in a separate experiment which provided the results shown in the last figure in this section.


DPF pressure drop and temperatures at internally placed thermocouples during regeneration. Silicon carbide honeycomb filter, no catalytic coating.


DPF pressure drop and temperatures at internally placed thermocouples during regeneration. Silicon carbide honeycomb filter with catalytic coating: CeO2 + Pt (75 gr/ft3)



Exhaust temperature increase vs. injection rate of the controlled post-injection process for the filter regeneration, measured downstream of the Diesel oxidation catalyst. The linearity of the temperature response indicates a near 100% effectiveness for the injected fuel oxidation.

 

 
 
FlowGrid evaluation

 

Problem size


The problem size required to handle design and/or concept evaluation simulations of exhaust after-treatment systems is not expected to exceed 8 million cells. This estimate is based on an exhaust system size typical for a passenger car and grid density criteria used currently in off-Grid simulations of partial exhaust after-treatment systems.


Solution turn-around time: steady state calculation


Simulation of a complete exhaust system configuration with fully 3-D flow calculations is a (relatively expensive) commodity that would typically be used in the later stages of pre-production design or for evaluation of untried system configuration concepts which would not be allocated (more costly) time in the prototyping workshop and engine test cell. Under these circumstances, it is considered that a exhaust system engineer would accept a turn-around time of 12 hours for the initial steady-state simulation of a complete exhaust system for one set of boundary conditions and a problem size as indicated above.


Solution turn-around time: repeated steady state calculations


There will also be demand for quasi-steady or repeated steady-state runs based on an initial steady-state solution of which the boundary conditions or a material property is modified. A turn-around time up to a half hour would be acceptable for this type of calculation where only a small change in the solution is effected. Included in this turn-around time criterion is the delay for the re-activation of the solution process (assuming CPU availability on the Grid) and for the subsequent cessation of the calculations and delivery of results which the exhaust system engineer can process/inspect.


Solution turn-around time: transient calculation


It is more difficult to specify turn-around time criteria for fully transient calculations where the computational load is strongly dependednt on the variability of the boundary conditions and of the phenomena within the solution domain. It is conceivable that a turn-around time of the order of 48 hours would be considered acceptable for the simulation of, for example, a DPF regeneration event corresponding to 15 minutes of physical time. This turn-around time would be in addition to the steady-state calculation required to provide the initial conditions.


Ease of use and interactivity: problem set-up


It is anticipated that in order for the FlowGrid system to be accepted by the automotive engineer user community, the pre-processing phase of the simulation process must not significantly exceed the level of difficulty and time-intensiveness of existing widely used non-Grid enabled CFD packages.


The time-intensiveness aspect of the above statement can be expressed in more specific terms of user wait-time for some common user actions:

  1. specification/application of a boundary condition 30 seconds
  2. manual modification of the mesh (refinement of 5% of domain) 15 minutes
  3. definition of a cut plane or sampling curve 1 minute
  4. 2-D results extraction (contour plot on an existing planar surface) 30 seconds
  5. 1-D results extraction (X-Y plot of data sampled along an existing line within the 3-D domain) 15 seconds


Accuracy


The nature of the automotive test case provides very well defined inflow/outflow locations separated by long domain regions. It is significant to conserve the mass flow over the extent of these typically long domains. Consequently, a basic check of accuracy and/or solution convergence can be the satisfaction of global mass conservation. It is expected that the net mass defect between inlet and outlet should be below 10-4 of the exhaust mass flow rate at the system inlet.


Extension of modelling capability: user-supplied models


The current automotive test case represents a class of engineering problems for which the flow solution is an intermediate result required for accurate application of other physical models. Additionally, the application specific physical models tend to be the result of internal development of the organisation applying them and, hence, proprietary. Coupling of these physical models with the flow solver would require either a) direct bilateral collaboration between customer and CFD software vendor within a confidentiality agreement or b) the interface facility for end-user integration.


For the sector represented by the current automotive end-user test case, it would be a significant boost to the market penetration potential of FlowGrid if there is the facility for the user to couple to the flow code certain types of add-on physical models. While this is a commonly encountered feature of non-Grid enabled commercial CFD codes, the implementation of such a facility is further complicated in a super-parallel environment and it is excessive to expect a fully market-ready implementation of such a feature in a pre-production flow code. Therefore, for the purposes of evaluation, the success criterion within the context of the FlowGrid project is defined by the integration of the physicochemical models supplied by CERTH/CPERI for the after-treatment components subject to the conditions:

  1. the CERTH/CPERI model code remains separate (until the object code stage) and numerical source code sharing (beyond interface header files) is not required for succesful interfacing,
  2. the CERTH/CPERI model code has access to the necessary flow solver solution variables through facilitites (pointers, macros, etc.) provided and documented by the flow solver developer,
  3. the simulation results obtained through the combined use of the FlowGrid flow solver and the provided sub-models compare favourably with the experimental data provided or with the results of identical (in boundary conditions and physical models) simulations performed with a third-party flow solver.


The first two of the above conditions ensure the required degree of code confidentiality and establish that the basis for future provision of user-extensibility of modelling capability has been designed into the code. Condition (c) is a measure of success of the current (pilot) implementation but does not evaluate only the FlowGrid system and the user-extensibility aspect since it depends on the quality of the experimental data and the validity of the physicochemical models in question. While the latter has been shown independently in the past assuming less detailed flow fields, it is only fair to isolate this aspect and so the fallback clause involving a third party flow solver is included.


 

Copyright © 2004 FlowGrid Consortium | Please send questions or comments to Norberto.Fueyo@posta.unizar.es, or to any other FlowGrid partner | Last modified on 02/04/2004