Encyclopaedia Index
Back to main contents

8. Moving objects

8.1 Distinction between VR and In-Form Objects

In-Form treats the motion of faceted (i.e. (i.e. VR) and parameterised (i.e. In-Form) objects differently. For the former, it provides the MOVOB keyword and POS and OFFSET functions, which obviate the need to employ a MOF file; but it leaves the momentum sources to be introduced by built-in MOFOR coding within the Earth solver.

For the latter it allows formulae describing the motion to appear as 'position', 'size' and 'rotation-angle' arguments of the object-describing functions, BOX, SPHERE etc; and it attaches momentum sources describing the effect of the motion explicitly in the Q1 file.

The built-in MOFOR coding is then not activated.

8.2 Faceted (i.e. VR) Objects

(a) MOVOB and POS

The MOVOB keyword of In-Form enables the motion of VR objects to be described by way of formulae. How it is used can be seen by inspection of core library case 360, which shows two objects moving along different trajectories through a fluid.

MOVOB statements make use of the POS function for setting the X, Y and Z coordinates and the rotation angles about the X, Y and Z axes of a moving object as functions of the time variable, TIM:

In case 360, the relevant statements are:

char(vel,gravt,times)

vel=10.; gravt=9.81; times=tim

(MOVOB of SPHERE1 is POS(:times:*:vel:,:times:*:vel:-0.5*:gravt:*:t$

imes:^2,0,0,0,0))

(MOVOB of SPHERE2 is POS(-:times:*:vel:,0,0,0,0,0))
These dictate a motion which, after the first time step appears thus:

Since the connection between the formula and the picture is not perfectly obvious, the following discussion is in order:

(c) The effect on the flow

The movement of the objects causes motions in the fluid also. This is achieved by the MOFOR feature of PHOENICS, about which the following remarks may suffice for present purposes:

(e) The OFFSET function

The OFFSET function is used when several objects move in pre-defined relative motion.

It is exemplified in library cases 381 and 382.

In-Form can calculate coordinates of a moving body position by the formula specified in "(MOVOB" In-Form statements which uses POS and OFFSET special functions. "(MOVOB" statement has next format:



 (MOVOB of VR_OBJ_NAME is special_FUNCTION() with PARENT=PARENT_NAME)

where VR_OBJ_NAME is the name of the VR object name which is connected to a appropriate object-related coordinate system for which the current attributes are set.

The special In-Form flag "!PARENT=PARENT_NAME" set the name of parent object-related coordinate systems. The OFFSET function describes the hierarchy part of the attribute settings. OFFSET is In-Form special function of declaring the frames of reference of object-related coordinate systems. Each new OFFSET function declares a new frame coordinate system and describes its position relative to its

parent system. OFFSET has the following format:
OFFSET(arg1,arg2,arg3)
where arg1 ,arg2 and arg3 are formulas f defining the of the new coordinate origin relative to those of its parent.

Each formula can contain the TIM variable which is current time in seconds at the current time step.

(f) Examples

Elementary motion: linear movement

The task is to describe the linear motion of a 2D rectangular object called "BLOCK" with uniform velocity of 3m/s in Z-direction of computational domain starting from a given initial, stationary position of the object.

The movement is along Z-axis. The initial position and the sizes of the BLOCK are specified in the Q1 file. Z coordinates of moving BLOCK object are described as

Z velocity component[m/s] * current time[s].The following picture displays the result. It is input-library case v119

.

The description the hierarchy part is not mandatory as there is only one moving object. Therefore it is enough to define the Z position of moving object in each time step, thus:



 (MOVOB of BLOCK is POS(0, 0, 3*TIM, 0, 0, 0))

More-complex movement: translation and rotation. The following image reveals what is to be simulated. It is input-library case v120

.

The case exemplifies the specification of the attributes for composite movement: the translation of a rotating block. It results in the effect of the rolling 2D rectangular object with the longitudinal (X-direction) velocity component of 0.5 m/s and the angular rotation about block centre line (Z-axis) of 30 degrees per seconds. The movement starts from the initially steady position defined in the Q1 file.

The hierarchy part is described as follows:



 (MOVOB of CHAM is OFFSET(0&0&0))

 (MOVOB of BLOCK is OFFSET(0.55&0.9&0) with PARENT=CHAM)

The OFFSET defines the position of the rotation axis relative to the root frame: it places the Z-axis in the middle of BLOCK initial position.

The movement is along X-axis and the rotation about Z-axis. X coordinates of moving BLOCK object and rotation angles are described as



 (MOVOB of BLOCK is POS(0.5*tim&0&0&0&0&-30*tim))

Independent motions: crossing paths

The case exemplifies the setting-up the attributes for the independent movements of two objects following their own linear trajectories in 2D, X-Y, computational space.

The movement of the first object, called SPHERE1, starts from its stationary position at the west-south corner and follows a prescribed parabolic trajectory. The velocity of SPHERE1 is 10 m/s and is defined by interaction of gravitation force.

The second object, SPHERE2, starts at east-south corner of the domain and follows the linear trajectory crossing the one from right to left. It has the constant velocity component of -10 m/s in X-direction and 3 m/s in Y-direction.

The movement starts from the initially steady position defined in the Q1 file.

The description the hierarchy part is not mandatory as two moving objects move inside one root coordinates system. Therefore it is enough only to define the position of moving objects in each time step.

The movement of SPHERE1 object is along diagonal of XY plane. X and Y coordinates of moving object are described as



 vel=10.; gravt=9.81

 (MOVOB of SPHERE1 is POS(tim*:vel:&tim*:vel:-0.5*:gravt:*tim^2&0&0&0&0))

The movement of SPHERE2 object is along X-axis from right to left. X coordinates of moving object are described as



 (MOVOB of SPHERE2 is POS(-tim*:vel:&0&0&0&0&0))

Connected objects: falling of a cracked wall

The case exemplifies the setting-up the attributes for the connected movements of two objects following their relative rotation in 2D, Y-Z, computational space.

The movement of the first object, called BLOCK, starts from its stationary position as a vertical wall with its base placed next to the middle of the bottom domain boundary. BLOCK is allowed to fall. It does so by rotating clockwise about X-axis of its south-high corner. The angular velocity of the fall is ,5 degrees per second.

Initially, the second smaller object, TIP, sits stationary on the top of BLOCK and can be regarded as a part of the wall. Once the whole wall starts to fall, it cracks and TIP begins to move in opposite direction by rotating counterclockwise about X- axis of the north-low corner of the BLOCK. The angular velocity of the TIP relative to the BLOCK is 180 degree per second.

The hierarchy part is described as follows:



 (MOVOB of BLOCK is OFFSET(0&0&2.1))



 (MOVOB of TIP is OFFSET(0&2.5&-0.5) with PARENT=BLOCK)

Two frames are defined: BLOCK is a parent joint, and TIP is the BLOCK's child.

The OFFSET of BLOCK defines the position of the rotation axis relative to the root frame: it places the origin of parent related coordinate frame at the south-high corner of BLOCK initial position.

The OFFSET of TIP defines the position of the rotation axis relative to the BLOCK frame: it places the origin of its coordinate frame at the north-low corner of BLOCK initial position.

The movement of BLOCK object is a rotation clockwise about X plane. Rotation angle is described as



 (MOVOB of BLOCK is POS(0&0&0&75*tim&0&0))

The movement of SPHERE2 object is a rotation counterclockwise about X plane. X coordinates of moving object are described as



 (MOVOB of TIP is POS(0&0&0&-180*tim&0&0))

Agitated reactor

Impellers are the units one most commonly associates with stirred reactors. The particular design considered here consists of the ROD, mounted on rotating vertical SHAFT. The rod carries two PADDLEs, which agitate the flow. As the impeller rotates it forces the surrounding fluid to rotate with it. The design with rotating paddles is used when "in-depth" mixing is a must.

The task of the exercise is to provide the attributes for connected movements of SHAFT-ROD-PADDLEs assembly following their relative rotation in 3D computational space. The angular velocity of the shaft is 60rpm.

The hierarchy part is described as follows:



 (MOVOB of CHAM is OFFSET(0&0&0))



 (MOVOB of SHAFT is OFFSET(0.15&0.25&0.25) with PARENT=CHAM)



 (MOVOB of ROD is OFFSET(0&0&0) with PARENT=SHAFT)



 (MOVOB of PADDLE1 is OFFSET(0&0&0) with PARENT=ROD)



 (MOVOB of PADDLE2 is OFFSET(0&0&0) with PARENT=PADDLE1)

Four frames are defined: SHAFT is a parent joint, and ROD, PADDLE1 and PADDLE2 are the SHAFT's children.

The OFFSET of SHAFT defines the position of the rotation axis relative to the ROOT frame: it places the origin of parent related coordinate frame at the middle of the SHAFT bottom face of its initial position.

The ROD and PADDLEs rotate about the same axis and has no freedom to move relatively to SHAFT. The OFFSETs of ROD and both PADDLEs are zero.

The movement of SHAFT object is a rotation clockwise about X plane. Rotation angle is described as



 (MOVOB of SHAFT is POS(0&0&0&360*tim&0&0))


8.3 Moving In-Form objects

Introduction

As has just been seen, In-Form's MOVOB keyword enables the motion of VR objects to be described; then activation of MOFOR sets the fluid in motion.

However, even before the existence of MOVOB, In-Form had a means of causing its own 'In-Form objects' to move, and to move the fluid with them. How this works will now be illustrated.

The fluid motion is achieved by attaching momentum sources to the In-Form objects. This was not in evidence when the MOVOB keyword was being used; but such sources were being introduced, nevertheless, behind the scenes.

Studying the 'source' statements associated with moving In-Form objects therefore throws some indirect light on how MOFOR works.


Contents

  1. Moving spheres
  2. Moving blades
  3. Moving valve
  4. Football trajectory, 2D
  5. Football trajectory, 3D

a. Moving spheres

So the 765 library case sets the linear motion of two hot spherical bodies to follow a horizontal path as

char(xce,yce,zce,radius; xce=.5+.5*(tim/100.-1); yce=0.1 + 01*(tim/100.-1); zce=.05; radius= .25

(INFOB at FIRST is SPHERE(:xce:,:yce:,:zce:,:radius:) with INFOB_1)

xce=.5+.25*(tim/100.-1); yce=1.5; zce=.05; radius= .25

(INFOB at SECOND is SPHERE(:xce:,:yce:,:zce:,:radius:) with INFOB_2)

It should be noted that the '(INFOB' statement can contain several long formulae. These can be spread over several lines in the Q1 file, with a '$' symbol as the last character of a line acting as a continuation marker.
When the Q1 file is rewritten at the end of an interactive section, lines longer than 68 characters will be automatically folded with a $ at column 68.

In the setting of long formulae it is recommended to use intermediate symbolical variables, as shown above.
The maximum possible length of a formula in any In-Form statement is 1000 symbols.

Heat sources within In-Form objects are represented thus:

(SOURCE of TEM1 at FIRST is 100. with INFOB_1)

(SOURCE of TEM1 at SECOND is 100. with INFOB_2)

b. Moving blades

The 770 library case set steady rotated In-Form object for simulation two paddle-stirred reactor. The rotated paddle is describes by In-Form:

REAL(ANGVL); ANGVL=4.*PI/1. ! Number of revolutions, 1/s.

REAL(X0,Y0); X0=0.5; Y0=0.5 ! X and Y coordinate of centre of impeller

char(ang,dx1,dx2,dy1,dy2); ang=:ANGVL:*TIM; dx1=:hsid2:*SIN(:ang:); dx2=:hsid1:*COS(:ang:) dy1=:hsid2:*COS(:ang:); dy2=:hsid1:*SIN(:ang:)

(INFOB at PATCH1 is BOX(:x0:-:dx1:-:dx2:,:y0:-:dy1:+:dy2:,0,0.1,0.7,10,0,0,:ang:) with INFOB_1)

The cartesian components of paddle velocity are set

(SOURCE of U1 at PATCH1 is :ANGVL:*(YG-:Y0:) with INFOB_1!FIXV)

(SOURCE of V1 at PATCH1 is :ANGVL:*(:X0:-XG) with INFOB_1!FIXV)


c. Moving valve

The inclined linear motion of rectangular object is submitted in 784 library case. Here four immobile In-Form objects (1, 2, 3 and 4) describe the geometry of blading sections of the chamber.

(INFOB at WHOLE is BOX(0.,.07,0.,.04,.03,1.,0.,0.,0.) with INFOB_1)

(INFOB at WHOLE is BOX(.07,0.,0.,.03,.04,1.,0.,0.,0.) with INFOB_2)

(INFOB at WHOLE is BOX(.04,.07,0.,.05,.03,1.,0.,0.,:-PI/4:) with INFOB_3)

(INFOB at WHOLE is BOX(.07,.04,0.,.03,.05,1.,0.,0.,:PI/4:) with INFOB_4)

Each of them is a solid body with appropriate installations inside objects

(STORED of VPOR at WHOLE is 0. with INFOB_1)

(SOURCE of U1 at WHOLE is 0. with INFOB_1!FIXV)

(SOURCE of V1 at WHOLE is 0. with INFOB_1!FIXV)

(STORED of VPOR at WHOLE is 0 with INFOB_2)

(SOURCE of U1 at WHOLE is 0. with INFOB_2!FIXV)

(SOURCE of V1 at WHOLE is 0. with INFOB_2!FIXV)

(STORED of VPOR at WHOLE is 0. with INFOB_3)

(SOURCE of U1 at WHOLE is 0. with INFOB_3!FIXV)

(SOURCE of V1 at WHOLE is 0. with INFOB_3!FIXV)

(STORED of VPOR at WHOLE is 0. with INFOB_4)

(SOURCE of U1 at WHOLE is 0. with INFOB_4!FIXV)

(SOURCE of V1 at WHOLE is 0. with INFOB_4!FIXV)

Two next In-Form objects (5 and 6) describe the geometry of a valve and a valve holder.

Description of a geometry of a valve

X and Y coordinates of a valve in the first time step

REAL(XVAL,YVAL); XVAL=0.065; YVAL=0.035

Moving of a valve during one time step

REAL(DMOV); DMOV=THROW/LSTEP; DMOV=DMOV/1.414

INTEGER(HLS,HLS1,HLS2); HLS=LSTEP/2; HLS1=HLS+1; HLS2=HLS+2

CHAR(CXP,CYP); CXP=:XVAL:-:DMOV:*(:HLS:-ABS(ISTEP-:HLS1:)); CYP=:YVAL:-:DMOV:*(:HLS:-ABS(ISTEP-:HLS1:))

(INFOB at WHOLE is BOX(:CXP:,:CYP:,0.,.01,.042,1.,0.,0.,:-PI/4:) with INFOB_5)

Description of a geometry of the valve holder

X and Y coordinates of the valve holder in the first time step

REAL(DXH,DYH); DXH=0.0113; DYH=0.0252

(INFOB at WHOLE is BOX(:CXP:-:DXH:,:CYP:+:DYH:,0.,.01,.11,1.,0.,0.,:PI/4:) with INFOB_6)

Fixation of the valve velocities into valve

(SOURCE of U1 at WHOLE is :UP: with INFOB_5!FIXV)

(SOURCE of V1 at WHOLE is :VP: with INFOB_5!FIXV)

Fixation of the valve velocities into valve holder

(SOURCE of U1 at WHOLE is :UP: with INFOB_6!FIXV)

(SOURCE of V1 at WHOLE is :VP: with INFOB_6!FIXV)


d. Football trajectory, 2D

The 766 library case illustrates the use of the In-Form 'SPHERE' function to simulate the effect on the motion of the air of a football following a prescribed parabolic trajectory. The In-Form object is presented as

char(xce,yce,zce,radius,gravt,vel,times); gravt=9.81;vel=14.14; times=tim; xce=0.5+:times:*:vel:/1.414; yce=0.5+:times:*:vel:/1.414-0.5*:gravt:*:times:^2; zce=.05; radius=.5

(INFOB at PATCH1 is SPHERE(:xce:,:yce:,:zce:,:radius:) with INFOB_1)

Where xce,yce and zce are the x,z and z coordinates. They are character variables which are evaluated in the In-Form statements because they are enclosed within colons.

Setting of U1 and V1 values into SPHERE is

char(usour,vsour); usour=:vel:/1.414; vsour=:vel:/1.414-:gravt:*:times:

(SOURCE of U1 at PATCH1 is :usour: with INFOB_1!FIXV)

(SOURCE of V1 at PATCH1 is :vsour: with INFOB_1!FIXV)


e. Football trajectory, 3D

The modeling of motion of spherical object in 3D space is submitted in 767 library case.

The In-Form object is presented as

char(xce,yce,zce,radius,gravt,vel,times) gravt=9.81; vel=14.14; times=tim;

xce=0.5+:times:*:vel:/1.414-0.5*:gravt:*:times:^2; yce=0.; zce=0.5+:times:*:vel:/1.414; radius=.5

(INFOB at PATCH1 is SPHERE(:xce:,:yce:,:zce:,:radius:) with INFOB_1)

Setting of U1, V1 and W1 values into SPHERE is

char(usour,wsour); usour=:vel:/1.414-:gravt:*:times:; wsour=:vel:/1.414

(SOURCE of U1 at PATCH1 is :usour: with INFOB_1!FIXV)

(SOURCE of V1 at PATCH1 is 0. with INFOB_1!FIXV)

(SOURCE of W1 at PATCH1 is :wsour: with INFOB_1!FIXV)


9. Print-out-related capabilities

9.1 LONGNAME

Variables which are introduced by way of In-Form statements beginning:
(STORED
are computed at each sweep through the solution domain. However, it sometimes occurs that values are required only for print-out purposes.

In these cases, In-Form makes use of the longname feature, which slightly pre-dates In-Form itself.

Syntax The syntax of longname statements can be deduced from the following example extracted from Input library case 763:



The LONGNAME feature provides reminders at RESULT-reading time

(LONGNAME of L3RH print as 3-Piece-Wise_Linear_Density)

(LONGNAME of L3EN print as 3-Piece-Wise_Linear_Viscosity)

(LONGNAME of L3CP print as 3-Piece-Wise_Linear_Specific_Heat)

(LONGNAME of L3CN print as 3-Piece-Wise_Linear_Conductivity)
This illustrates the use of longname as a reminder, which will be printed in the RESULT file as a field-values title, of what formula has been used for the calculation of density and other properties.

The similarity of the property and longname entries in this example should not however lead to the supposition that their treatment by PHOENICS is similar.

On the contrary; whereas what follows "is" in the property statement must a meaningful formula, that in the longname statement can be any string of characters. Equally acceptable, for example, would be:



(LONGNAME of VISL is my_new_formula)

9.2 PRINT

Another feature for a dump of variables values in a separate file is the '(PRINT' In-Form statement. It prints fields of standard dependent variables, or of user-defined single real variables calculated by Formula, in an INFOROUT file, which it places in the working directory.

Its format is:

(PRINT String_15 [at PatchName] is Formula)

where

String_15 is a character name with a length of 15 symbols;

PatchName is the name of a PATCH or VR object.

The length of String_15 together with PatchName is limited 15 symbols according to SPEDAT format.

The String_15 string is a comment of dumping variables.

Examples of use are:

(make pinlet) ! make user-defines single real variable

(store1 of pinlet is old(p1[1,1,1]) with if(isweep.eq.1)) ! define pinlet

(print of pin is pinlet) ! dump in INFOROUT file the pinlet value

(stored of pold is old(p1) with if(isweep.eq.1)) ! calculate POLD variable

(print of p1_old is pold) ! dump in INFOROUT file the fields of POLD

The 362 and 363 library cases use for a print-out of user-defined single real variables ASUM and TSUM.

(PRINT of Whole_high_area is ASUM)

(PRINT of IZ=NZ__Sum_TEM1 is TSUM)

9.3 Coefficients, residuals, corrections and exchange coefficients (gammas)

Contents:
  1. Coefficients
  2. residuals
  3. corrections
  4. exchange coefficients (gammas)
  5. manipulating coefficients

  1. Coefficients

    Users who are interested in the finite-volume equations solved by PHOENICS may print, and manipulate, terms which enter those equations.

    The typical form these equations is seen by clicking here.

    The terms which may be accessed are:

    The In-Form statements which enable them to be accessed have the form:

    (STORED of name is AX(varname))

    where:

    A complete set of examples can be found in input-library case 788

  2. Residuals

    The equation imbalances, i.e. the residuals, may be obtained in a similar manner; but for them the In-Form Statement is:

    (STORED of name is RESI(varname))

    Such statements are also to be seen in case 277.

  3. Corrections

    Solving the finite-volume equations produces "corrections", i.e. quantities which should be added, cell-by-cell, to the values of the solved-for variables in order to reduce the imbalances in the equations.

    To gain access to them, the appropriate statement is:

    (STORED of name is CORR(varname))

    Examples of accessing residuals and corrections are to be found in library cases: 249, concerned with 2D flow in a square cavity, and 768, concerned with 3D flow in a water heater.

    If on-line, click here for the temperature field, the residual field, and the correction field for case 249.

    Because the solution is well-converged, the values of both the residuals and the corrections are very small. This accounts for the irregularity of the residual field, of which the values have been reduced to the round-off error of the computer.

    This method of displaying residuals and corrections is more convenient than the older-established method, which involved giving the variable of which residuals and corrections were required a special name, ending with the % sign. That method however is still available.

    Warning

    It will sometimes occur that the corrections are printed as zero. The explanation is that the iterative computation will have stopped before the prescribed value of LSWEEP because the residuals had fallen below the reference value; therefore the solver, which is where the corrections are computed, may not have been entered.

    The cure is to set NPRINT to some value well below that of the number of sweeps at which solution terminated.

  4. Exchange coefficients (gammas)

    Also of interest to those who study the workings of the numerical-solution process are the exchange coefficients, i.e. diffusivities times densities, which enter (together with convection contributions) into the calculation of aN, aS, aE, aW etc. These too may be accessed by way of an In-Form statement, which is in this case:

    (STORED of name is GAMM(varname))

    This feature is illustrated in case 788.

  5. Manipulating the coefficients, etc

    Like other 3D-stored variables, the coefficients and other quantities mentioned in the present section may be:

    These possibilities give the user great power to intervene, if he or she wishes, in the solution process.


9.4 Eliciting debug

In-Form is supplied with extensive debug facilities, for the investigation of suspected errors.

These facilities are activated by use of the "read Q1" facility. Specifically, the Q1 file is supplied with, starting in column 3 or greater:

The full list of features is:

FULL
for all the following
FORMULA
for displaying the formula being parsed
INITIAL
for initial-value settings
STORED
for stored-value settings
MAKE
for the MAKE facility
PROPERTY
for property settings
SOURCE
for sources
LINE
for linearization aspects
XGRID
for grid-related settings
YGRID
ZGRID
TGRID
INFOB
for In-Form objects
MOFOR
for moving objects

As is obvious, debug of a particular kind is activated when t follows the feature name, and deactivated by f.

An f following debug deactivates all debug features.

All debug features are f by default.

In-Form debug print-out is governed by the same indices as is the older-established debug from EARTH, i.e. that elicited by the PIL variable debug, namely izdb1,izdb2, etc.

Library case case 768 provides an example.


10. Replacing READQ1

(a) READREALS, READINTS and READLOGS

The READQ1 features of PHOENICS allow variables which do not form part of the PIL set to be transmitted to EARTH. However, each variable requires one extra line to be inserted in the Q1 file.

In-Form allows up to 20 variables to be transmitted in a single line (possibly with 'continuation' effected by the $ sign), by means of the READREALS, READINTS, and READLOGS statements.

Their use is illustrated by the facility (introduced with PHOENICS-3.5) for changing turbulence-model constants, which is described here,

Suppose, for example, it were desired to employ the different constants:
CMU =0.6 CD =0.2 C1E =1.5
C2E =1.92 AK =0.4 EWM =9.0

This could be effected by inserting in the Q1 file the line:

(READREALS turconst 0.6 0.2 1.5 1.92 0.4 9.0)

When the satellite reads this line, it places in Q1EAR the line:



 SPEDAT(SET,REALREAD,TURCONST,C,0.6&0.2&1.5&1.92&0.4&9.0)
which is echoed in RESULT; and in EARDAT the line:


 REALREAD  TURCONST       C0.6&0.2&1.5&1.92&0.4&9.0 
This is then acted upon by the sequence of coding starting with IF(GETREALS in the subroutine INIVST, which duly interprets what it finds and records its work by printing the following in the RESULT file:


 CMU     = 6.000000E-01 CD      = 2.000000E-01

 C1E     = 1.500000E+00 C2E     = 1.920000E+00

 AK      = 4.000000E-01 EWAL    = 9.000000E+00

This example has shown how real variables may be transmitted. Integer and logical variables are transmitted by use of READINTS and READLOGS statements in the corresponding manner.

(b) Discussion

The following points need to be understood by those wishing to exploit this powerful new means of transmitting simulation-defining data:


11. In- Form and the VR-Editor

(a) Historical background


(b) Editing In-Form statements via the menu

The question has been answered by providing "In-Form" buttons in all appropriate menu panels of the VR-Editor, which access a newly-created 'In-form editor'.

One such button is shown here, for the top panel.

When that button is pressed, the Inform Editor appears.

Similar buttons appear on lower-level panels of the VR-Editor user-interface.


(c) Example; library case 360

There now follow several screen-capture images which show stages in the editing of the moving-body trajectory.

The existing Group 13 statements are viewed here

They are then changed by way of Notepad-like editing actions to this.

When they are what the user wants, they are saved.

This action places them in the phxx file which the VR Editor uses to store items which must be written to the final Q1, the relevant part of which is seen here:



  Echo InForm settings for Group 13

  inform13begin

char(xce,yce,zce,radius,gravt)

char(vel,times);

   ** Definition of the first moving In-Form Object

   SOME COMMENTS : Radius doubled; Gravity halved; That is all

radius=.5*2; gravt=9.81/2     ! Changes made on this line only

vel=10.;times=tim

xce=0.5+:times:*:vel:


(d) The future of the Inform Editor


End of main text of In-Form Documentation


Back to main contents