Such objects have been characterised by:
When a user has completed the introduction of data, and quitted the interactive session, the results of his settings are recorded in the Q1 file.
Some typical examples are shown here.
The VR-Editor provides no way of extracting an object from an earlier-written Q1 file and bringing it into the current 'VR world'; and, even if it did, Q1 files are too case-specific to be convenient places to store re-usable-object information.
A user who is skilled in the art of editing VR-type Q1s could, in principle, use a word-processor to transfer blocks of information from one Q1 to another, prior to the new VR session.
However, such users are few; and CHAM has done nothing to encourage their activities.
With hindsight, it can be argued that this practice is so obvious that it should have been used from the beginning; but... 'better late than never'!
The new practice is especially useful when the objects are characterised, in practice, by rather few parameters, which may well remain the same from case to case, such as:
Section 1.2: New thinking about objects and
patches
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 ascribed to any file (of which there are still rather few) which contains non-geometric attributes in addition.
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, it has been decided to combine the capabilities of both the VR-Editor and Shapemaker, so that:-
The reasons for the tendency and its lessening are as follows:
Thus, if a solid rectangular grid-fitting object was to be represented, one initial-value patch would be used so as to specify the material index (i.e. PRPS value) of each cell within the block.
Then six additional 'wall-type' patches would be created, one for each surface, to express the frictional influence of those surfaces on the flow.
This practice has been unnecessary for many years; for the 'EGWF' (i.e. earth-generated-wall-function) feature enables the frictional influence to be deduced simply from knowledge of which cells contain fluid and which solid.
Thus the initial-value patch specifying the material appeared in Group 11 of the Q1 file, whereas the heat source would appear in Group 13.
The distinction between initial-condition and boundary-condition (i.e. group 11 and group 13) patches must have seemed like 'a good idea at the time'; but the distinction is artificial; and it needed not be perpetuated.
Section 1.3: The current status
PHOENICS already has a practice of loading objects from libraries of dat files. However, the only information stored in those object files was their shapes. Undoubtedly HVAC users would like to have a library of ready-for-use HVAC objects with complete information stored. Those model objects need only to be put in position and switched on.
PHOENICS 3.6 provides a library of POB files which store both shape and attributes. Those data files can be imported, modified, exported and retrieved through the newly developed Object Management Panel in the PHOENICS graphical user interface, VR-Editor, as shown below.
POB files can be created using either Shapemaker or VR-Editor. The Shapemaker program has been smoothly integrated into VR-Editor in PHOENICS 3.6 (see Chapter 7).
For PHOENICS 3.6, especially for FLAIR, the following HVAC model objects in the POB format were created,
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:
Click here to see a list of a cabinet assembly pob file which contains a master object B1 and three components B2, B3, and B4.