ASAP is an abbreviation for:
Arbitrary Source (or Solid) Allocation Procedure.
It is an add-on to PHOENICS which permits sources and solid objects to be placed within pre-defined grids, their presence being signalled by the attachment of the corresponding fluxes and material-property values to the appropriate cells.
ASAP therefore allows the user to set up his flow-simulation problems wholly in geometrical terms, without considering the grid.
The paper describes the basic theory in genral terms, and the method of setting up problems in more detail.
Examples of the use of ASAP are then presented, ranging in complexity from a simple cylinder to a Formula-1 racing car.
The prospects and plans for the further development of ASAP are discussed.
Now that computational fluid dynamics has become an accepted tool of engineering and science, the flow-simulation problems which its users attempt to solve become more and more complex.
Quite apart from the complexities associated with the physical and chemical processes involved, the geometrical shapes of the boundaries of the flow domain, and of solid objects placed within that domain, become ever more complex.
Further, the flow-determining sources of mass, momentum and energy may be defined in complicated ways.
A realistic example exhibiting these complexities is that of a fire-fighting vehicle, moving among blazing buildings and projecting jets of water in continuously-changing directions. Other examples are:-
Such flow-simulation tasks are often attempted with the aid of moving body-fitted coordinates; but this approach is attended by considerable difficulties, and there is no general-purpose computer code which is currently able to solve them routinely.
ASAP has been devised so as to enable the general-purpose PHOENICS code to simulate flows of great complexity as easily as simple ones.
ASAP is a software package which transfers information about the presence of sources and solids into the cell-wise-organised data structure of PHOENICS, without the user's having to be aware of that structure.
The grid can indeed be a cartesian one, the fineness of which the user can certainly control; but he concerns himself only with the construction of the objects and sources which constitute his physical problem. ASAP does the rest.
The objects are constructed from a sufficiently (for the time being) varied set of elementary shapes and materials, the selection, sizing and location of which are the user's main tasks.
He is helped in the performance of this task by an interactive graphical package, based on but differing from PHOTON.
Of course, the accuracy with which PHOENICS simulates the phenomenon will depend on the fineness of the grid which is used; and it may well be that ASAP will need a larger number of cells to achieve a given accuracy than a well-designed body-fitted-coordinate grid.
However, the man-time and computer-time required for the creation of such a BFC grid are often great; and cartesian-grid computations are usually faster and less memory-intensive than BFC ones.
It may therefore often be the case that the balance of advantage lies with the conceptually and practically simpler ASAP approach.
ASAP was first conceived (by the first author) and implemented (by the second author) early in 1995. Since that time it has, been used successfully in several highly-demanding consultancy tasks.
CHAM's judgement is therefore that the technique is sufficiently well-proven to be generally released.
In the remainder of the paper, section 2 explains how ASAP works, in general terms, and then focusses attention on the aspects which most concern the user, namely:
The last topic is by far the most important; therefore its principles are explained in some detail.
In the interests of brevity, however, the fully exhaustive treatment of this file and its syntax is relegated to Appendix 1.
Section 3 then introduces some applications of ASAP. Two of them, namely the cylinder in cross-flow and the Tee-junction, are rather simple. The last three however exbibit considerable complexity.
The user is required to describe the solid objects and their associated sources in terms of their locations in Cartesian space, and the magnitudes of their quantitative attributes.
He does this by creating a GEOMDA file which contains details of the objects and then attaches this GEOMDA file to the bottom of the Q1 file. The detail of how to attach the GEOMDA file to the Q1 file will be explained in Section 2.4 below. The geometry data in the Q1 file are read by the ASAP attachment to EARTH, which converts the information into the grid-related terms understood by PHOENICS.
The reading of geometry data, and the allocation of the necessary storage, are effected in Group 1, Section 1 of the special GROUND, GXASAP, via :
CALL CRTOBJ CALL SRCIDX
Then a call to ASAPZZ is made in Group 11, whereafter EARTH performs the simulation in the usual way.
When, as is usual for ASAP, the chosen grid is either Cartesian or cylindrical polar, the task of transferring the source-and-solids data from the user's geometrically-organised description to the PHOENICS grid-based one is exceptionally easy.
The IX, IY and IZ (or I,J,K) indices of the cells can then be expressed explicitly in terms of the x, y and z in which the data are expressed.
All that is necessary is for the program to break the solids and sources into sufficiently small fragments and then to "project" them into the PHOENICS grid, where they contribute to the blockage of the cells, when solids are in question, and to the sources of the appropriate PHOENICS variables.
These operations are however performed out of the user's sight.
ASAP is activated by including in the Q1 file a patch called QSOLID, which extends over the whole domain of simulation, by means of the following commands:
PATCH(QSOLID, INIVAL, 1, NX, 1, NY, 1, NZ, 1, 1) COVAL(QSOLID, PRPS, 0.0, GRND)
The creation of this patch activates ASAP during the EARTH run, and causes the GEOMDA file to be read.
In the future, the simple command
ASAP=T
will be made to suffice for all ASAP-related Q1 settings; and probably the GEOMDA data will be read from Q1 itself.
The other entries in the Q1 file are conventional. In particular, the grid which is to be used, and what variables are to be solved for, are defined there.
The value of INIADD should be set to F (ie false), whenever, as in most cases, the main function of ASAP is to provide a distribution of the variable PRPS.
ASAP is used solely to fit geometrical objects and associated sources into the grid, thereby performing tasks which would otherwise be done by Group 11 and Group 13 commands.
The description of the solids and sources which are to be placed in the grid must be supplied in a file called GEOMDA. This must reside in the working directory.
The GEOMDA file is the main focus of attention of the user of ASAP. It will therefore be extensively explained and exemplified below.
In order to be able to read the GEOMDA file, and to create the corresponding distributions of solids and sources within the grid, the EARTH executable must contain a special GROUND.OBJ containing the sub-routine calls mentioned above, and a special library called ASAPLB.OBJ.
This special library contains an interactive-graphical-display feature, based upon PHOTON but different from it, which enables the objects and the flow to be clearly visualized.
When ASAPLB.OBJ has done its work, if the introduction of solid objects is in question, the result is a three-dimensional array of values of the variable PRPS. That is all; and of course the same information could be conveyed to EARTH from a phi file in a restart run.
If it is sources which are to be conveyed, the result of ASAP's work is the filling of a three-dimensional array of sources of the variable in question. This is an array which does not ordinarily find a place in PHOENICS, except in the GENTRA option.
All ASAP sources are, at the present time, of the fixed-flux variety. Linearised sources could be introduced, if the need arose, as could sources of a more complex kind, for example those which depend on several local variables.
Formulae for these sources could be introduced in a PLANT-like manner; but this has not yet been done.
The GEOMDA file is an ASCII file, which can be created by means of any editor or word-processor.
Two such files are shown, in sections 3.1 and 3.2 respectively. The first relates to a cylinder, and the second to a Tee-junction. They are both short, and, once a few simple rules have been recognised, easy to understand.
The language of ASAP has very few words of its own; they are, in alphabetical order:
| AERO-FOIL | BOX | CHAIN | CONE | CONSTANT | COORDINATE | CYLINDER |
| ELLIPSOID | END | END-OF-GROUP | :EOF | FIRST-CHAIN | GROUP | POINT-SOURCE |
| POLY-PIPE | POLY-SURFACE | PROPERTY | SOLID |
These words are refered to as key-words. All are fully explained in Apendix 1.
Not all key-words are used in every file. Thus, the file of section 3.1 uses only:
COORDINATE
CYLINDER
END-OF-GROUP
:EOF GROUP PROPERTY;
while that of section 3.2 uses additionally: BOX CONSTANT END END-OF-GROUP POLY-SURFACE.
However non-ASAP words, ie those introduced by the user, are also to be found. They are of three kinds, namely:-
ASAP is not case-sensitive; but it is useful to adopt the convention that words to which ASAP responds are upper case, while comments are lower case.
Blank lines may be inserted in GEOMDA files without having any effect.
Every line which is neither blank nor a comment must be complete in itslf; continuation from one line to the next is not permitted.
Indentation is significant to ASAP. When it occurs, as in the GEOMDA of section 3.2, the rule is always: move four spaces left or right.
Most ASAP-readable lines are of the form:
key-word, followed by a sequence of numbers
However, any number may be replaced by a previously-declared constant; and the GROUP key-word is followed by a user-chosen name.
At present, eight classes of object are available. They are:
Object class |
ASAP keyword |
| rectangular boxes, aligned with the grid | BOX |
| circular-sectioned cylinders | CYLINDER |
| elliptical-sectioned cones, which may be truncated | CONE |
| ellipsoids | ELLIPSOID |
| cylinders of arbitrary uniform cross-section | AERO-FOIL |
| arbitrary 3D shapes | SOLID |
| pipes (of any cross-section) with bends | POLY-PIPE |
| point source of mass, momentum, energy, etc | POINT-SOURCE |
The key-word must be followed by the numbers 1 or 2, according to whether the PROPERTY value is to be applied inside or outside the surface of the object. The number is called the type of the object.
What material is to be associated with the object, whether inside or outside its surface, is indicated by the number following the preceding PROPERTY key-word. These numbers correspnd to the values of the PHOENICS variables PRPS, to be found in the PROPS file.
Thus, in the GEOMDA files of sections 3.1 and 3.2, PROPERTY 111 signifies that the material is steel.
In the visual display, distinct colours are associated with each material. That of steel is blue. [Note: The colour-to-materials associations are currently fixed by an inaccessible data statement. This will be changed.]
The PROPERTY value governs all objects below it in the GEOMDA file, until the next PROPERTY line is reached.
It is often convenient to replace numbers by names of variables, eg HEIGHT, as in the section 3.2 GEOMDA.
The variables need to be first declared, and assigned values, by lines beginning with the keyword CONSTANT.
Thus PROPERTY 111 could be replaced by
CONSTANT STEEL = 111
PROPERTY STEEL
Further details of this, and all other features of the ASAP language used in GEOMDA files, are fully described in Appendix 1. No further explanations will be provided in the body of the text.
The GEOMDA file described above can be read directly by the ASAP. However, it is strongly recommended that the GEOMDA file created is attached to the corresponding Q1 file. The advantages of this practice are twofold: a) GEOMDA files will never be mixed up with irrelevant Q1 files; b) this enables the user to create a ASAP library which contains both the PIL settings and the geometry data for each case. To attach a GEOMDA file to the corresponding Q1 file, the user should:
An example of the Q1 file can be found in Appendix 1.
To enable the user to view quickly the geometry which he has created, an interactive-graphics feature has been supplied within the ASAP option.
This is activated via the graphical-monitor option (TSTSWP= -1) of PHOENICS, which offers a PHOTON button among the other interrupt options.
This allows the geometry to be inspected and velocity vectors (but not yet contours) to be drawn.
An example is shown below, in secton 3.2.
The ASAP has been attached to PHOENICS as an option.
All the files related to EARTH attachment are in the directory D_EARTH/D_OPT/D_ASAP and the ASAP library, ASALIBDA.UDA is included in the directory D_SATELL/D_OPT/D_ASAP.
The special GROUND, GXASAP is called from GREX3 when NAMGRD is set to ASAP in the Q1 file.
There are four cases in the ASAP library. They are: T-Junction case 100 Ink-Jet case 101 Soaking pit case 102 Drill bit case 103
To run a library case, the user should follow the steps described below: runsat type m to activate the top menu panel select library option from the menu panel select ASAP library select load option and enter case number select 'end' to save the Q1 file and quit the SATELLITE runear
During execution of EARTH, the user can view the geometry and velocity vectors as described in Section 2.6.
The GEOMDA file for this case is extremely simple because there is only one object to be introduced, namely the cylinder. It is as follows:
COORDINATE 1.0 -0.5 0.0
PROPERTY 111
GROUP THE-CYLINDER 0.0 0.0 0.0 1.0 1.0 1.0
CYLINDER 1 0.5 0.5 0.0 0.5 0.5 1.0 1.0 2 2
END-OF-GROUP
:EOF
Computed results now follow.
The computed results appear to be rather satisfactory, the length of recirculation being around 2.0, whereas experimental data for this Reynolds Number may be somewhat larger.
No comprehensive study of the accuracy attainable has been made however.
A vertical pipe joins a horizontal ---------------------------
pipe from below. Both are |/////////////////////////|
represented as hollow cylinders ---------------------------
within a rectangular steel block. <--->
----------- ^ -----------
The Q1 file is supplied as |/////////| | |/////////|
Appendix 2. ----------| |----------
The GEOMDA file for this case is longer than that of the cylinder, because there are three objects to introduce. Note that one of them, the box, is of type 1 (ie solid is inside), while the others, namely the cylinders, are of type 2 (ie solid lies outside).
Explanatory comments are included.
// Declaration of variables used in this file // box height horizontal half horiz box // pipe diam pipe length thickness CONSTANT HEIGHT=1.5 HORPIPDI=1.0 HALFHOPILN=1.5 THICK=0.6 // vertical pipe twice y coordinate // diameter verpipdi of horiz. pipe // centre-line CONSTANT VERPIPDI=0.8 TWVEPIDI=1.6 YHCL=1.0
// Note that, because ASAP language is (unlike PIL) not yet able to
// interpret
arithmetic expressions, both diameter and twice-diameter // must be assigned by the user.
// x,y & z of origin of local coordinate system of following objects COORDINATE THICK 0.0 HALFHOPILN
// 111 is steel, the colour of which is blue in the visual display PROPERTY 111
//
Group is a flag indicating the elements grouped to form a geometry
// Name and oordinates
of bounding-box corners are:
// group name x1 y1 z1 x2 y2 z2 GROUP T-JUNCTION -THICK 0.0
-HALFHOPILN 0.0 1.5 HALFHOPILN
POLY-SURFACE
// Two points to define a BOX. The 1 means material set by
// PROPERTY is
INside
// Coordinates of bounding-box corners are the same as for GROUP BOX 1 -THICK 0.0
-HALFHOPILN 0.0 1.5 HALFHOPILN
// 102 for brick colour is red PROPERTY 102
// Class of object is CYLINDER. Type = 2 means material is OUTside
// type x1 y1 z1 x2
y2 z2 diameter
// open ends
// vertical cylinder CYLINDER 2 0.0 0.0 0.0 0.0 YHCL 0.0
VERPIPDI 1 1
// horizontal cylinder CYLINDER 2 0.0 YHCL -TWVEPIDI 0.0 YHCL TWVEPIDI
HORPIPDI 1 1 END END-OF-GROUP :EOF
Some computed results now follow.
A picture from the interactive viewer
Velocity vectors
A picture from PHOTON
Pressure contours
This simulation represents a real-life industrial problem.
The GEOMDA file for this case comprised 37 objects.
The file was 650 lines long.
The data were obtained, manually, from an AUTOCAD file, because automatic data transfer has not yet been effected.
The grid was 54 * 54 * 25.
The k-epsilon turbulence model was employed.
No comparison with experimental data is available.
/phoenics/d_polis/d_enc/d_pcx/bit_1
/phoenics/d_polis/d_enc/d_pcx/bit_2
Velocity vectors at a cross section
The GEOMDA file for this case comprised 44 objects.
The file was about 1000 lines long.
The grid size was 50 * 55 * 208
The k-epsilon turbulence model was employed.
No comparisons with experimental data have been made.
/phoenics/d_polis/d_enc/d_pcx/car1
/phoenics/d_polis/d_enc/d_pcx/car2
/phoenics/d_polis/d_enc/d_pcx/car3
Finally, an example in which there are sourcs of mass and momentum:
A gas cooker is supposed to be injecting unignited gas into a room.
Fortunately, it is close to a ventilator. The question is: will the gas be withdrawn with sufficient rapidity.
The study is not complete, from the engineering point of view; but the pictures will show what ASAP can do.
Approximately half a man-day was used in setting the problem up. The room, the cooker and the ventilator
/phoenics/d_polis/d_enc/d_pcx/room
The gas concentrations near the top of the cooker
ASAP has produced some excellent flow simulations (many more than have been shown here). CHAM thereore intends to develop it further.
Among the envisaged improvements are:
Curved solid-fluid boundaries are currently represented by ASAP in a step-wise manner, because all cells must be either fully blocked by solid or fully open to fluid. For this reason, accurate representation of the flow requires the use of rather fine grids.
It is possible to introduce into PHOENICS special solid-fluid boundary conditions, by extending the EGWF (Earth-Generated-Wall- Function) feature.
Whether or not this will be done depends on the speed with which new X-Cell algorithm of PHOENICS is developed. Probably X-Cell will advance with sufficient rapidity to rendered further adaptations of ASAP to staggered grids unnecessary.
Reference 1 describes the X-Cell feature, of which all that need be stated here is that it currently employs a cartesian grid subdivided by diagonals. Each rectangular cell therefore contains four triangular cells, in two dimensions, or six pyramidal cells in three dimensions.
This arrangement renders the acurate representation of curved solid-fluid interfaces much easier, because the fluid can lie on one side of a diagonal while the solid lies on the other.
In order to exploit X-Cell, ASAP will need to employ a somewhat different search procedure: instead of asking which rectangular cell a solid particle lies in, it must find out which CORNER of the cell it occupies.
There appears to be no difficulty of principle or practice in the way of this development.
As described above, ASAP placs solids and sources as well as it can in a pre-defined grid, and then immediately initiates the flow- simulation calculation.
However, it will often prove advisable to introduce a grid- adaptation and -refinement stage before the said calculation starts.
What is necessary is to compute the extent to which the solids as represented by blocked cells fail quite to conform to the objects defined by GEOMDA, and then to shift grid coordinates (while still retaining their cartesian nature) or to introduce new cells in the best possible places, so as to reduce the error. (b) Development of an object library and the link with PHOENICS-VR
A modern tendency in applied computational fluid dynamics is to keep the mechanics of the simulation process hidden from the user.
The user will take responsibility for defining the situations to be simulated, and for interpreting and assessing the results; but he will require the simulation itself to proceed automatically, economically, and with good quality control.
ASAP is wholly compatible with this tendency; but its dependence on the editing of the GEOMDA file, at the present time, imposes a requirement which not all users will meet.
Fortunately, it is also compatible with the object-oriented reality- focussed style of the PHOENICS Virtual-Reality Front End; for the latter placs objects in space; the former (ASAP) implants them in the grid.
What is therefore needed is an invisible link: the GEOMDA file must automatically result from the VR-user's specification.
ASAP has proved to be a robust and easy-to-use device for introducing complex geometrical and source data into PHOENICS.
Its great merit is that it can work which cartesian grids, and that the user is spared the task of adapting even these to the input data.
Its disadvantages are that, for a fixed number of cells, it is likely to give less accurate solutions than those obtainable from body-fitted-coordinate grids.
Two kinds of improvement are foreseen, namely:
Geometrical information to be used by ASAP is stored in a formatted data file called GEOMDA. The data in this file are organised in terms of both format and key-words.
All key-words or data items are separated by space(s).
There is no distinction between real, integer or character variables, the type of a particular data item being determined by the format of the statement containing the data.
A typical GEOMDA file has the following format:
// [comments-1]
CONSTANT name1=[value1] name2=[value2] ...
COORDINATE [x y z]
PROPERTY [PRPS index]
GROUP [group1-name] [x0 y0 z0 x1 y1 z1]
BOX [type] [x0b y0b z0b x1b y1b z1b]
CYLINDER [type] [x0c y0c z0c x1c y1c z1c] [D]
END-OF-GROUP
// [comments-2]
GROUP [group2-name] [x2 y2 z2 x3 y3 z3]
BOX [type] [x2b y2b z2b x3b y3b z3b]
POLY-SURFACES CONE [type] [x11 y11 z11] [x12 y12 z12]
[x13 y13 z13] [x21 y21 z21] [x22 y22 z22] [x23 y23 z23]
SOLID [type]
FIRST-CHAIN [xf1 yf1 zf1] [xf2 yf2 zf2]
Chai1n [xcn1 ycn1 zcn1] [xcn2 ycn2 zcn2]
END
END
END-OF-GROUP
:EOF
Items in the square brackets are values specifying the geometry.
Any line starting with double slash "//" is treated as a comment.
Comment lines can appear anywhere in the file.
No continuation line is permitted.
The rule for indentation is shifting four spaces right for each sub-object.
CONSTANT name1=[value1] name2=[value2] ...
This statement assigns numerical values to character names.
Names are character strings up to 10 characters long and value1, value2, etc are numerical constants.
Once a name has been assigned a value in a CONSTANT statement, it can be used to represent that value anywhere in the file. The basic co-ordinate system in ASAP is the co-ordinate system used in creating the mesh system. Each ASAP object can have its own co-ordinate system, which is convenient but not essential.
COORDINATE [x y z]
The three real numbers in the bracket define the origin of the local coordinate system.
Subsequent geometry elements are all defined in this local coordinate system until another coordinate statement redefines it.
The coordinate statement can appear before any geometry element or group (see later) statement but not within the definition of a geometry element.
The default coordinate system is the one used in other parts of PHOENICS.
PROPERTY [PRPS index]
This statement assigns the PRPS index value to all subsequent geometry elements until being redefined by another PROPERTY statement.
Like the COORDINATE statement, the PROPERTY statement can be put anywhere in the file except within the definition of a geometry element.
GROUP [group-name] [x0 y0 z0 x1 y1 z1]
........
END-OF-GROUP
All geometry elements in the GEOMDA file are grouped as the user chooses.
The group-name is a character string with no space in it.
Six numbers define a Cartesian bounding box. The first 3 indicate x, y and z of the west-south-low corner; and the last 3 indicate those of the east-north-high corner of the cube.
Any geometry element or part of it falling outside this box will be discarded by ASAP.
The group statement should always be matched by an end-of-group statement.
The default box is the entire computational domain.
BOX [type] [x0b y0b z0b x1b y1b z1b]
This statement defines a Cartesian six-sided rectangular surface.
There are two types of geometry elements:
This is true not only for BOX but for all other geometry elements.
The six numbers in the second bracket define the box by its corners, in exactly the same way as in the group statement.
| ELLIPSOID | [type] | [xe1 ye1 ze1] | [xe2 ye2 ze2] | |
| [xe3 ye3 ze3] | [xe4 ye4 ze4] |
This statement defines an ellipsoid (of which class a sphere is a special case) having the centre at [xe1 ye1 ze1] and three axes defined by the three vectors [xe2 ye2 ze2] [xe3 ye3 ze3] and [xe4 ye4 ze4].
Both the directions and the lengths of the vectors are read by ASAP.
If the user has inadvertently specified non-orthogonal directions, ASAP will modify these by taking the first vector as correct, the second as defining only its length and the surface in which it lies, and the third as defining only its length. CONE is a truncated cone that has a top and a bottom. One of them can have effectively zero area.
| CONE | [type] | ||
| [x11 y11 z11] | [x12 y12 z12] | [x13 y13 z13] | |
| [x21 y21 z21] | [x22 y22 z22] | [x23 y23 z23] |
The description of a CONE occupies three lines.
The second line defines the top plane of the cone, as follows:
In the case of circular-sectiond cone, the two vectors should have equal lengths.
The third line has exactly the same meaning as the second line but for the bottom of the cone.
CYLINDER [type] [x0c y0c z0c] [x1c y1c z1c] [D]
This object class comprises cylinders of circular cross-section, each defined by the two ends of its axis, [x0c y0c z0c] & [x1c y1c z1c], and by its diameter D.
Cylinders of more general cross-section are handled in the AERO-FOIL object class.
AERO-FOIL [type] [x0c y0c z0c] [x1c y1c z1c]
[xf1 yf1 zf1]
[xf2 yf2 zf2]
........
END
An AERO-FOIL is defined here as a cylinder with arbitrary cross section.
The description of an AERO-FOIL requires more than one line. The exact number of lines depends on the number of points [xfi yfi zfi] given to describe the shape.
An END statement is used to complete the data input for the aero-foil.
[x0c y0c z0c] and [x1c y1c z1c] define the ends of the axis of the aero-foil.
A poly-pipe is defined as a collection of cylinders with the same diameter and joined axes.
POLY-PIPE [type] [D]
[xf1 yf1 zf1]
[xf2 yf2 zf2]
........
END
Here D is the diameter of the pipe and the points [xfi yfi zfi] and [xf2 yf2 zf2] describe the centre-line of the pipe.
SOLID [type]
FIRST-CHAIN
[xf1 yf1 zf1]
[xf2 yf2 zf2]
........
CHAIN
[xcn1 ycn1 zcn1]
[xcn2 ycn2 zcn2]
.......
END
END
SOLID is the most general type of geometry element. In principle, any geometry can be create by using SOLID only.
However, in practice, building complex geometry with SOLID only can be very inefficient.
A SOLID is a hexahedral enclosed by 6 plane surfaces.
Each CHAIN defines a closed 3_D poly-line. All CHAINs contain the same number of points.
The rule here is that all lines linking 2 corresponding points belong to two neighbouring CHAINs are on the surface of the solid.
FIRST-CHAIN here is not different from other CHAIN statements except that the name marks the beginning of data input for SOLID geometry.
POINT-SOURCE is an object of a different kind from the others: it causes the introduction into the field of a source of momentum (in any of three cartesian directions), of mass, or of energy, at a defined point in space.
The syntax is:
POINT-SOURCE [npoints] [x y z] [uc vc wc] [m] [temp]
------------------------------------------End of Appendix-1 ------------
Q1 file with the GEOMDA file attached
for Flow in a T-junction
----------------------------------------------
TALK=T;RUN( 1, 1);VDU=VGAMOUSE
lsg60=f
************************************************************
Group 1. Run Title
TEXT(T-Junction )
************************************************************
Group 2. Transience
* Set overall time and no. of steps
RSET(U,0.000E+00,1.000E+02,100)
* Modify regions
spedat(set,material,111,l,t)
************************************************************
Groups 3, 4, 5 Grid Information
* Overall number of cells, RSET(M,NX,NY,NZ,tolerance)
RSET(M,12,20,30)
* Set overall domain extent:
* xulast yvlast zwlast name
XSI= 0.6;YSI= 1.5;ZSI= 3.0;RSET(D,CHAM )
Note:
If only a portion (half or quarter) of the geometry
is taken as the computational domain RSG2 should be set
accordingly otherwise set RSG2=1.
RSG2=0.5
************************************************************
Group 7. Variables: STOREd,SOLVEd,NAMEd
* Solved variables list
SOLVE(P1,U1,V1,W1)
* Stored variables list
STORE(PRPS,GEOMID)
* Additional solver options
SOLUTN(P1,Y,Y,Y,N,N,Y)
IVARBK=-1;ISOLBK=1
************************************************************
Group 8. Terms & Devices
NEWRH1=T; NEWENL=T
ISOLX=0;ISOLY=0;ISOLZ=0
************************************************************
Group 9. Properties
RHO1 = 1.0; ENUL = GRND10
************************************************************
Group 11.Initialise Var/Porosity Fields
FIINIT(PRPS)=1.000E+00
FIINIT(P1)=0.0; FIINIT(U1)=0.0
FIINIT(V1)=0.0; FIINIT(W1)=0.0
patch(init,inival,1,1,1,1,1,1,1,1)
coval(init,prps,0,111)
INIADD=F
************************************************************
Group 13. Boundary & Special Sources
Note:
After the geometry has been successfully adapted REST
should be True to avoid repeating the geometry adaptation
process.
PATCH(QSOLID, INIVAL, 1, NX, 1, NY, 1, NZ, 1, 1)
COVAL(QSOLID, PRPS, 0.0, GRND)
PATCH(INLET, SOUTH, 1, NX, 1, 1, 1, NZ, 1, 1)
COVAL(INLET, P1, FIXFLU, 1.0)
COVAL(INLET, V1, 0.0, 1.0)
PATCH(OUTLT1, LOW, 1, NX, 1, NY, 1, 1, 1, 1)
COVAL(OUTLT1, P1,FIXP, 0.0)
PATCH(OUTLT2, HIGH, 1, NX, 1, NY, NZ, NZ, 1, 1)
COVAL(OUTLT2, P1, FIXP, 0.0)
*********************************************************
*** Group 15. Terminate Sweeps
LSWEEP = 500; SELREF = F; RESFAC = 1.000E-03
*********************************************************
*** Group 16. Terminate Iterations
ENDIT (P1 ) = 1.000E-03 ;ENDIT (U1 ) = 1.000E-03
ENDIT (V1 ) = 1.000E-03 ;ENDIT(W1 ) = 1.000E-03
*********************************************************
*** Group 19. EARTH Calls To GROUND Station NAMGRD=ASAP
*********************************************************
*** Group 20. Preliminary Printout
ECHO = T
*********************************************************
*** Group 22.
Monitor Print-Out
TSTSWP = -1
IXMON=NX;IYMON=15;IZMON=15
cg(8)=Q1
// Declaration variables for used in this geometry data file constant
Hight=1.5 Diametr=1.0 Lhalf=1.5 Thick=0.6
// Coordinate flag is to set a reference origin
Coordinate
Thick 0.0
Lhalf
// Property flag only affects the geometry elements below it
// 111 is steel colour is blue
Property 111
// Group is a flag indicating 3 elements grouped to form a
// geometry in this case and it acts as
INIADD=F
Group T-Junction Thick 0.0 -Lhalf 0.0 1.5 Lhalf Poly-surface
// Two points to define a
BOX and Box 1 means Blocked, if 2
// unblocked Box 1 -Thick 0.0 -Lhalf 0.0 1.5 Lhalf
// 102 for brick colour is red
Property 102
// Cylinder 2 is not blocked (2 coordinates define the length
// of the central line, 0.8 is the diameter, both ends are open
Cylinder 2 0.0 0.0 0.0 0.0 1.0 0.0 0.8 1 1
Cylinder 2 0.0 1.0 -1.6 0.0 1.0 1.6 Diametr 1 1
END
END-OF-GROUP
:EOF
STOP
---------End of Appendix-2 ------------