Some of those readers may be content on finding that a special-application-package which satisfies their needs has already been created, i.e. that the 'app-tree' (see below)
already bears the fruit they desire.
Others, recognising, that many more apps will be needed before all potential beneficiaries from CFD have been supplied, will wish to learn how they may become app-makers themselves. This tutorial is for them also.
Please note: throughout this tutorial, hyperlinks such as 'Q1 files' and 'PIL' above allow inquisitive readers to acquire fuller information about the so-marked items. But doing so is not positively advised, lest readers become lost in the (here metaphorical) 'Labyrinth' of the PHOENICS Encyclopedia. The present tutorial is itself designed to be a sufficient 'Ariadne's Thread' for the beginner.
PIL is a created-for-CFD language, and not hard to learn; but it must of course be learned by would-be providers of input to PHOENICS; unless of course some easy-to-use utility can write it for them.
(1.1 b) VRE writes 'pidgin-PIL' Q1 files
Such a utility is the so called Virtual-Reality Editor abbreviated to VRE; but how to use VRE also has to be learned. One of the early aids to learning was a tutorial using flow through a labyrinth as its example. It can be inspected by clicking here.
Strictly speaking, the student of that tutorial, and of others of the same era, are not shown what Q1 is written as a result of his or her efforts. VRE tended therefore to make its users dependent on it; and, PIL being hidden from view, so were PIL's wider powers.
They were tutorials, one might say, on how not to write Q1s, but to let VRE do the job instead. However VRE was able to write what might be called 'pidgin PIL'; i.e. expressions of only the simpler input-data concepts.
(1.1 c) Humans write
parameterised Q1 files
PIL is a very powerful language, with variable-declaration, logical and conditional constructs, and formula-expressing capabilities. PIL's beyond-VRE capabilities can however be unleashed only via parameterised Q1s, which humans alone can write.
In the present tutorial also the labyrinth is being used; partly for the sake of continuity, but partly as a back-drop against which to exhibit the latest features of simulation capability and ease-of-use of PHOENICS. The latter include PHOENICS-Direct and the PQ1 Editor.
During the course of this exposition, it will be observed that the objects of the original labyrinth tutorial are not all of the same kind. Three of them are truly three-dimensional; but the others are two-dimensional and grid-aligned. Since the beginnings of the 'virtual-reality take-over', nearly two decades ago, the distinction has been somewhat blurred. But it is worth clarifying now because PHOENICS has recently been rendered capable of handling objects which are two-dimensional but not grid-ali gned.
Partly for this reason, the General section of the PHOENICS-Direct menu has been provided, as shown below.
Information about the whole-domain dimensions are also introducible here.
This is an image which will be familiar to students of the pre-SimScene tutorials. Eight objects are displayed namely:
The image is produced by behind-the-scenes activation of the VR-Editor, caused by two lines in /phoenics/d_sapps/labyrinth/input/interface.xml which selects the scenario-display device which PHOENICS-Direct is to use in the SimScene.
The lines are:
%PHOENICS%\d_sapps\common\direct\run.bat %PHOENICS%\d_satell\d_windf\satexe.exe vre
The parameters relating to object 1 appear first. Those which characterise it, and their default values, appear in the right-hand columns. Explanations of these are:
> OBJ, NAME, IN-BLOCK > OBJ, POSITION, 1.000000E+00, 0.000000E+00, 5.000000E-02 > OBJ, SIZE, 4.000000E-01, TO_END, 6.500000E-01 > OBJ, DOMCLIP, NO > OBJ, GEOMETRY, cube14 > OBJ, ROTATION24, 1 > OBJ, TYPE, BLOCKAGE > OBJ, MATERIAL, 103,COPPER at 27 deg C
The creators of the present tutorials, by contrast, have provided in the underlying parameterised Q1 file the lines which caused PHOENICS-Direct to exhibit the menus which have just been seen, namely:
if(is_1) then > OBJ, NAME, onam1 > OBJ, POSITION, posx1, posy1, posz1 > OBJ, SIZE, sizx1, sizy1, sizz1 > OBJ, GEOMETRY, :ogeo1: if(:rotmo1:.eq.rot24) then > OBJ, ROTATION24, orot1 else > OBJ, rot-angle, alpha,beta,theta endif > OBJ, rot-centre, :rotcen: > OBJ, DOMCLIP, NO > OBJ, TYPE, BLOCKAGE > OBJ, MATERIAL, :mt_1: > obj, wireframe, yes) endif
Comparison of the above two in-Q1 sequences shows many differences, for example:
Object 1 char(onam1) ! object 1 name onam1=IN-BLOCKwhich declares the name of object 1;
char(ogeo1) ! shape of object 1which offers a choice of shapes for object 1;
ogeo1=cube14 ! sphere;cone;cylinder;half-sphere;half-cone;half-cylinder char(rotmo1) ! rotation modewhich indicates how object 1 should be rotated;
rotmo1=rot24 ! rotang integer(alpha) ! rotation angle about x-axis alpha=0 integer(beta) ! rotation angle about y-axis beta=0 integer(theta) ! rotation angle about z-axis theta=0 char(rotcen) ! rotation centre rotcen=wsl!esl;wnl;wsh;enl;esh;wnh;enh;centre wsl=west-south-low, etc. integer(orot1) ! rotation index orot1=1which declare rotation parameters for object 1; and so on, to parameters representing position and size.
We are going to change shape, locations and sizes of the in-block object inside the labyrinth as well as its material.
Under '3D objects' tab the box 'shape of object 1" is represented by a list of possible shapes wherein we can find, e.g., the cone and select it.
The objects in the list correspond precisely to the line in the PQ1 file which was already referrred to above, namely
ogeo1=cube14 ! sphere;cone;cylinder;half-sphere;half-cone;half-cyl$ inderThis is because what appeared in the PQ1 has its automatically-created counterpart in the file
<param type="list"> <name>shape of object 1</name> <variable>ogeo1</variable> <variable_type>character</variable_type> <declared>yes</declared> <value default="yes">cube14</value> <value>sphere</value> <value>cone</value> <value>cylinder</value> <value>half-sphere</value> <value>half-cone</value> <value>half-cylinder</value> </param>These lines are written without error (as few humans could do) by the PQ1-editor whenever it saves PQ1; and they are read by the PHOENICS-Direct module when it displays the screen image which has just been shown.
which for simplicity we replace with numbers as follows.
The object called IN-BLOCK, initially rectangular, is now replaced by a cone. This happens because the entries in the menu boxes have already been written into the frommenu.htm file, which is 'included' into the Q1 file which the VR-Editor reads before presenting the scenario image.
Close the VR Editor window to return to the PHOENICS-Direct window.
The mode chosen by default is rot24. It will be discussed first.
It is not a very useful mode for two reasons:
The images that follow show orientations of the cone for rotation indices corresponding to the 6 choices of 'floor' introduced in each picture, namely: 1, 5, 9, 13, 17 and 21. There would be no point in displaying intemediate-index images, because a cone looks the same from every side.
Note that the cones in the above pictures do not all have the same height/diameter ratio. Indeed they are not all, strictly-speaking, cones at all. The reason is that rotations of this kind constrain the object always to lie within the original bounding box; and the x-direction and y-direction sizes are different. Therefore when its symmetry axis lies in the y-direction (rotation index 5 or 17) or in the x-direction (rotation index 9 or 21), the base of the object is an ellipse, not a circle.
The menu items then offered include:
Click then on the display-scenario button. Something similar to the following image
should be revealed. Evidently the block has been tilted 30 degrees to the right as a consequence of the entries into the menu.
If it is desired to produce by rotation a three-dimensional flow pattern, a further rotation about (say) the z-axis can procure this. Let this then be also 30 degrees. Then the consequent rotation and flow-pattern alterations are as illustrated in the following images.
OBJ, TYPE, PLATETheir effects on the flow differ in that in-plate has a flow-through-it-inhibiting effect, as well as exerting friction on both of its sides. Wall-w and wall-e do not have to exert this effect because they are situated at domain boundaries.
The distinction is made plain by what is printed in the RESULT file as a record of the instructions which it has received, as may be seen in the following extract:
Parent VR object for this patch is: ONAM3 PATCH(OB4 ,EWALL , 20, 20, 1, 10, 9, 15, 1, 1) COVAL(OB4 ,V1 ,1. ,0. ) COVAL(OB4 ,W1 ,1. ,0. ) Parent VR object for this patch is: ONAM4 PATCH(OB5 ,WWALL , 1, 1, 1, 10, 1, 8, 1, 1) COVAL(OB5 ,V1 ,1. ,0. ) COVAL(OB5 ,W1 ,1. ,0. ) Parent VR object for this patch is: ONAM5 PATCH(OB6-L ,EWALL , 5, 5, 1, 10, 6, 14, 1, 1) COVAL(OB6-L ,U1 , FIXVAL ,0. ) COVAL(OB6-L ,V1 ,1. ,0. ) COVAL(OB6-L ,W1 ,1. ,0. ) Parent VR object for this patch is: ONAM5 PATCH(OB6-H ,WWALL , 6, 6, 1, 10, 6, 14, 1, 1) COVAL(OB6-H ,V1 ,1. ,0. ) COVAL(OB6-H ,W1 ,1. ,0. )Only ONAM5, viz in-plate, has two patches: of EWALL and WWALL types respectively; and it alone has a set-U1-to-zero line, namely:
COVAL(OB6-L ,U1 , FIXVAL ,0. )The above settings are made by Satellite automatically. That is one of the advantages of the virtual-reality style of object description.
The objects appear in the order: wall-w, wall-e and in-plate. For each the x_size is 0.0, confirming their 2D nature. Each is given the shape 'cube11'; but this means no more that that they are rectangular planes, Even more meaningless is the ascribed rotation index 1; for any other of the 24 possibilities would effect no change. Rotations of the 'rotang' mode are not permitted for 2D grid-aligned objects.
If however the shape is changed from 'cube' to 'wedge', the rotation index does exert an influence, as is shown by the next two images, in which in-plate is given the values 5 and 13 respectively. In order to introduce this change, simply type the word "wedge" in the object 5 geometry box to get what follows.
Of the three, it is in-plate which has the greatest influence on the flow, as may be seen by performing runs with f rather than t in the top boxes of each object in turn; for it is in-plate which causes the incoming flow to be deflected before flowing over in-block.
Removal of wall-w and wall-e, by contrast would remove only their modest frictional effects, which incidentally in-plate also exerts.
The following image shows one picture of the flow which ensues when object 7, the inlet, is given the shape 'wedge' and the rotation index remains at 1. This can be done, as we already know, by typing the word "wedge" instead of "cube3t" in the 'shape of object 7' box. The grid is the rather-coarse default; and contours are of x-direction velocity.
Evidently the flow is entering only through the lower left-hand half of the original inlet aperture.
In principle, any existing shape of inlet can be constructed in this way; one needs only to be able to call in the .dat file which defines its facets; and to work out which is the appropriate rotation index. Since those conditions (especially the second!) are not always easy to meet, it will now be explained that there are other means of obtaining the same end; and that sometimes they are more convenient. Answering 'as_patch' to the 'inlet_treatment' question of the General menu opens the door.
PATCH(patch_name,INIVAL,ixf,ixl,iyf,iyl,izf,izl,itf,itl)wherein ixf,ixl,iyf,ixl etc. were the first and last indices of the cells occupied in the x, y, etc. directions.
Such PATCH statements appear to this day, as has been seen above.
Users know where their objects are; but not necessarily where the cells are. However a (post-VR) 'dot-patch' innovation allows them to put a dot in front of the patch_name, and then to employ real (rxf, rxl etc.) rather than indicial arguments, thus:
PATCH(.patch_name,INIVAL,rxf,rxl,ryf,ryl,rzf,rzl,rtf,rtl)or, for a mass- and momentum-source ptach such as an inlet,
Now a final post-VR innovation must be described: the COVAL function of In-Form. Clicking on the hyperlinks will lead to full explanations of these terms; but here it sufffices to show two examples of their use, and then to explain how they were created.
How this is done is revealed by the following lines from the underlying PQ1:
else ! the dot-patch alternative rxf=posx5/xulast*1000;rxl=posx5/xulast*1000 ryf=posy5/yvlast*1000;ryl=(posy5+sizy5)/yvlast*1000 rzf=posz5/zwlast*1000;rzl=(posz5+sizz5)/zwlast*1000 PATCH(.:onam5:,EAST,rxf,rxl,ryf,ryl,rzf,rzl,1,1) condtn=zg.gt.:posz5:*(1.+sin(3.1416*yg/:sizy5:)) (source of u1 at .:onam5: is coval(1.e10,0.0)!if(:condtn:)) endifwherein the first few lines dictate the bounding box of the plate, that beginning 'source ' sets the x-direction velocity to zero when 'condtn' is true, and the line above it, which contains the sine function, dictates where the setting is to be made.
That these lines are effective is shown by the following image, which displays contours of x-direction velocity just downstream of in-plate, with values of NY and NZ increased from their defaults in order to intensify the effect. Their sinusoidal shape is very clear.
The 'condtn' formula can of course be varied without limit; therefore any desired shape of plate can be easily created.
Two comments are needed about the above-shown PQ1 lines, for example:
the division by yvlast indicates that ryf is a non-dimensional co-ordinate; and the multiplication by 1000 is a not-worth-explaining 'trick' concerned with the inner workings of the Satellite coding.
(2.4. b.3) Circular inlets and outlets
A similar technique can be employed for altering the shapes of inlets and outlets. Thus, the following diagrams illustrate, on the left and right respectively: an inlet in which an inner circular section is blocked; and an outlet in which the circular section is open. The grid is uniform, with 40 and 60 intervals in the y- and z-directions respectively. The contour plots are of x-direction velocity; and the chosen planes are close to, but not precisely at, the planes of the apertures.
The PHOENICS run which produces the just-shown results was launched by way of menus already shown; but, underlying these were some passages in the parameterised Q1 file which will now be discussed. For the inlet they are:
else ! the dot-patch alternative rxf=posx7/zwlast*1000 rxl=(posx7+sizx7)/xulast*1000 ryf=posy7/zwlast*1000 ryl=(posy7+sizy7)/yvlast*1000 rzf=posz7/zwlast*1000 rzl=(posz7+sizz7)/zwlast*1000 patch(.:onam7:,west,rxf,rxl,ryf,ryl,rzf,rzl,1,1)which desctibe the bounding box of the patch;
real(ycn,zcn) char(radsq) ycn=posy7+0.5*sizy7 zcn=posz7+0.5*sizz7 radsq=(yg-:ycn:)^2+(zg-:zcn:)^2 condtn=radsq.gt.0.04 (stored var rgt is 1 !if(radsq.gt.0.04))which define the centre of the circle and its radius (squared), also define the outside-circle condition; and
(source of p1 at .:onam7: is :invelx: with fixf!if(:condtn:)) coval(.:onam7:,u1,onlyms,invelx) coval(.:onam7:,tem1,onlyms,intem) endifwhich applies the sources of mass, momentum and thermal energy.
For the outlet, the statements are identical except that: 8 replaces 7 because that is the object number; and '.lt.' replaces '.gt.' because the active area is now inside rather than outside the circle.
A pertinent question; to which the answer is: "Certainly, not!"
It is the prospective PQ1 writer who should learn it; and who should, if it is relevant to the SimScene which is to be created, enable the 'ordinary user' to exploit the available facilities.
How is this to be done? Simply by utilising the existing facilities connecting PQ1, scene.xml, and what appears in the user's screen.
Does the user, interested in circular inlets, wish to choose the centre and radius of the circle? The PQ1 writer should find it is easy, (xcen, ycen, zcen and radsq already having been defined as parameters), if this tutorial has been successful, to know what to do. Readers might wish to ask themselves how they would make this possible before activating and exploring the provisos for radius adjustment already made, in this tutorial, in the menus for the inlet and outlet objects.
These are pressure p1 and temperature tem1, as well as the three Cartesian-directon velociy components, u1, v1 and w1.
They can be set either to "t" (meaning "true") or "f" ("false"). The index "1" indicates that this is a case when only one fluid is used, no provision having been made, in this tutorial, for activating the two-intermingling-fluids capabilities of PHOENICS.
That individual variables can be set "t" or "f" does not imply that any arbitrary collection of settings is reasonable. Thus presssure should always be solved for; otherwise mass continuity will not be preserved. Solvng for temperature, might be switched off if thermal effects were of no interest; but solving for it alone, although possible, would be unwise unless physically plausible velocity distributions had been imposed.
That is all that will be said about the topic here.
The selection of the material of the solid objects can be selected via the top three boxes of the menu shown below:
When the drop-down menu of the object 1 box is activated, what is seen is shown below.
This enables other materials to be selected, with their correspondngly-different densities, thermal conductivities, etc., all being regarded as independent of temperature.
If one of these is selected, the information, which is drawn from the PHOENICS library of materials, includes how the properties vary with temperature.
It allows turbulence to be represented either not at all, or else by the simplest-of-all lvel model. As is clear from the above image none of the models is used at present.
The boundary coditions which can be set here are:
i.e the number of grid cells in X-, Y- and Z-directions and also the number of iterations. Increasing the number of iterations it is possible to improve the convergence of the calculation process.
Note that in this page 3-dimensionality is introduced by making the number of cells in Y-direction equal to 10 rather than to 1 used in the two-dimensonal simulations in the older labyrinth tutorials mentioned above.
In the graphical output page a user sets his control on the display of streamlines
upon termination of the calculation. Here a principal possibility is made evident
when in the first box either "t" (true) or "f" (false) is chosen. In case a user
chooses to display streamlines, their number is entered in the second box.
How and where this possibility is realized, will be shown in section 4.
Click on the 'Run' button
to start the calculation, and upon its termination click on the "Display results graphically" button
to open the VR Viewer.
We will here present some results of the simulation made.
Here, for better visibility, we selected the wireframe-display mode by clicking on the 'Wireframe toggle' button;
and similar representation of velocity contours on the Z-plane will look as follows:
The material chosen by default for the cone was a highly conducting copper (with the constant properties appropriate to 27 degrees Celsius). Besides, the heat flux introduced from the bottom lower plate was uniform and 100 W only. This is the explanation why we got so uniform temperature distribution inside the cone.
and closing it afterwards,
Temperature stratification is very obvious here and having introduced 1 kW heat flux coming from the lower plate we obtained much higher temperatures.
The number of iterations (400) was not changed.
The easiest way to compare the results upon the end of calculations is to use temperature contours as an example.
It is clear that only the two first images depict a realistic picture. In the third case the increase of cell numbers eight times as compared with the initial ones, did not produce a realistic picture of temperature contours; and the minimum temperature is reported as about minus 50 degC.
A no-nonsense user might now feel a strong urge to send the software back to its provider, perhaps forever. In this tutorial however, we will inquire a little more deeply into how such faulty predictions came to be made, and how they can be avoided.
In doing so, a useful method of 'looking behind the scenes' into PHOENICS-Direct will be disclosed; and its poential future utility may make the digression worthwhile.
First however we glance at some other effects of increasing grid size, so as to check whether they seem to be reasonable.
CPU time of run 29 s This includes 25 seconds of user time and 4 seconds of system time. TIME/(VARIABLES*CELLS*TSTEPS*SWEEPS*ITS) = 4.833E-06
CPU time of run 158 s This includes 151 seconds of user time and 7 seconds of system time. TIME/(VARIABLES*CELLS*TSTEPS*SWEEPS*ITS) = 3.292E-06
CPU time of run 1186 s This includes 1172 seconds of user time and 14 seconds of system time. TIME/(VARIABLES*CELLS*TSTEPS*SWEEPS*ITS) = 3.089E-06
One of the easiest ways of checking how well a solution has converged to the solution which is appropriate to the grid size is by examining the closeness to equality of the rates of inflow and outflow of mass. This is deducible from the following lines which are printed in the RESULT file. For the three grid sizes which have been investigated, the relevant lines are:
Nett source of R1 at patch named: OB7 (ONAM7 ) = 2.675250E-02 Nett source of R1 at patch named: OB8 (ONAM8 ) =-2.675249E-02 (Mass Out -2.675250E-02 In 0.000000E+00) pos. sum=0.026752 neg. sum=-0.026752 nett sum=5.587935E-09 Nett source of R1 at patch named: OB7 (ONAM7 ) = 2.675250E-02 Nett source of R1 at patch named: OB8 (ONAM8 ) =-2.675284E-02 (Mass Out -2.675284E-02 In 0.000000E+00) pos. sum=0.026752 neg. sum=-0.026753 nett sum=-3.408641E-07 Nett source of R1 at patch named: OB7 (ONAM7 ) = 2.675250E-02 Nett source of R1 at patch named: OB8 (ONAM8 ) =-2.675230E-02 (Mass Out -2.675230E-02 In 0.000000E+00) pos. sum=0.026752 neg. sum=-0.026752 nett sum=1.918525E-07Inspection of these numbers, in which "Nett source of R1" signifies mass flow rate, indicates that all three grids give essentially the same answer, and that the differences between inflow and outflow are negligible. This is very satisfactory.
What about the corresponding energy-flow balances however? The RESULT files show:
Nett source of TEM1 at patch named: OB7 (ONAM7 ) = 7.870658E+03 Nett source of TEM1 at patch named: OB8 (ONAM8 ) =-8.039979E+03 (Ave Out 2.623291E+01 In 0.000000E+00) Nett source of TEM1 at patch named: OC2 (ONAM2 ) = 1.000000E+02 Nett source of TEM1 at patch named: OC6 (ONAM6 ) = 1.525879E+04 pos. sum=2.322945E+04 neg. sum=-8039.979492 nett sum=1.518947E+04 Nett source of TEM1 at patch named: OB7 (ONAM7 ) = 7.870656E+03 Nett source of TEM1 at patch named: OB8 (ONAM8 ) =-8.001582E+03 (Ave Out 2.482197E+01 In 0.000000E+00) Nett source of TEM1 at patch named: OC2 (ONAM2 ) = 1.000000E+02 Nett source of TEM1 at patch named: OC6 (ONAM6 ) = 1.525870E+04 pos. sum=2.322936E+04 neg. sum=-8001.581543 nett sum=1.522777E+04 Nett source of TEM1 at patch named: OB7 (ONAM7 ) = 7.870667E+03 Nett source of TEM1 at patch named: OB8 (ONAM8 ) =-7.978067E+03 (Ave Out 2.410911E+01 In 0.000000E+00) Nett source of TEM1 at patch named: OC2 (ONAM2 ) = 9.999814E+01 Nett source of TEM1 at patch named: OC6 (ONAM6 ) = 1.525826E+04 pos. sum=2.322893E+04 neg. sum=-7978.067383 nett sum=1.525086E+04Here too there is substantial agreement: but agreement, in one respect, to be wrong!
What is clear, and satisfactory, is that the difference between the inflow (ONAM7) and outflow (ONAM8) is about 100 watts, which is very close to the heat input at the lower block (ONAM2), which is to be expected. What is unsatisfactory is the large and unbalanced heat-flux reported for the higher block (ONAM6).
What is the temperature of that block? Inspection of the RESULT file shows that it is 100.0 degrees Celsius, just as was set in the boundary-condition menu (section 2.6). So what is wrong?
The boundary condition at the block in question is nominally one of 'fixed temperature'; but now it must be disclosed that PHOENICS never imposes such conditions directly, but only via 'linearised-source terms'; thus:
wherein CO and VAL are capitalised as a reminder ot the closely connected PIL statement COVAL. A 'fixed temperature' is than secured by setting VAL equal to it and making CO very large; for then even a small departure of the current value from the required one will introduce a heat source tending to correct it.
The knowledgable (and painstaking) reader of the RESULT file can find in it, by way of confirmation, the lines:
Group 13. Boundary & Special Sources Parent VR object for this patch is: ONAM6 PATCH(OC6 ,VOLUME, 1, 20, 1, 10, 15, 15, 1, 1) COVAL(OC6 ,TEM1,1.0E+10 ,100. )wherein the emboldened characters are indeed the said CO and VAL, the former of which is indeed 'very large' namely, 1.0E+10.
Indeed too large, one may surmise; because, if the desired and actual values of temperature differ by no more that the rounding error of 100.0 (and they must differ by something if the method is to work at all), the resulting source can be quite large; as indeed it is in this case.
One way to test the surmise is to use smaller magnitude for CO. But how is this to be done? For CO is not accessible as a settable parameter, as the image in section 2.6 shows.
Even though it is not presented as a parameter, the Co of 1.0E+10 is being transmitted to the Earth Solver module somehow; and the only way is via the EARDAT file which Satellite, having read Q1, writes in the worling directory. Moreover this is an ASCII file which we can search and edit, for example with Notepad,
Although the file is a long one, there are only few occurrences of 0E+10; and only one of them occurs with 1.000000E+02 as the next number, thus:
2.000000E-10 9.999998E+02 1.000000E+10 1.000000E+02It is therefore reasonable to presume that these are the sought-for CO and VAL; and it is easy to modify them to, say:
If this is done, and the Earth solver module is then launched by way of the command 'runear', it will be found that the energy heat-balance lines in RESULT become:
Nett source of TEM1 at patch named: OB7 (ONAM7 ) = 7.870653E+03 Nett source of TEM1 at patch named: OB8 (ONAM8 ) =-8.084789E+03 (Ave Out 2.787926E+01 In 0.000000E+00) Nett source of TEM1 at patch named: OC2 (ONAM2 ) = 1.000000E+02 Nett source of TEM1 at patch named: OC6 (ONAM6 ) = 1.128006E+02 pos. sum=8083.453613 neg. sum=-8084.789062 nett sum=-1.335449;while the temperatures at the highest z locations are given by:
Field Values of TEM1 IY= 10 1.010E+02 1.010E+02 1.010E+02 1.010E+02 1.010E+02 IY= 8 1.010E+02 1.010E+02 1.010E+02 1.010E+02 1.010E+02
Evidently our intervention in EARDAT has been successful. The nett-sum error is less than 1% of the absolute sum of the heat fluxes; and the H-BLOCK does possess its (new) required value.
real(hitem) ! temperature of H-block hitem=100.0by a second for the coefficient, say:
real(cotem) ! temperature coefficient of H-block cotem=1.E5But that is not all. In the lower-down >OBJ region of the PQ1, the coefficient would be enabled to exert its influence by deactivating one line and activating a substitute, thus:
>> obj, temperature, hitem (source of tem1 at onam6 is coval(:cotem:,:hitem:))
write(>u, p;;;;; ) write(>>u, Start of frame ) write(>>u, * Setting display switches ) )Here the 'write' statements contain instructions for the macro file 'u' for the creation of several specific images (frames) shown in a given sequence one after another.
The streamlines are visible because in the 'graphical output' page the 'show streamlines' setting is 't' (true). If we make this setting 'f' (false), the streamlines will not be displayed in the macro.