STAR-CD中的动网格计算
Moving Mesh in STAR-CDIntroduction
An important class of problems in engineering fluid dynamics is that of fluid motion caused by, or regulated by the motion of a solid body in contact with the fluid. Examples include systems such as turbomachinery, piston engines, mixing devices, and moving valves. Many of these systems include sufficient boundary motion that the interior fluid volume can vary significantly.
The simulation of internal combustion engines falls squarely into this category. As the piston goes from bottom to top dead center, the cylinder height may change by almost a factor of 100. Some special techniques are needed to deal with this large change of computational volume
STAR-CD allows for changing flow domains in two ways. For small scale motion, the vertex positions can be moved and the interior mesh smoothed at each time. STAR-CD uses a "space conservation" algorithm to accurately account for all the fluxes generated by the mesh movement, including mesh movement in the normal direction to the boundaries.
For larger scale motion, various connectivity change options are offered. In particular, cell layers may be collapsed when the volume is compressing, and expanded as required. Conceptually, the cell is squeezed to zero volume over one time step, with all its contents (mass, momentum, enthalpy etc) being expelled into its neighbours. Thus conservation is satisfied exactly even with cell layer removal (no interpolation). Conversly, when cell layers are added, they grow to their full volume from zero size, absorbing the conserved variables through their faces.
This article will give you a quick tour of the available features. More detailed instructions for setting up models are in the user guide (Chapter 14).
Moving Mesh
STAR-CD implements various moving mesh operations which allow both the topology and geometry of the mesh to be varied:
• Geometric variation - The vertex coordinates of mesh change. This can be accomplished by
o The user subroutine NEWXYZ called at every time step
o An external program spawned by STAR. Currently, PROSTAR and PROICE can understand and communicate with STAR-CD, although, in principle, interfaces can be developed for any mesher.
• Topology or Connectivity variation, where the cell neighbours change.
Mesh connectivity changes occur in discrete steps called events i.e. The mesh connectivity at any time step can be derived from the mesh connectivity at the previous time step by a sequence of operations. An Example
To illustrate these concepts before we get bogged down in the details of the events, we use the following example from tutorial 13. The serious user is strongly advised to read this tutorial fully, and try it!
The model is a 2d slice through a engine (with floating valves!), shown here with both valves shut, and the piston at bottom dead center. As the piston moves up on the exhaust stroke, the exhast valve pops open to expell the contents.
Comparing these two figures, you can see some of the processes occuring. For one thing, the geometry of the domain is changing. This is accomplished by changing the vertex coordinates at each time step. More importantly, the number of cell layers in the cylinder has decreased, keeping the resolution in the cylinder area similar as the piston moves up. New cells are added above the exhaust valve, and old cells are removed below it, to "move" the valve down. Also, two of the three unconnected segments (exhaust port and cylinder) are now connected together, sharing the same pressure reference.
The motion of the valve needs more explanation. New cells cannot be created during the run. All cells that are ever needed must exist before the analysis is begun. So the initial mesh in the region of the valve actually looks like this: (Valve and port have been moved up for clarity)
At the start of the analysis, all the cells on the top of the valve are collapsed to close the valve. The valve is then opened by adding a cell layer on the top and collapsing one from the bottom.
Now that we have some idea of what is involved, it is time to discuss the concepts in a slightly more formal manner ..
[ 本帖最后由 linda 于 2007-4-5 06:57 编辑 ] Events
An Event consists of a collection of elementary mesh operations which occur at a given point in time. Events are classified into three categories, Absolute Events, Conditional Events and Sliding Events.
• Absolute events occur at a predefined time. Each such event can have the a number of Elementary operations contained within, which are all executed when the solution time crosses the event time.
• Conditional events occur when released by a user subroutine, typically based upon the flow conditions. Only three elementary operations: ATTACH, DETACH and CHANGE FLUID are allowed in conditional events
Conditional events must be Enabled by an absolute event before they are active. The user subroutine is then repeatedly called until the conditional event is either executed, or is Disabled by another absolute event
• Sliding events resemble Conditional events in that they need to be enabled by an absolute event. After that point, they remain continuously active. Sliding events consist of only one elementary event type: the arbitrary attach. The event defines the master and slave faces; At each time step, while the sliding event is active, these faces are rematched by STAR based upon the current vertex positions.
Elementary operations
As discussed, Events consist of elementary mesh operations. It must be emphasized that these operations (except the EGRID operation) only change the connectivity, not the vertex locations. For instance, deactivating a cell layer will leave a "hole" in the model unless the vertices of the surviving cells are moved. The following operations are defined in STAR-CD
• Cell Layer Deactivation (EDCELL) and Activation (EACELL)
In the case of cell layer deactivation, an entire layer of cells can be collapsed in a given direction. The original neighbours of the cell in the direction of collapse are directly attached to each other, so that this cell drops out of the model. Two adjacent layers cannot be collapsed at the same time step.
Cell layers previously deactivated can be reactivated by the Activation event. These cells reappear with the neighbours that they had at the time of deactivation.
• Cell Attachment (EATTACH) and Detachment (EDETACH)
Cell attachment specifies a set of boundary couples that should be treated as attached. These boundaries must belong to regions of type ATTACH. Once a boundary pair is attached, it remains attached until it is explicitly detached, one of the pair is reattached to another boundary, or one of the partner cells is deactivated. Any unattached boundaries of type ATTACH are assumed to belong to the WALL region number specified in the region definition.
Cell detachment specifies a boundary of type ATTACH to be detached i.e. connected to the appropriate wall region. If this boundary is currently connected, the other side is also implicitly detached.
• Cell Exclusion (EECELL)and Cell Inclusion(EICELL)
Cell exclusion specifies a list of cells which will no longer be solved for. Unlike the Deactivation operation, these cells need not represent one layer. However, the excluded cells should not have any connections to active cells ie. only a separated block of cells can be excluded (Eg. the intake port and manifold after the intake valve closes).
Cells previously excluded can be brought into the solution again using the Include event. The solution field in these cells can be reinitialized, or restored to the situation at the time of their exclusion.
• Cell Fluid Stream Change
Specifies a list of cells to be changed to a different fluid stream (i.e. material type). This would become necessary if a series of cell DETACHMENTS created isolated regions of the domain which are not connected to the pressure reference cell.
• Conditional Event Enable and Disable
These operations allow conditional events to be enabled/disabled. While the conditional event is enabled, a user subroutine is called at each time step to check if the conditional event is to be executed. The conditional event is automatically disabled after it is executed.
A conditional event disable command is used to disable a conditional event, and is ignored if the conditional event is not currently enabled.
• Sliding Event Enable and Disable
These operations allow sliding events to be enabled/disabled.
Once a sliding event is enabled, the corresponding faces are rematched by STAR at each time step. This continues even if there are no more events ie. even after the events file is closed
The sliding event disable operation is only needed if the attached faces are to be detached (eg. a valve closes). The detached faces are then treated as the wall region defined in the attach boundar region definition.
• Change Geometry (EGRID)
This operation specifies a list of PROSTAR commands which will be executed at each time step from this point on. More than one absolute event may contain an EGRID operation, in which case the latest set of PROSTAR commands will be used. Note that this is the only elementary operation that results in the vertices being moved. Vertex Motion Using PROSTAR
As we have repeatedly stressed, setting up the events only changes the connectivity of the mesh. The other half of the story is obtaining the vertex positions corresponding to this new topology
The EGRID operation provides the key to this. Before we consider the EGRID commands, it is important to realize the context or environment in which they will be called upon to perform. During the transient run, STAR calls PROSTAR at each time step (before solving any of the governing equations) to set up the current mesh. Thus by the time these commands need to be executed, the events file (with all the events) has been completely created. This means that some of the events can be used to generate the mesh (by using the events processing features in PROSTAR).
In addition, STAR provides certain built in variables which are updated at each time step.
• ITER : The current time stepnumber.
• TIME : The current solution time.
• LSTP : The currentload step.
• EVEX : The event number last executed.
• EVNO : Theevent number waiting to be executed.
• ETIM : The time at which thenext event is scheduled.
These can be used to create general commands to generate the mesh at any time. Advanced users may create their own parameters using the user subroutine UPARM as documented in the manual. Note that parameters saved in the .mdl file will not be available at this time.
All the normal PROSTAR commands are available in this mode. However, it is not trivial to build the moving mesh commands to work over the entire range of engine motion. The example in tutorial 13 gives many hints and strategies, and is strongly recommended.
Enter PROICE
As we have noted, setting up a full moving mesh analysis is a hard and error prone task. PROICE simplifies many aspects of setting up and running these models. The next two articles in this series discuss PROICE in greater detail 好好好,可惜都是英语的饿:@L 不错，fluent中的dynamic mesh功能也是很不错的，各有特点
页:
[1]