Encyclopaedia Index

Summary

A 'PHOENICS Object' possesses The totality of its attributes is defined in a single file of which the name has the extension .pob .

The PHOENICS-object concept

  1. New thinking about objects and patches
  2. The POB file
  3. The POBs for Heating and Ventilating
  4. Further new thinking


Section 1. New thinking about objects and patches


Section 2: The POB file

Changes of thinking are assisted by changes of nomenclature. Therefore the 'Phoenics Object file', with the extension .pob, has been introduced.
Unlike the more familiar .dat file, it may also contain information of a non-geometric character.

Although in fact .dat and .pob files are treated in the same way by the PHOENICS satellite, the former name is preferred for the old-style geometry-only files (of which there are very many); while the latter is used for any file which also contains non-geometric attributes.

A PHOENICS Object File may contain data regarding a single object; or it may describe several objects which are linked together as an 'assembly'

POB files can be read from either the current working directory, or from any subdirectory of /phoenics/d_satell/d_object/public.

See also the TR326 entry on ASSEMBLY objects, which use the POB file to save the components of an assembly,
and also the tutorial Working with ASSEMBLY Objects.


The .pob file is not the first to contain both geometric and non-geometric information; for the .geo file produced by the Shapemaker modules did the same.

Moreover, whereas the VR-Editor could work only with imported shapes, Shapemaker could create them AND assign attributes to the associated objects.

In order to simplify the user's task, the capabilities of both the VR-Editor and Shapemaker have been combined, so that:-


Section 3. POBs for heating and ventilating

PHOENICS provides a library of HVAC-related POB files, namely:

These files can be imported, modified, exported and retrieved through the Object Management Panel in the PHOENICS graphical user interface, VR-Editor, as shown below.

 

POB files can be created using either The Shapemaker program or the VR-Editor.

The VR-Editor can also import or export assemblies of objects in a single POB file. The information stored in a POB file may include:


4. Further new thinking

4.1 Generalising the POB idea by using INCL(filename)

Once it has been recognised that a .pob file merely contains a set of object-related statements such as appear in Q1 files, the possibility of introducing such statements in other ways can be envisaged.

One such way is the use of the long-existing PIL INCL statement.

Thus, if a file called, say, v100obs.htm were to be created which contained the statements regarding the objects of case v100, revealed above by clicking here, then those statements could be replaced in the q1 file by the single line:
INCL(v100obs.htm).

The satellite will react to this q1 in precisely the same way as it does to the original one, in the sense that the q1ear and eardat files which it produced would be identical.

Moreover, if the lines referring to the domain were similarly transferred to v100obs.htm, namely:



 GVIEW(P,7.390102E-01,-6.736943E-01,0.000000E+00)

 GVIEW(UP,0.000000E+00,0.000000E+00,1.000000E+00)



> DOM,    SIZE,        1.000000E+01, 2.000000E+00, 1.000000E+00

> DOM,    MONIT,       5.000000E-01, 1.000000E+00, 5.000000E-01

> DOM,    SCALE,       1.000000E+00, 1.000000E+00, 1.000000E+00

> DOM,    SNAPSIZE,    1.000000E-02

> DOM,    RELAX,       5.000000E-01 
the result would also have been the same.

Of course, if the satellite is operated in the interactive mode, the Q1 which it saved will be different from the one which it read; for the > DOM .... and > OBJ .... lines would have reappeared in it.

4.2 Use of PIL variables in the included files

It would be allowable, in the q1 or in the INCLuded file to replace, say:


> DOM,    SIZE,        1.000000E+01, 2.000000E+00, 1.000000E+00
by:


XULAST=1.000000E+01; YVLAST=2.000000E+00; ZWLAST=1.000000E+00

> DOM,    SIZE,        XULAST,YVLAST,ZWLAST
for the q1ear, eardat ( and, in interactive mode, q1 ) files would remain identical.

Similarly, it would be permissible to declare, set and use new variables, for example:

Real(xdom,ydom,zdom)

xdom=10.;ydom=2.;zdom=1.

> dom,size,xdom,ydom,zdom
Once again, the result would be identical.

Why is this important? Because it provides a way to protect user-provided settings from the forgetfulness of the VR-Editor.

If the above settings had been placed in the q1 file itself, they would not have appeared in the q1 written by the VR-Editor; in effect, they would have been wiped out.

However, the Editor has no influence on v100obs.htm, which remains intact.

4.3 The use of arrays

Having recognised that any PIL statements can be both used and preserved, let us go further, by re-writing the v100obs.htm as follows:



array(nam,3) ! for the names of the three objects

array(pos.3.3) ! for the x,y,and,z coordinates of the three objects

array(size.3.3)  ! for the x,y,and,z sizes of the three objects

followed by:


nam(1)=B1

pos(1,1) =0.0E+00; pos(1,2) = 0.0E+00; pos(1,3) = 0.0E+00

size(1,1)=0.0E+00; size(1,2)= 2.0E+00; size(1,3)= 1.0E+00

pos(2,1) =5.0E+00; pos(2,2) = 0.0E+00; pos(2,3) = 0.0E+00

size(2,1)=0.0E+00; size(2,2)= 2.0E+00; size(2,3)= 1.0E+00

pos(3,1) =1.0E+01; pos(3,2) = 0.0E+00; pos(3,3) = 0.0E+00

size(3,1)=0.0E+00; size(3,2)= 2.0E+00; size(3,3)= 1.0E+00



> OBJ1,   NAME,        B1

> OBJ1,   POSITION,    pos(1,1) , pos(1,2) , pos(1,3)

> OBJ1,   SIZE,        size(1,1), size(1,2), size(1,3)

> OBJ1,   CLIPART,     cube3t

> OBJ1,   ROTATION24,        1

> OBJ1,   TYPE,        INLET

> OBJ1,   PRESSURE,      0.000000E+00

> OBJ1,   VELOCITY,      1.800000E+01, 0.000000E+00, 0.000000E+00

> OBJ1,   TEMPERATURE,   0.000000E+00

 

> OBJ2,   NAME,        B2

> OBJ2,   POSITION,    pos(2,1) , pos(2,2) , pos(2,3)

> OBJ2,   SIZE,        size(2,1), size(2,2), size(2,3)

> OBJ2,   CLIPART,     cube11

> OBJ2,   ROTATION24,        1

> OBJ2,   TYPE,        PLATE

> OBJ2,   POROSITY,      1.500000E-01

> OBJ2,   RESISTANCE,    4.000000E-01

> OBJ2,   SIDE,        BOTH

 

> OBJ3,   NAME,        B3

> OBJ3,   POSITION,    pos(3,1) , pos(3,2) , pos(3,3)

> OBJ3,   SIZE,        size(3,1), size(3,2), ,size(3,3)

> OBJ3,   CLIPART,     cube12t

> OBJ3,   ROTATION24,        1

> OBJ3,   TYPE,        OUTLET

> OBJ3,   PRESSURE,      0.000000E+00

> OBJ3,   TEMPERATURE,  -1.026000E+04

> OBJ3,   COEFFICIENT,   1.000000E+03



4.4 Use of PIL relations

The exploitation of this idea is illustrated by i201obsa.htm, which represents the objects employed in FLAIR-library case 1201 as shown below

However, the arrays used there are not strictly needed; and a more compact representation of the same data is provided by i201obsb.htm

Inspection of that file permits the following conclusions to be drawn:

  1. In comparison with the object-related section of a q1 file created by the VR-Editor, or indeed with the pob files mentioned above, it is much easier to read, The reason is that understandable variable names, such as 'roomhigh' and 'doorwide' are used in place of numbers.

  2. Moreover combinations of these variables are employed, as in the lines:
    
    
    > OBJ,    NAME,        wall-l2
    
    > OBJ,    POSITION,    0.0, suppypos+suppwide, 0.0
    
    > OBJ,    SIZE,        roomhigh, roomwide-suppwide-suppypos,0.0
    
    
    which describe the part of the 'low' wall which lies immediately beneath the air-supply aperture.

  3. The file therefore allows data to be specified in a relational manner; it can thus be used for the generation of many instances of a class of input files, each being distinguished by the choice of parameters; and not only geometrical ones.
    For example, the air-supply temperature appears as a parameter.

  4. It also allows PIL logical constructs to be used, as exemplified by the use of the Boolean variable 'fourwall'. This has been introduced so as to test whether the care taken by the originator of this library case to provide wall segments which do not cover the apertures was necessary. When fourwall is set true, four complete-surface walls are provided instead; but, because they appear earlier in the q1 than apertures ('supply', 'return' and 'open') it is latter which should take precedence.
    This does in fact occur; so the care was not necessary (except for cosmetic reasons); but the point to note here is that the test was very easy to make, and required no use of the VR-Editor at all.

4.5 Use of In-Form statements

The use of the INCL feature thus allows PIL logical and other constructs to be used freely; and examination of the settings associated with the FIRE objects shows that In-Form statements can also be used,
Thus the line:


> OBJ,infsrc_tem1, :fireflux: with if(tem1.lt.2000)

has been inserted so as to reflect the fact that heat generation ceases when the temperature rises to the adiabatic combustion temperature (here estimated to be 2000 degrees) because the fuel and oxygen become depleted locally.

The satellite reads the line, dutifully transmits the information via a SPEDAT line to the solver, and, if it is working in the 'silent' mode, lets line incl(i201obsb.htm) remain in the q1 file.

If it is working in interactive mode, it will write the numerical implications of the i201obs.htm into the q1 file instead of the incl statement; but the i201obs.htm file itself will remain intact.

4.6 Use of PRELUDE

PRELUDE is now able to interpret and display q1 files which contain INCL statements; and it will be developed in such a manner that 'obs' files of the kind described above, which were created by hand editing, will be capable of being created interactively.