Their positions and shapes are marked:
In-Form objects are created and defined by means of statements of the following format:
(INFOB at PATCHNAME is FORMULA with infob_OBJNAME!options)
Here:
Partly because this conflicted in style with the grid-independent setting of In-Form objects, a new kind of patch, the so-called 'dot-patch' has now been introduced.
This sets the location by way of real-number arguments: RXF, RXL, RYF, RYL, RZF, RZL, RTF, and RTL. These represent the geometric coordinates, normalised by reference to XULAST, YVLAST, ZWLAST and TLAST, of the eight faces of the space-time block within the In-Form object is to be found.
Such patches, which are marked by having a dot, ., as the first character of their names retain their positions when the grid is changed.
It is for this reason that the use of dot-patches is to be preferred ot those of the old indicial type.
(INITIAL of PRPS at PATCHNAME is 67. with infob_OBJNAME) (PROPERTY of RHO1 at PATCHNAME is 1.e-5*(P1+:PRESS0:) with infob_OBJNAME) (SOURCE of TEM1 at PATCHNAME is xg+yg with infob_OBJNAME)Thus the specific name of the object appears as an 'option' i.e. a 'modifier' of the source statement, Without it, the source would appear in all the cells of the patch.
It is however not necessarily the only one. For example, the above line could be modified to:
(SOURCE of TEM1 at PATCHNAME is xg+yg with infob_OBJNAME!fixval)or
(SOURCE of TEM1 at PATCHNAME is xg+yg with infob_OBJNAME!fixflu)If no additional option is added, the default !fixflu is presumed.
and
The arguments in question are as follows:
BOX(x0,y0,z0,xsize,ysize,zsize,alpha,beta,theta)
where
x0 = X-coordinate of west south low corner of box, in meters
y0 = Y-coordinate of west south low corner of box, in meters
z0 = Z-coordinate of west south low corner of box, in meters
xsize = X-size of box side, in meters
ysize = Y-size of box side, in meters
zsize = Z-size of box side, in meters
alpha = angle rotating around x axis, in radians
beta = angle rotating around y axis, in radians
theta = angle rotating around z axis, in radians
The six position and size arguments correspond to those which are used for VR-objects; but the three rotation arguments follow a different convention.
Library case 383 illustrates the use of the box function for the creation of a box in a cubical domain, with all its rotations equal to 0.25 radians, by means of the following statements:
inform11begin (stored of mark at patch1 is 1.0 with infob_1) ! MARK object (initial of prps is 100 with infob_1) ! initialise PRPS real(x0,y0,z0,xs,ys,zs,al,be,th) ! declarations x0=xulast/4 ! x/y/z position of box y0=yvlast/4 ! z0=zwlast/4 ! xs=xulast/2 ! x/y/z size of box ys=yvlast/2 ! zs=zwlast/2 ! al=0.25 ! alpha/beta/theta angles of coordinate system be=0.25 ! of box th=0.25 ! (infob at patch1 is box(x0,y0,z0,xs,ys,zs,al,be,th) with infob_1) inform11endHere, in order to make its shape and position visible in PHOTON and the VR VIEWER, the variable MARK has been stored and given the value of 1.0 for all the cells enclosed by the object.
It will be noticed that the often-convenient device is adopted of defining x0, y0, etc as real variables, and setting their values in statements which precede (INFOB ... .
In this case, the values are constants, which would not be difficult to
read if
inserted directly as:
BOX(:xulast/4:,:yvlast/4:, etc) ;
but, were
they long formulae, their
appearance following BOX( would make the line tiresomely long.
A PHOTON plot of the case-383 BOX object is shown here. It was created by the sur mark x 0.99 and sur mark y 0.99 commands.
In this example, each parameter is a constant; but each could have been a function, as will be illustrated in section (e) below.
It has only four arguments however, namely:
SPHERE(xc, yc, zc, radius)
where
xc = x coordinate of the centre, in meters
yc = y coordinate of the centre, in meters
zc = z coordinate of the centre, in meters
radius = radius of the sphere, in meters
because rotations about its centre cannot change its shape.
When the calculation is being carried out with a Cartesian grid, the coordinate system of the sphere coincides with the coordinate system of the calculation domain.
However, when the calculation is being carried out with a
cylindrical-polar-coordinate grid,
the cartesian coordinate system of the sphere has its origin at the bottom
left-hand corner of a rectangular box which circumscribes a cylinder of radius
RINNER+YVLAST.
In this case, cartesian coordinates xc and yc are related to the polar
coordinates xp and yp by the relations:
xc=(yvlast+rinner) + (yp + rinner) * sin(xp)
and
yc=(yvlast+rinner) + (yp + rinner) * cos(xp)
The Z coordinates of the origins and the directions of Z axes of both coordinate systems coincide with one another.
Library case
772
creates an In-Form object,
namely a sphere with its centre on the axis of a polar grid, by means
of:
(INFOB at PATCH1 is SPHERE(10, 10, 10, 5) with INFOB_1)
The PHOTON plot displayed here reveals the result.
In this case, it may be noted, xce, yce and zce are declared as character variables. This is the preferable procedure when the possible use of formulae as arguments is to be provided for.
The arguments in question are as follows:
ELLPSD(x0,y0,z0,xrad,yrad,zrad,alpha,beta,theta)
where
x0 = X-coordinate of the centre of the ellipsoid, in meters
y0 = Y-coordinate of the centre of the ellipsoid, in meters
z0 = Z-coordinate of the centre of the ellipsoid, in meters
xrad = X-direction radius, in meters
yrad = Y-direction radius, in meters
zrad = Z-direction radius, in meters
alpha = angle rotating around x axis, in radians
beta = angle rotating around y axis, in radians
theta = angle rotating around z axis, in radians
Library case 384 illustrates the use of the ELLPSD function for the creation of an ellipsoid in a cubical domain, with all its rotations equal to 0.25 radians, by means of the following statements:
inform11begin (stored of mark at patch1 is 1.0 with infob_1) ! MARK object (initial of prps is 100 with infob_1) ! initialise PRPS real(x0,y0,z0,xs,ys,zs,al,be,th) ! declarations x0=xulast/4 ! x/y/z position of ellipsoid y0=yvlast/4 ! z0=zwlast/4 ! xs=xulast/2 ! x/y/z radius of ellipsoid ys=yvlast/3 ! zs=zwlast/4 ! al=0.25 ! alpha/beta/theta angles of coordinate system be=0.25 ! of ellipsoid th=0.25 ! (infob at patch1 is ellpsd(x0,y0,z0,xs,ys,zs,al,be,th) with infob_1) inform11endAn image representing the ellipsoid created by core-input-file-library case 384 can be seen by clicking here.
Another example of the use of ellipsoid objects is core-library case 162, wherein the ellipsoid is given such an extremely large y-direction radius that, within the domain of study, it can be regarded as a cylinder.
It is indeed used there to represent a cylindrical pipe with an aperture in its walls from which gas is released into the atmosphere,
A fuller description of the situation can be found by clicking here,
Sub-grid objects are those of which one of the dimensions is smaller than that of the computational grid.
The three basic shapes of this kind are: POINT, LINE and PLANE; and to each there corresponds an In-Form function.
(INFOB at PNTPAT1 is POINT(arguments) with INFOB_PNT1!options
where PNTPAT1 and PNT1 are names chosen freely by the user.
The arguments in question are as follows:
POINT(x0,y0,z0,nomdiam)
where:
x0 = X-coordinate of the point, in meters,
y0 = Y-coordinate of the point, in meters,
z0 = Z-coordinate of the point, in meters,
nomdiam = nominal diameter of the point.
The setting of point objects is exemplified in Core Library case 385, as seen by clicking here.
(INFOB at LINPAT1 is POINT(arguments) with INFOB_LIN1!optionsV
where LINPAT1 and LIN1 are names chosen freely by the user.
The arguments in question are as follows:
LINE(x0,y0,z0,x1,y1,z1,nomdiam)
where:
x0 = X-coordinate of the start point, in meters,
y0 = Y-coordinate of the start point, in meters,
z0 = Z-coordinate of the start point, in meters,
x1 = X-coordinate of the end point, in meters,
y1 = Y-coordinate of the end point, in meters,
z1 = Z-coordinate of the end point, in meters,
nomdiam = nominal diameter of the line.
The setting of line objects is exemplified in Core Library case 385, as seen by clicking here.
(INFOB at PLAPAT1 is PLANE(arguments) with INFOB_PLA1!options)
where PLAPAT1 and PLA1 are names chosen freely by the user.
The arguments in question are as follows:
PLANE(
where:
x0 = X-coordinate of 1st vertex, in meters,
y0 = Y-coordinate of 1st vertex, in meters,
z0 = Z-coordinate of 1st vertex, in meters,
x1 = X-coordinate of 2nd vertex, in meters,
y1 = Y-coordinate of 2nd vertex, in meters,
z1 = Z-coordinate of 2nd vertex , in meters,
x2 = X-coordinate of 3rd vertex , in meters,
y2 = Y-coordinate of 3rd vertex, in meters,
z2 = Z-coordinate of 3rd vertex, in meters,
x3 = X-coordinate of 4th vertex, in meters,
y3 = Y-coordinate of 4th vertex, in meters,
z3 = Z-coordinate of 4th vertex, in meters,
nomdiam = nominal thickness of the plane.
Not all shapes are permissible, as shown here.
Further, if the user inadvertently selects four points which do not lie in a plane, the fact is detected by PHOENICS, which thereupon changes the 9th co-ordinate to such a value (there can be only one) which causes the fourth vertex to lie in the plane of the other three; or, if that is not possible, it does it for the 8th or the 7th.
It is sometimes useful to distinguish the two sides of the plane as being 'positive' or 'negative'. The convention adopted is that the positive side of the plane is that in which one must look if the first, second, third and fourth points are to apppear in clock-wise order.
Thus we are looking in the positive direction of the top-left quadrilateral above (and therefore seeing its negative side:
and we are looking in the negative direction at the top-right quadrilateral (and therefore seeing its positive side.
The setting of plane objects is exemplified in Core Library case 385, which employs PIL do loops to enable many objects to be set, in orderly groups
Points, lines and planes are all represented, the later by way of 'quadrilaterals' which have been reduced to triangles, as is always permissible, by having two cooincident vertices.
When the patch referred to in the INFOB command is as large as the whole domain, the photon picture showing the contours and surface of the MARK variable are as shown here.
Evidently the shape of the object has changed for the indicially-sized patch; but it has remained constant for the geometrically-sized one. That the grid change is the same in both cases is shown be the eqaual enlargement of the white bands used by PHOTON to high-light the co-ordinate axes.
Of the two images below, that on the left displays the shape of the apertures by way of MARK contours, while that on the right shows the associated velocity vectors.
Of course, use of a finer grid would improve the circularity-appearance of the aperture edges. The use of a dot-patch makes this easy.
The use of 'subtraction', to be discussed in section (f) below, is much more powerful.
Examination of the Q1 file shows that the pyramid is composed of four parts, of which the first, created by the lines:
(INFOB at PATCH1 is BOX(10,10,0,.5*(-ZG+20),.5*(-ZG+20),$ 16*(-ZG+20.),0,0,0) with INFOB_1!poros)while the second is created by the lines:
(INFOB at PATCH1 is BOX(10,10,0,.5*(-ZG+20),.5*(-ZG+20),$ 16*(-ZG+20.),0,0,.5*PI) with INFOB_1!poros)in which the sole differences have been distinguished by the red font.
These first two quarters of the pyramid are shown below:
Let us now consider how it was that the quarter pyramids were created. The crucial steps were:
5*(-ZG+20) and .5*(-ZG+20),dictate that horizontal dimensions of the box diminish linearly as the height zG increases. This gives the object its 'pointed'shape.
16*(-ZG+20.)proves to be much less important; indeed the person who introduced it was probably not perfectly clear as to what he or she was doing; for to insert
ZGproduces only porosity difference at the very peak of the pyramid; then inserting
ZWLASTor
2.0*ZWLASTor any large-enough number produces no further differences at all!
All that is important is that, when the EARTH solver module is deciding about each cell having co-ordinates xG, yG and zG whether it lies inside of outside the box, the box appropriate to that cell should have a z-dimension large enough to enclose it.
The following hyperlinks lead to photon displays of the various shapes:
caseno | shape | grid type | hyperlinks |
---|---|---|---|
1 | fixed sphere | cartesian | click here |
2 | fixed sphere | bfc | click here |
3 | fixed sphere | polar | click here |
4 | cone | cartesian | click here |
5 | cone | bfc | click here |
6 | cone | polar | click here |
7 | spiral | cartesian | click here |
8 | spiral | bfc | click here |
9 | spiral | polar | click here |
10 | curved duct | cartesian | click here |
11 | curved duct | bfc | click here |
In the following table are shown the values of the arguments of the sphere function in the infob statement for the various cases. namely:
(infob at .patch1 is sphere(x0,y0,z0,rad) with infob_1)
caseno | x0 | y0 | z0 | rad |
---|---|---|---|---|
1 | xulast/2 | yvlast/2 | zwlast/2 | xulast/4 |
2 | xulast/2 | yvlast/2 | zwlast/2 | xulast/4 |
3 | xulast/2 | yvlast/2 | zwlast/2 | yvlast/2 |
4 | xulast/2 | yvlast/2 | zg | 0.25*(:zwlast:-zg) |
5 | xulast/2 | yvlast/2 | zg | 0.25*(:zwlast:-zg) |
6 | yvlast | yvlast | zg | 0.5*(:zwlast:-zg) |
7 | :xulast/2:*(1+0.8*cos(:PI2:*zg)) | :yvlast/2:*(1+0.8*sin(:PI2:*zg)) | zg | zwlast/10 |
8 | :xulast/2:*(1+0.8*cos(:PI2:*zg)) | :yvlast/2:*(1+0.8*sin(:PI2:*zg)) | zg | zwlast/10 |
9 | :yvlast:*(1+2*:rad:*cos(:PI2:*zg)) | :yvlast:*(1+2*:rad:*sin(:PI2:*zg)) | zg | yvlast/4 |
10 | xg | :yvlast/2: | :zwlast/2:+0.25*sin(:pi2:*xg/xulast) | yvlast/4 |
11 | xg | :yvlast/2: | :zwlast/2:+0.25*sin(:pi2:*xg/xulast) | yvlast/4 |
The following points should be noted:
The grid is not fine enough to show the shape well; but the flattening is unmistakeable.
Library case 249 also possesses two boolean variables: altercrt and alterbfc. Both were set false in all the cases shown so far; but, when set true,the former alters the cartesian grid and the latter alters the bfc one. They have been used for further testing the grid-independence of the In-Form object settings, with the results shown here.
Clearly, although the distribution of the grid lines does affect the smoothness of its surface, the position of the sphere in cartesian space is not infuenced by it.
The bfc grid, it should be mentioned, was coarsened as well as distorted because the the execution of the PIL do loop in the Q1 file, by which the distortion was effected, is rather slow.
case 768 reveals that there is more than one way to create a spiral in a polar-coordinate grid; and its way of doiing so does create cross-sections which are more truly circular than those of case 749, as the next Photon image shows:
This method, as is seen, uses the angular coordinate xg in the formula; therefore it is necessary to use two spheres for the two-turn spiral shown here. They can however, if desired, be specified in a single INFOB statement, as is explained by comments in the Q1 file of the case.