Implements complex structure in the R2 interface.
ATTA name !!attaname() and PCOM classification !!pcomClasses() are displayed in the AVEVA Pipe Stress Interface - R2: Settings window.
Both are provided as an example and placed in the PMLLIB path below userfunction. The !!attaname() as an example:

ATTA
!!attaname()
PCOM
!!pcomClasses()
AVEVA Pipe Stress Interface - R2: Settings
PMLLIB
userfunction
!!attaname()
-------------------------------------------------------
define function !!attaName() is string
if (!!ce.type inset('ATTA','ANCI','LUANCI')) then
return !!ce.stext & '-' & !!ce.:mdssuppfunc
else
return !!ce.name
endif
endfunction
-------------------------------------------------------


Functionality is available to support the transfer of Lap Joint Stub End (LJSE) elements to Rohr2.
The LJSE and the associated flange are combined into a single FLA component to be transferred to Rohr2.
The example displays a set of LJSE with associated lapped flanges.

When the LJSE is transferred to Rohr2, instead of being transferred as two separate components, the LJSE and FLAN are transferred as a single FLA entry in the Rohr2 neutral file. For example:

Because the two components from AVEVA E3D Design are combined into a single component, some of the transferred data is derived from the LJSE and some of the data is derived from the FLAN.
The table indicates how the data is transferred to the single FLA entry in the neutral file and what element the data is derived from.
Attribute
Expression
E3D Element
More Info
Component Description
NAME
LJSE
Material Description
MTXX
LJSE
Weight of elements (kg)
GWEI
FLAN + LJSE
Weight is the LJSE weight and FLAN weight added together.
Wall Thickness ppoint
1 (mm)
pwallt(1)
LJSE
Wall Thickness ppoint
2 (mm)
pwallt(2)
LJSE
Wall Thickness ppoint
3 (mm)
pwallt(3)
LJSE
Wall Thickness ppoint
4 (mm)
pwallt(4)
LJSE
Wall Thickness Outside Tolerance (%)
LJSE
Wall Thickness Inside Tolerance (%)
LJSE
Norm / Standard
FLAN
NORM obtained from the flange.
BTK
FLAN
The bolt thickness is taken from the flange.
Attribute
Expression
E3D Element
More Info
Component Description
NAME
LJSE

Material Description
MTXX
LJSE

Weight of elements (kg)
GWEI
FLAN + LJSE
Weight is the LJSE weight and FLAN weight added together.
Wall Thickness ppoint
1 (mm)
pwallt(1)
LJSE

Wall Thickness ppoint
2 (mm)
pwallt(2)
LJSE

Wall Thickness ppoint
3 (mm)
pwallt(3)
LJSE

Wall Thickness ppoint
4 (mm)
pwallt(4)
LJSE

Wall Thickness Outside Tolerance (%)

LJSE

Wall Thickness Inside Tolerance (%)

LJSE

Norm / Standard

FLAN
NORM obtained from the flange.
BTK

FLAN
The bolt thickness is taken from the flange.
Much like creating a set or weld neck flanges, the gasket is ignored completely and any geometry length of the gasket is added onto the length of one of the flanges in the flange set.

Attribute
Expression
E3D Element
More Info


This reference manual describes in detail the structure and methods of the internal databases used within AVEVA E3D Design. It is written for System Administrators who may be involved in maintaining projects, and the databases from which they are created.


Information is provided on project organization, the definition of teams and multiple database and the splitting of data across multiple databases.


In order to create data, you must first create a Project.
A Project consists of:
A project starts with just the System, Comms and Misc DBs.
You will then have to create other DBs for users to work on. The various visible DB types are:
System
Contains details on DBs, Multiple Databases (MDBs), teams etc in the project
Dictionary
Contains User Defined Attribute (UDA) and User Defined Element Type (UDET) definitions
Property
Contains units for different properties
Catalog
Contains Catalog and specification information
Model
Contains Plant design information
Draw
Contains drawing information
SPOOL
Contains spool information
Materials
Contains hull material information
Diagrams
Contains Schematic information
Transaction
Used by Global to record transactions
SCHEMATIC
Contains PI&D (Schematic) information
MANU
Contains detailed manufacturing data
NSEQ
Stores name sequences
System
Contains details on DBs, Multiple Databases (MDBs), teams etc in the project
Dictionary
Contains User Defined Attribute (UDA) and User Defined Element Type (UDET) definitions
Property
Contains units for different properties
Catalog
Contains Catalog and specification information
Model
Contains Plant design information
Draw
Contains drawing information
SPOOL
Contains spool information
Materials
Contains hull material information
Diagrams
Contains Schematic information
Transaction
Used by Global to record transactions
SCHEMATIC
Contains PI&D (Schematic) information
MANU
Contains detailed manufacturing data
NSEQ
Stores name sequences
Typically there will be many DBs of each type within a project.
An example of a simple project is as follows:

DBs may be included from other projects.
Each DB has a unique DB number. User DBs have numbers in the range 1-7000. The range 7000-8000 is reserved for AVEVA supplied databases. The range 8000-8192 is reserved for system databases.
The DB number is assigned to the DB on creation. You may specify the DB number. If not specified by you then the next available DB number is used.
There may never be two DBs with the same DB number in a single project. Thus to include a DB from another project, that DB number must be unused in the target project.
One each of System, Comms, and Misc Databases (DBs)
Multiple Design, Catalog, Drawing, and Dictionary DBs
Various picture files
One each of System, Comms, and Misc Databases (DBs)
One each of System, Comms, and Misc Databases (DBs)
Multiple Design, Catalog, Drawing, and Dictionary DBs
Multiple Design, Catalog, Drawing, and Dictionary DBs
Various picture files
Various picture files

System
Dictionary
Property
Catalog
SPOOL
Materials
Diagrams
Transaction


For ease of working DBs are grouped into Teams and Multiple Databases (MDBs). A Database (DB) belongs to one team, but may be in many MDBs. You must specify the MDB to work on when entering AVEVA E3D Design.
Details of DBs, teams, and MDBs are stored in the system database.
It can be seen that DB /A is only in MDB /X, whereas DB /B is in both MDB /X and /Y.
Team access controls fundamental write access. Members of Team1 will always have write access to DBs /A and /B, and read access to the remainder. For members of Team2 it will be the opposite way around.
If a DB is included from another project then it is always read only regardless of team membership.
These concepts are discussed in detail in the Administrator User Guide.

Administrator User Guide
Administrator User Guide


Theoretically there need only be one Database (DB) of each DB type. The main reasons for there being more are:
DBs are used as a fundamental means of access control. DBs are allocated to Teams, and only team members can modify a DB.
Whilst the multiwrite facilities allow many writers per DB, it eases contention if the writers are not all accessing the same DB.
The easiest way to run a Global project is to have different DBs writable at different locations.
The granularity of propagation and distribution in Global is per DB
It allows different permutations of Multiple Databases (MDBs).
It allows specific DBs to be hidden from sub contractors
Inclusion in other projects is done on a DB basis.
DBs are used as a fundamental means of access control. DBs are allocated to Teams, and only team members can modify a DB.
DBs are used as a fundamental means of access control. DBs are allocated to Teams, and only team members can modify a DB.
Whilst the multiwrite facilities allow many writers per DB, it eases contention if the writers are not all accessing the same DB.
Whilst the multiwrite facilities allow many writers per DB, it eases contention if the writers are not all accessing the same DB.
The easiest way to run a Global project is to have different DBs writable at different locations.
The easiest way to run a Global project is to have different DBs writable at different locations.
The granularity of propagation and distribution in Global is per DB
The granularity of propagation and distribution in Global is per DB
It allows different permutations of Multiple Databases (MDBs).
It allows different permutations of Multiple Databases (MDBs).
It allows specific DBs to be hidden from sub contractors
It allows specific DBs to be hidden from sub contractors
Inclusion in other projects is done on a DB basis.
Inclusion in other projects is done on a DB basis.


All data in a Dabacon database is stored in elements. Every element has a type, for example BOX. The type of element determines the attributes available on the element.
Each DB type allows a different set of element types.
Database attributes are described in Database Attributes
The elements are organized in a primary hierarchy. This is described in Database hierarchy.

BOX
BOX


Every element has a reference number, which is assigned when the element is created, and is unique to that element within the project. The reference number comprises two 32 bit integers. This is displayed in the form:
The first integer encodes the database number. This can be queried on the command line using Q DBNUMBER.
The second integer is a sequence number, starting at 0, and incrementing each time an element is created.
Thus, for example, the element with a reference number of =8193/0 will be the WORLD element (since this is always created first) created in Database (DB) 1.
The reference number is never changed once an element has been created.


In AVEVA E3D Design any element may be given a name. The name always starts with a '/'. At the user level, it is this name that is typically used to identify an element. Names may of course be changed, thus there is no guarantee that the element named '/FRED' today is the same as the element named '/FRED' yesterday.
An element need not have a name. For these elements AVEVA E3D Design creates a constructed name, consisting of the relative position in the hierarchy up to the first named element.
for example, BOX 2 OF SUBEQUIPMENT 1 OF /VESS1
Whilst the constructed name can be used to identify elements, its use is even more volatile than named elements, since the order of an element in a member's list may change.
You can duplicate the name of an element in a Design (DESI), Production (MANU), Schematic (SCHE) or Engineering (ENGI) databases in the current MDB. For example an element can be named `/FRED´ in the DESI database and a different element can be named ´/FRED´ in the MANU database.
AVEVA E3D Design is case sensitive and AVEVA recommends you stick to UPPERCASE characters. If you create an element named /FRED and at some later time you try to find it by typing /fred or /FreD, it will not be found.


At the user level there is a concept of current element.
Most AVEVA E3D Design commands act on the current element. This is often referred to as the CE. There is an extensive set of commands to navigate around the database changing the CE.


For most elements, the element type may never be changed after creation. For example, once created, an element of type SITE will always be of type SITE until deleted.
There are a few exceptions to this rule where it makes sense. For example, BENDs may be changed to ELBOs and vice versa.


Information is provided on the hierarchical data model, the user defined hierarchies, the element instances and the use case of primary hierarchy.


The database schemas in AVEVA E3D Design are fixed by AVEVA.
You may, however, customize the allowed hierarchy using User Defined Element Types (UDETs).
A UDET must be based on an existing system type. For example, you may define a UDET :PUMP which is based on an Equipment. By default, a UDET will have the same allowed members and allowed owners as a base type. This can be customised to be a subset of that allowed on the base type, for example, you might decide that SUBE are not allowed under a :PUMP even though they are allowed under an Equipment (EQUI).
UDETs based on zones may own other UDETs based on zones. This allows very flexible data models to be built.


A new database (DB) starts with a single world element with name '/*'. Users will then create instances of other element types. For example, a system user might create an initial hierarchy of sites and zones in a Model DB, leaving it to other users to create the actual Plant items.
An element instance will always be created within the primary hierarchy. For example, a new ZONE element must be created under an existing SITE. It cannot be created as a 'freestanding' element outside the existing hierarchy.
The actual element hierarchy can be viewed with the AVEVA E3D Design explorer.
All element instances within a multiple Database (MDB) are accessible at all times.


The primary hierarchy is used as follows:
It is used to create the 'constructed' name for unnamed elements.
When an element is deleted, all descendants in the primary hierarchy are deleted.
The COPY command will copy an element and all its primary descendants.
Claiming elements relies on the primary hierarchy.
Collections work on the primary hierarchy.
Most commands assume that the action is to be performed on the given element and its descendants in its primary hierarchy, for example,. adding a ZONE to a 3D view will add everything below that ZONE.
In the Design Database (DB), world positions and orientations are concatenated according to the primary hierarchy.
It is used to create the 'constructed' name for unnamed elements.
It is used to create the 'constructed' name for unnamed elements.
When an element is deleted, all descendants in the primary hierarchy are deleted.
When an element is deleted, all descendants in the primary hierarchy are deleted.
The COPY command will copy an element and all its primary descendants.
The COPY command will copy an element and all its primary descendants.
Claiming elements relies on the primary hierarchy.
Claiming elements relies on the primary hierarchy.
Collections work on the primary hierarchy.
Collections work on the primary hierarchy.
Most commands assume that the action is to be performed on the given element and its descendants in its primary hierarchy, for example,. adding a ZONE to a 3D view will add everything below that ZONE.
Most commands assume that the action is to be performed on the given element and its descendants in its primary hierarchy, for example,. adding a ZONE to a 3D view will add everything below that ZONE.
In the Design Database (DB), world positions and orientations are concatenated according to the primary hierarchy.
In the Design Database (DB), world positions and orientations are concatenated according to the primary hierarchy.


An element can only exist once in the primary data hierarchy. Secondary hierarchies, such as Group Sets (GPSETs), allow elements to appear more than once in the overall hierarchy. For example a PIPE will appear below a ZONE in the primary hierarchy. The same PIPE may also be added to a GPSET element. This is useful for collecting elements according to different criteria.
The diagram below shows a typical multi hierarchy where the secondary links are dotted.

Most commands will work on secondary hierarchies. For example, if /GPSET1 is added to a 3D view then this is equivalent to adding both /VESS1 and /PUMP2 to the 3D view. However, there are exceptions to this. In particular deleting a GROUP will not delete the GROUP members; thus deleting /GPSET1 will not delete /VESS1 and /PUMP2.
Unlike the Primary hierarchy, secondary hierarchies may span different databases (DBs).


Every element may have a number of attributes. All elements have the following attributes:
NAME
the element's name
TYPE
the element's type
LOCK
if set, then the element may not be modified
OWNER
the element's owner
MEMBERS
the current members of the element
NAME
the element's name
TYPE
the element's type
LOCK
if set, then the element may not be modified
OWNER
the element's owner
MEMBERS
the current members of the element
The remaining attributes vary depending on the element type. The Database Schema defines which attributes are available on an element type. The allowed attributes for an element type may be ascertained using Programmable Macro Language (PML) objects and other command queries.
Attributes may be one of the following types:
Ref
Ref Array
Position
Direction
Orientation
Attribute
ElementType (or Noun)
A 'Ref' type is a pointer to another element. For example, on a BRANCH element the Connection Reference (CREF) attribute points to the connected NOZZLE. The use of Ref attributes enables AVEVA E3D Design to model networks and other cross relationships.
The attribute type dictates how the attribute can be set with PML or specific syntax.

NAME
TYPE
LOCK
OWNER
MEMBERS


You can extend the allowed attributes for any element type, including a /ser Defined Element Type (UDET), by defining User Defined Attributes (UDAs). For example, you could define a UDA called :SUPPLIER of type string on all piping components. The newly defined UDA will then exist on all applicable elements, existing and new. If the definition of a UDA is changed then this will also apply to all existing instances.
Having defined a UDA, it is accessed in the same way as any other attribute.


In addition to the attributes stored on the database, there are a large number of pseudo attributes. The value of pseudo attributes is calculated at the time of making the query.
For example, the CUTLENGTH attribute on SCTN elements is a pseudo attribute calculated at the point of doing the query.
There is a lot of functionality presented via pseudo attributes. Currently there are over 1200 pseudo attributes.
Since the value of a pseudo attribute is calculated from other attributes, it is not generally possible to set their value directly.


Attributes and element types have a global name space. This means that an attribute such as XLEN will have an identical meaning wherever it exists.
Similarly if an element type is valid in more than one database type, the definition of the element type will be identical in each.


Some real attributes are simply numbers, counts, quantities etc. Others represent real physical quantities such as distances, areas, densities, angles etc. The type of physical quantity is called its physical dimension, often shortened in unambiguous contexts to its dimension. Real attributes (stored, derived, user defined etc.) can all be assigned a physical dimension and this determines the type of data stored in these attributes wherever and whenever they occur in the database. The most common dimensions of attributes are of length (internally set to either DIST or BORE). There are many others supported including density, mass, pressure, temperature, area, volume and angle.
The dimension of an attribute is held in the database in its (ambiguously named) UNIT field. It may be queried directly using the VAR ATTDEF attributeName UNIT syntax, and the !attribute.units() PML ATTRIBUTE object method, refer to PML ElementType Class.

PML ElementType Class
PML ElementType Class


Information is provided on database expressions and rules to define a database.


Database expression may be defined as a rule

Database expressions can be of the following types:
The contents of an expression may contain the standard operator and mathematical functions along with the names of attributes and element identification.
This expression simply multiplies the three attributes XLEN, YLEN, ZLEN together and then multiplies by two.
The attributes refer to the current element. If attributes of other elements are required then the OF syntax is used.
The 'OF' keyword makes sure that the AREA attribute is obtained from the owner of the current element rather than the current element itself.
The main uses of expressions are:
Database expressions are very similar to Programmable Macro Language (PML) expressions. The major difference is that database expressions may not contain other PML variables or functions. For example, (XLEN * !MYVAR) is not a valid database expression.
(XLEN * YLEN * ZLEN * 2)
(PURP EQ 'HS' AND AREA OF OWNER EQ 1)
algebraic
boolean (or logical)
text
Element ID
position
direction
orientation
algebraic
algebraic
boolean (or logical)
boolean (or logical)
text
text
Element ID
Element ID
position
position
direction
direction
orientation
orientation
Catalog parameterization
Template parameterization
Rules
Drafting line styles
User level collections and report
Catalog parameterization
Catalog parameterization
Template parameterization
Template parameterization
Rules
Rules
Drafting line styles
Drafting line styles
User level collections and report
User level collections and report


An attribute may be defined as a rule. For example, the attribute XLEN may be defined as a rule by the expression (YLEN * 2).
The OF syntax is often used in Rule expressions to refer to other elements, for example, (YLEN OF /FRED * 2)
The result of the rule is stored against the attribute as for other attributes.
There are commands to recalculate the rule.
Rules may be either static or dynamic. If static, then the rule result will only be recalculated on demand. If dynamic, then the result will be recalculated every time an attribute within the expression changes, for example, for the above rule, if YLEN is modified, then XLEN will be recalculated automatically. The dynamic linkage of rules may be across elements and across Databases (DBs).


Information is provided on the possibilities to dump out the database using data listings and the Reconfigurer.


Data listings (DATALs) capture the state of the database in the form of AVEVA E3D Design commands. All element data including all attributes, User Defined Attributes (UDAs) and rules will be captured. They are similar in concept to Extensible Markup Language (XML) output. These files can then be read back in via the command line.
Data listings are used as follows:
Long term archiving
Copying parts of a Database (DB) between projects
For general information.
Long term archiving
Long term archiving
Copying parts of a Database (DB) between projects
Copying parts of a Database (DB) between projects
For general information.
For general information.


Reconfigurer is similar to Data Listing (DATAL) in that it dumps out the state of the data.
The data can be dumped to either binary or text file. Using binary files is quickest.
Reconfigurer is faster than DATAL and is recommended if whole DBs or world level elements are to be transferred. DATAL or the copy facilities is recommended if lower level elements are to be transferred.


Data Access Control (DAC) is the mechanism that protects information handled by the system from accidental or unauthorised manipulation.
The basic access control available is known as 'Team Owning Databases'. It implements access control on database level by simply giving the members of the team owning the database full access and others read-only to data held in particular databases.
A more sophisticated access control is implemented in the form of Access Control Rights (ACRs). ACR allows the administrator of the system to apply a more fine grained access control over the model. The following figure illustrates the DAC database hierarchy.

An ACR is defined through two entities:
A PEROP defines the access rights given for a number of pre-defined operations for one or more elements.
One or more ACRs may be assigned to a user granting and denying access to the model.
For a user to gain update access to a particular element two rules apply:
Management tools are available for DAC through the Admin module. Control of DAC is also available through Programmable Macro Language (PML).
A PEROP consists of three parts:
The PEROP may further restrict the elements it applies to by a qualifying condition. The qualifying conditions is an AVEVA E3D Design statement that should evaluate to true to qualify the PEROP.
The following operations are available through PEROPs
Each of these operations may be set to
Allow
The operation is permitted
Disallow
The operation is not permitted
Ignore
The PEROP does not define whether this operation is permitted or not
Allow
The operation is permitted
Disallow
The operation is not permitted
Ignore
The PEROP does not define whether this operation is permitted or not
Optionally the PEROP may further restrict which attributes it allows modification to by specifying a list of attributes that it either includes or excludes from allowing modification to.
The PEROP also holds the message that the system will issue if the PEROP denies attempted operation.
A ROLE, which is a collection of rules called Permissible Operations (PEROPs).
A SCOPE, which defines to what part of the model the ROLE applies. The SCOPE may be an expression, for example, all ZONE WHERE (FUNC eq 'TEAMA')
A ROLE, which is a collection of rules called Permissible Operations (PEROPs).
A ROLE, which is a collection of rules called Permissible Operations (PEROPs).
A SCOPE, which defines to what part of the model the ROLE applies. The SCOPE may be an expression, for example, all ZONE WHERE (FUNC eq 'TEAMA')
A SCOPE, which defines to what part of the model the ROLE applies. The SCOPE may be an expression, for example, all ZONE WHERE (FUNC eq 'TEAMA')
At least one PEROP in a ROLE assigned to a USER must grant the update operation.
No one PEROP must explicitly deny the operation.
At least one PEROP in a ROLE assigned to a USER must grant the update operation.
At least one PEROP in a ROLE assigned to a USER must grant the update operation.
No one PEROP must explicitly deny the operation.
No one PEROP must explicitly deny the operation.
The Element it applies to
The operations which can be performed on those elements
Optionally the Attributes that may be modified.
The Element it applies to
The Element it applies to
The operations which can be performed on those elements
The operations which can be performed on those elements
Optionally the Attributes that may be modified.
Optionally the Attributes that may be modified.
Create
Modify
Delete
Claim
Issue
Drop
Output
Export
Copy
Create
Create
Modify
Modify
Delete
Delete
Claim
Claim
Issue
Issue
Drop
Drop
Output
Output
Export
Export
Copy
Copy

Allow
Disallow
Ignore


The following checks are applied to all modifications:
The claiming process is described in Claiming Elements.
Check access control
Check that the DB is open in write
Check that the element's LOCK flag is false
If a multiwrite Database (DB) then do a claim check, and claim if needed
Check access control
Check access control
Check that the DB is open in write
Check that the DB is open in write
Check that the element's LOCK flag is false
Check that the element's LOCK flag is false
If a multiwrite Database (DB) then do a claim check, and claim if needed
If a multiwrite Database (DB) then do a claim check, and claim if needed


The engineering integrity is always maintained for any database modification.
The integrity checks are applied below the database interface. Thus modifying the database is always safe whether done via PML commands or C#.
The checks are applied to individual attributes and element types. For example the OBST attribute can only ever be set to 0,1 or 2. AVEVA E3D Design will always check that this is the case prior to allowing the modification.


Elements may be created. They are always created one at a time, and may only be created at a legitimate point in the primary hierarchy.
On creation, a unique reference number will be assigned. The method by which the default reference number is generated is described in User Defined Hierarchies.
It is possible to create an element with a specified reference number, provided it is unused and valid for the Database (DB). This functionality is provided for certain specialized situations (such as recreating an exact copy of a DB, so that all references to elements from other DBs remain valid), and is not recommended for general use.
The attributes will be set to their default values. In some cases the default attribute values are cascaded down from the owning element.

User Defined Hierarchies
User Defined Hierarchies


Elements may be deleted. All elements below the deleted element in the primary hierarchy will also be deleted.
Reference numbers of deleted elements are never reused.


Elements may be copied. There are options to copy a single element or an element and all its descendants. Elements may be copied between Databases (DBs). Any cross references entirely within the copied structure will be updated to point to the newly created elements.
Elements are always copied on top of an existing element of the same type.
There are various options on the copy command to allow:
Additional potential errors at create are:
The copied elements to be renamed according to a given criteria
Whether any attribute rules are to be rerun on the copied element. (Rules are described in Reconfigurer)
The copied elements to be renamed according to a given criteria
The copied elements to be renamed according to a given criteria
Whether any attribute rules are to be rerun on the copied element. (Rules are described in Reconfigurer)
Whether any attribute rules are to be rerun on the copied element. (Rules are described in Reconfigurer)
The element may not be copied to an element of a different type
The element may not be copied to an element of a different type
The element may not be copied to an element of a different type

Reconfigurer
Reconfigurer


Elements may be moved to a different point in the Database (DB) or to a different DB.
The Element and all its descendants will be moved.
If the element is moved to a different DB, then its reference number is changed. All reference attributes pointing to the moved structure will be updated.
Additional potential errors at move are:
The element is not allowed in the members list of the new owner
The element is not allowed in the members list of the new owner
The element is not allowed in the members list of the new owner


The following checks are applied when modifying attributes:
Sometimes modifying one attribute will actually cause a number of attributes to change. There are two main cases where this might happen:
The integrity of cross referenced attributes is maintained when one end of the connection is changed. Changing one end of a connection will also change the following:
In essence, changing one value may result in four elements being updated.
For example, consider the following:

After setting the CREF on /N1 to /B1, the end result is:


A dynamic rule will automatically respond to changes which affect the attributes referred to in the rule.
For example, we set a rule on YLEN of /MYBOX to be (YLEN OF /FRED * 2). Thus if YLEN on /FRED changes then YLEN on /MYBOX will be updated automatically. However there are reasons why the automatic propagation of dynamic rules may fail, as follows:
Note also that only static rules are not automatically updated. For these reasons there are commands to verify that rule results are up to date.


Information is provided on the handling of a session, for example, defining a session by saving or getting the work, creating a stamp, displaying the session history, setting a comparison date and merging changes.


A new session is created for every flush operation. Thus it is much better to flush a large number of elements in one go rather than flush them individually.


Global allows Databases to be spread across different locations

Global allows Databases (DBs) to be spread across different locations. Global propagates changes from one location to another. The Global daemon does the propagation.
With global, there may be copies of a database or extract at multiple locations, but only one copy may be writeable. A database is said to be primary at a given location if it is writeable there, and secondary if it is not. A DB may be made primary at any location.
Different extracts from the same extract family may be primary at different locations. This allows multiple different locations to modify the same DB.


Changes made to a primary database (DB) are propagated to the read only secondary DBs. The propagation algorithm just sends the new sessions. For example:

If this case the propagation algorithm will send the sessions 20 to 39 to the secondary location.


A Programmable Macro Language (PML) attribute instance may be created for a system attribute or a User defined Attribute (UDA).
The class should not be confused with the attribute value. The actual Attribute value for a particular Element can only be accessed via the DBREF class or via the QUERY command. Comparing two Attributes just compares whether they identify the same attribute, the comparison does not look at attribute values in any way.


The Attribute instance can then be used for querying the ‘meta data’, that means, data about data. The methods of the class allow the following to be queried.
String Type()
Attribute type
String Name()
Attribute name
String Description()
Attribute description
Int Hash()
Attribute hash value
int Length()
Attribute length
bool IsPseudo()
Whether pseudo or not
bool IsUda()
Whether a User defined Attributes (UDA) or not
string querytext()
As output at the command line when querying attribute
string units
Either BORE, DISTANCE or NONE
Returns the unit field of the attribute which is the string of the hash code of the dimension of the attribute (BORE, DIST, MASS, ANGL, or for numbers of no physical quantity NONE). For UDAs it is the value of the UDA Type (UTYP) attribute.
bool Noclaim()
Whether attribute can be changed without doing a claim
ElementType array
ElementTypes
List of Elements for which the attribute is valid. This only works for UDAs
Real array limits
Min/Max values for real/int types
String array
ValidValues(ElementType)
List of valid for text attributes. The list may vary with element type
string DefaultValue
(ElementType)
Attribute default. This only works for UDAs
string Category()
Determines the grouping of attributes on the ‘Attribute Utility’ form
bool hyperlink()
if true then the attribute value refers to an external file
bool connection()
if true then the attribute value will appear on the reference list form
bool hidden()
If true then attribute will not appear on the Attribute utility form or after ‘Q ATT’
bool protected()
if true then attribute is not visible if a protected Databases (DB).
String Type()
Attribute type
String Name()
Attribute name
String Description()
Attribute description
Int Hash()
Attribute hash value
int Length()
Attribute length
bool IsPseudo()
Whether pseudo or not
bool IsUda()
Whether a User defined Attributes (UDA) or not
string querytext()
As output at the command line when querying attribute
string units
Either BORE, DISTANCE or NONE
Returns the unit field of the attribute which is the string of the hash code of the dimension of the attribute (BORE, DIST, MASS, ANGL, or for numbers of no physical quantity NONE). For UDAs it is the value of the UDA Type (UTYP) attribute.
bool Noclaim()
Whether attribute can be changed without doing a claim
ElementType array
ElementTypes
List of Elements for which the attribute is valid. This only works for UDAs
Real array limits
Min/Max values for real/int types
String array
ValidValues(ElementType)
List of valid for text attributes. The list may vary with element type
string DefaultValue
(ElementType)
Attribute default. This only works for UDAs
string Category()
Determines the grouping of attributes on the ‘Attribute Utility’ form
bool hyperlink()
if true then the attribute value refers to an external file
bool connection()
if true then the attribute value will appear on the reference list form
bool hidden()
If true then attribute will not appear on the Attribute utility form or after ‘Q ATT’
bool protected()
if true then attribute is not visible if a protected Databases (DB).
String Type()
Attribute type
String Name()
Attribute name
String Description()
Attribute description
Int Hash()
Attribute hash value
int Length()
Attribute length
bool IsPseudo()
Whether pseudo or not
bool IsUda()
Whether a User defined Attributes (UDA) or not
string querytext()
As output at the command line when querying attribute
string units
Either BORE, DISTANCE or NONE
Returns the unit field of the attribute which is the string of the hash code of the dimension of the attribute (BORE, DIST, MASS, ANGL, or for numbers of no physical quantity NONE). For UDAs it is the value of the UDA Type (UTYP) attribute.
bool Noclaim()
Whether attribute can be changed without doing a claim
ElementType array
ElementTypes
List of Elements for which the attribute is valid. This only works for UDAs
Real array limits
Min/Max values for real/int types
String array
ValidValues(ElementType)
List of valid for text attributes. The list may vary with element type
string DefaultValue
(ElementType)
Attribute default. This only works for UDAs
string Category()
Determines the grouping of attributes on the ‘Attribute Utility’ form
bool hyperlink()
if true then the attribute value refers to an external file
bool connection()
if true then the attribute value will appear on the reference list form
bool hidden()
If true then attribute will not appear on the Attribute utility form or after ‘Q ATT’
bool protected()
if true then attribute is not visible if a protected Databases (DB).
Note:
We do yet not support direct usage of this class in other syntax.

String Type()
String Name()
String Description()
Int Hash()
int Length()
bool IsPseudo()
bool IsUda()
string querytext()
string units
bool Noclaim()
ElementType array
ElementTypes
Real array limits
String array
ValidValues(ElementType)
string DefaultValue
(ElementType)
string Category()
bool hyperlink()
bool connection()
bool hidden()
bool protected()
Note
:


An ElementType instance may be created for a system Element type or a User Defined Element Type (UDET).
The ElementType instance can then be used for querying the ‘meta data’. which means,. data about data. The methods of the class allow the following to be queried.


The available methods are:
string Name()
Name of element type
string Description()
Description of element type
int Hash()
Hash value
bool IsUdet()
Whether a User Defined Element Type (UDET) or not
Attribute array
systemAttributes()
List of system attributes (excludes User defined Attributes (UDAs))
string array DbType()s
List of valid Database (DB) types
string ChangeType()
Indicates if an element of this type may have it’s type changed
ElementType SystemType()
for UDETs this is the base type
ElementType array
UDETs derived from this type
bool Primary()
Whether the element is primary or not
ElementType array
MemberTypes()
Valid members, including UDETs
ElementType array
ParentTypes()
Valid parents, including UDETs
string Name()
Name of element type
string Description()
Description of element type
int Hash()
Hash value
bool IsUdet()
Whether a User Defined Element Type (UDET) or not
Attribute array
systemAttributes()
List of system attributes (excludes User defined Attributes (UDAs))
string array DbType()s
List of valid Database (DB) types
string ChangeType()
Indicates if an element of this type may have it’s type changed
ElementType SystemType()
for UDETs this is the base type
ElementType array
UDETs derived from this type
bool Primary()
Whether the element is primary or not
ElementType array
MemberTypes()
Valid members, including UDETs
ElementType array
ParentTypes()
Valid parents, including UDETs
string Name()
Name of element type
string Description()
Description of element type
int Hash()
Hash value
bool IsUdet()
Whether a User Defined Element Type (UDET) or not
Attribute array
systemAttributes()
List of system attributes (excludes User defined Attributes (UDAs))
string array DbType()s
List of valid Database (DB) types
string ChangeType()
Indicates if an element of this type may have it’s type changed
ElementType SystemType()
for UDETs this is the base type
ElementType array
UDETs derived from this type
bool Primary()
Whether the element is primary or not
ElementType array
MemberTypes()
Valid members, including UDETs
ElementType array
ParentTypes()
Valid parents, including UDETs
Note:
We do yet not support direct usage of this class in other syntax.

string Name()
string Description()
int Hash()
bool IsUdet()
Attribute array
systemAttributes()
string array DbType()s
string ChangeType()
ElementType SystemType()
ElementType array
bool Primary()
ElementType array
MemberTypes()
ElementType array
ParentTypes()
Note
:


There are a number of pseudo attributes that return values according to the element type, as follows:
HLIS
WORD(2000)

List of all possible types in owning hierarchy
LIST
WORD(2000)

List of all possible member types
LLIS
WORD(2000)

List of all possible types in member hierarchy
OLIS
WORD(2000)

List of all possible owner types
REPTXT
STRING

Reporter text used for element type

Attribute Name
Data Type
Qualifier
Description
HLIS
WORD(2000)
List of all possible types in owning hierarchy
LIST
WORD(2000)
List of all possible member types
LLIS
WORD(2000)
List of all possible types in member hierarchy
OLIS
WORD(2000)
List of all possible owner types
REPTXT
STRING
Reporter text used for element type


This chapter describes the commands to create, copy and modify database elements.


As well as accessing the current content of a Database (DB), you may also (if you have Read/Write access rights) modify a DB in any of the following ways:
Create a new element at an appropriate level of the DB hierarchy; refer to Create a New Element.
Delete an element from the DB hierarchy; refer to Delete an Element.
Reorganize the hierarchy, refer to Reorganize the DB Hierarchy:
by rearranging members of an element into a different list order.
by moving an element from one part of the hierarchy to another;
Define the attributes and offspring of a new element by copying the corresponding attribute, settings and member lists from another element; refer to Copy Attributes from One Element to Another.
Create a new element at an appropriate level of the DB hierarchy; refer to Create a New Element.
Create a new element at an appropriate level of the DB hierarchy; refer to Create a New Element.
Delete an element from the DB hierarchy; refer to Delete an Element.
Delete an element from the DB hierarchy; refer to Delete an Element.
Reorganize the hierarchy, refer to Reorganize the DB Hierarchy:
by rearranging members of an element into a different list order.
by moving an element from one part of the hierarchy to another;
Reorganize the hierarchy, refer to Reorganize the DB Hierarchy:
Define the attributes and offspring of a new element by copying the corresponding attribute, settings and member lists from another element; refer to Copy Attributes from One Element to Another.
Define the attributes and offspring of a new element by copying the corresponding attribute, settings and member lists from another element; refer to Copy Attributes from One Element to Another.

Create a New Element
Delete an Element
Reorganize the DB Hierarchy
Copy Attributes from One Element to Another
Create a New Element
Delete an Element
Reorganize the DB Hierarchy
Copy Attributes from One Element to Another


To create a new element within an existing Database (DB), you must first make sure that the Current Element (CE) is at a level within the hierarchy which can legally own the element to be created. For example, a Site can own a Zone, but it cannot own a Valve. To create a new Valve, you must be at Branch level. You must therefore navigate to the correct level by using one of the command options described in Database Navigation and Query Syntax.
You can then create a new element, set its attributes and, if required, create further elements as its members.
If you create an element without explicitly identifying its position in the Member List of the Current Element, the new element is inserted immediately after the Current List Position. To use this option, enter the command
NEW element_type element_name
(element_name is optional)
NEW element_type element_name
(element_name is optional)
For example, if the Current List Position is at member 4 (/VALV1) of the Member List.

The command
adds a new Tee at list position 5 (between /VALV1 and /ELBO2) and names it /TEE2. The Member List of /BRAN1 thus becomes

To insert the new Tee as the first or last component in the Member List, access the Branch Head or Tail, respectively, before giving the NEW TEE command.
To create a new element at a specified list position, identify a list position adjacent to the required position and state which side of it the newly-created element is to go. The command syntax is one of the following:
where element_name is again optional and where list_position may be specified in any of the ways described in Database Navigation and Query Syntax.
Consider the following examples. Starting from the configuration shown, any of these commands creates a new Tee between /ELBO3 (list position 7) and /FLAN2 (list position 8):
NEW TEE AFTER /ELBO3
Specify name or refno
NEW TEE BEFORE 8
Specify list position number
NEW TEE BEFORE FLAN 2
Specify member type and number (second Flange in the list)
NEW TEE AFTER LAST ELBO
Specify first or last member of a given type (last Elbow in the list)
NEW TEE AFTER NEXT 3
Specify position relative to Current List Position
NEW TEE BEFORE LAST FLAN
Specify first or last member of a given type
NEW TEE AFTER /ELBO3
Specify name or refno
NEW TEE BEFORE 8
Specify list position number
NEW TEE BEFORE FLAN 2
Specify member type and number (second Flange in the list)
NEW TEE AFTER LAST ELBO
Specify first or last member of a given type (last Elbow in the list)
NEW TEE AFTER NEXT 3
Specify position relative to Current List Position
NEW TEE BEFORE LAST FLAN
Specify first or last member of a given type
The new Tee, which is unnamed, becomes list member 7, /ELBO3 becomes list member 8, /FLAN2 becomes list member 9, and so on.
To create a new top level element in a specific database there is a DB keyword available in the syntax of the ‘NEW’ command as follows:
NEW element_type element_name DB database_name
where element_name is again optional and where the database_name is expressed as a fully qualified database name,for example, team/database.
The following command will create a new SITE named /MYSITE in the MYTEAM/MYDB database.
NEW element_type element_name
(element_name is optional)
NEW TEE AFTER /ELBO3
Specify name or refno
NEW TEE BEFORE 8
Specify list position number
NEW TEE BEFORE FLAN 2
Specify member type and number (second Flange in the list)
NEW TEE AFTER LAST ELBO
Specify first or last member of a given type (last Elbow in the list)
NEW TEE AFTER NEXT 3
Specify position relative to Current List Position
NEW TEE BEFORE LAST FLAN
Specify first or last member of a given type
NEW TEE /TEE2
NEW    element_type element_name BEFore list_position
NEW    element_type element_name AFTer list_position
NEW SITE /MYSITE DB MYTEAM/MYDB
Note:
The Q LIST query will tell you which element types you can create as members of the Current Element.

Database Navigation and Query Syntax
Database Navigation and Query Syntax
Database Navigation and Query Syntax
Note
:
NEW element_type element_name
Database Navigation and Query Syntax
NEW TEE AFTER /ELBO3
NEW TEE BEFORE 8
NEW TEE BEFORE FLAN 2
NEW TEE AFTER LAST ELBO
NEW TEE AFTER NEXT 3
NEW TEE BEFORE LAST FLAN
NEW
element_type element_name
DB
database_name
element_name
database_name
team/database


You can delete either the entire Current Element or some or all of its offspring. When you delete the Current Element, you also delete all of its offspring (that is, its members, their members, etc.) from the hierarchy. The command must therefore be used with care. When an element has been deleted, its Owner becomes the new Current Element.
As a safeguard against accidental deletion of parts of a DB, the deletion function operates only on the Current Element. As further safeguards, the DELETE command word must be entered in full and the command syntax requires that you confirm the generic type of the Current Element. Furthermore, access to the required element and its subsequent deletion must be specified in two separate command lines.
To delete the Current Element and all its offspring, enter
For example, to delete a Nozzle, make the Nozzle the Current Element and then enter
The Equipment which owned the Nozzle becomes the Current Element.
To delete a complete Zone, including all Equipment, Piping, Structures etc. owned by it, make the Zone the Current Element and then enter
The Site which owned the deleted Zone becomes the Current Element.
To delete only specified members of the Current Element, use one of the following forms of the command syntax:
DELETE element_type MEMbers
(deletes all members)
DELETE element_type MEMbers integer
(deletes one member)
DELETE element_type MEMbers integer TO integer
(deletes a range of members)
(deletes all members)
(deletes one member)
(deletes a range of members)
Consider the following examples, where the Current Element is /BRAN1 with the Member List illustrated in Figure 10-2:
DELETE BRAN MEMBERS
Deletes all components from the Branch, leaving only the Branch Head and Tail
DELETE BRAN MEMBER 6
Deletes only /TEE1
DELETE BRAN MEMBERS 5 TO 7
Deletes /ELBO2, /TEE1 and /ELBO3
Deletes all components from the Branch, leaving only the Branch Head and Tail
Deletes only /TEE1
Deletes /ELBO2, /TEE1 and /ELBO3

DELETE element_type MEMbers
(deletes all members)
DELETE element_type MEMbers integer
(deletes one member)
DELETE element_type MEMbers integer TO integer
(deletes a range of members)
DELETE BRAN MEMBERS
Deletes all components from the Branch, leaving only the Branch Head and Tail
DELETE BRAN MEMBER 6
Deletes only /TEE1
DELETE BRAN MEMBERS 5 TO 7
Deletes /ELBO2, /TEE1 and /ELBO3
DELETE NOZZ
DELETE ZONE

DELETE
DELETE element_type MEMbers
DELETE element_type MEMbers integer
DELETE element_type MEMbers integer TO integer
DELETE BRAN MEMBERS
DELETE BRAN MEMBER 6
DELETE BRAN MEMBERS 5 TO 7


You can reorganize the structure of the Database (DB) hierarchy, without elements being added to or removed from its contents, in either of two ways:
In both cases elements and their offspring are transferred to new positions in the hierarchy. In the first case the element's owner remains unchanged, while in the second case the element's owner changes.
To rearrange the Member List of the Current Element (CE), use one of the commands:
where element_id specifies an element which is to be moved (which must be a member of the Current Element) and where list_position may be specified in any of the ways described in Database Navigation and Query Syntax.
If list_position is omitted, the intended position is assumed to be immediately after the Current List Position.
For example, starting with the previous Member List:

The command
moves /ELBO3 to position 5, immediately following the Current List Position, giving the new Member List

Starting from either of the above configurations, the command
moves /ELBO3 to position 3, immediately before /ELBO1, thus

To insert an existing element into the Member List of the Current Element, when it is not already a member of that list, use one of the commands
where element_id specifies an element which is to be moved (which may be anywhere within the DB hierarchy as long as it is at an appropriate level) and where list_position may be specified in any of the ways described in Database Navigation and Query Syntax.
If list_position is omitted, the intended position is assumed to be immediately after the Current List Position.
For example, starting with the simple hierarchy

the command
moves /PIPE2 (and all its offspring) to the position immediately following the Current List Position. Ownership of /PIPE2 passes from /ZONE2 to /ZONE1, resulting in the new hierarchy

REOrder element_id
REOrder element_id  BEFore list_position
REOrder element_id  AFTer  list_position
REORDER /ELBO3
REORDER    /ELBO3   BEFORE   FIRST   ELBO
INCLude element_id
INCLude element_id  BEFore list_position
INCLude element_id  AFTer  list_position
INCLUDE /PIPE2
By rearranging the order of the Member List of a single element
By relocating an element to a different part of the hierarchy
By rearranging the order of the Member List of a single element
By rearranging the order of the Member List of a single element
By relocating an element to a different part of the hierarchy
By relocating an element to a different part of the hierarchy

Database Navigation and Query Syntax
Database Navigation and Query Syntax
Database Navigation and Query Syntax
Lude element_id
INCLude element_id  BEFore list_position
INCLude element_id  AFTer  list_position
Database Navigation and Query Syntax


It is often convenient to create a new element as a copy of an existing element which has the same, or similar, attribute settings or members to those required. You do this in two stages:
When an element is 'cloned' in this way, all attributes are copied from the source element to the target element except NAME (which must be unique) and LOCK (which is always unlocked in the target element). Additionally, and this is what makes the facility so powerful, all offspring of the source element are copied as offspring of the target element.
You may specify automatic renaming of the Current Element and its offspring as part of the copying process. Without this the new elements will be unnamed, since AVEVA E3D Design does not permit two elements in the same Database (DB) hierarchy to have identical names. You may also choose to copy only the members (and their offspring) of the source element, leaving the attributes of the Current Element itself unchanged.
To copy a complete element and all of its offspring, after creating a new Current Element of an appropriate type, enter
where element_id identifies the source element to be copied.
For example, to create a new item of Equipment which is an exact replica of a previously-defined Equipment, you might use the command sequence (at Zone level)
This creates /EQUIPB as the Current Element and then turns it into an exact copy of /EQUIPA. All attributes and members of /EQUIPB now have the same settings as those of /EQUIPA, including its position, orientation etc., and so you will probably now want to move one of the Equipments to a different location.
To copy all offspring of an element, so that they create duplicate offspring for the Current Element, enter
The position, orientation, etc., of the Current Element now remain unchanged, but it acquires new members which are derived from the specified source element and which are correctly positioned relative to the Current Element.
To copy selected offspring of an element, so that they create duplicate offspring for the Current Element, enter
For example, the command sequence
creates a new Branch named /SIDEARM whose components replicate that part of the existing Branch /MAINLINE between the specified list positions. The attributes of the Branch /SIDEARM itself are unaffected by the COPY command, so that its position, orientation, etc. (as defined by its Head and Tail settings) remain unchanged by the addition of its new members.
To copy attributes from an identified element into the current element, type
This causes all attributes (except for references to elements in DESI databases and OWNER) to be copied to the current element. Or:
This is similar to the ATTRIBUTES option, except that as well as DESI references not being copied, neither are any position, direction, orientation or angle attributes.
In both cases, the Specification Reference (SPREF) and Catalog Reference (CATREF) are also not copied between elements of different types.
To copy elements alongside their original positions, type
This option causes a list of elements, defined by the selection criterion select, to be copied alongside their original positions in the database. So if the list includes a SCTN and a PNOD (for example) then each of these items would be copied so that the new SCTN shares the same owner as the old SCTN and the new PNOD shares the same owner as the old PNOD. As this option copies elements, rather than just attributes, other COPY options, such as RENAME, are valid.
To copy all or part of an element and rename the copies, append the command
to the corresponding COPY command line.
For example, the command
copies all attributes and offspring of /FRACT1/PIPE into the Current Element. Where /FRACT1 occurs as the name or part of the name, it is changed to /FRACT2 in the Current Element and its offspring. Thus the Current Element itself is now named /FRACT2/PIPE, and so on.
DACCOH
BOOL

True if DAC allows element hierarchy to be copied to another DB
DACCOP
BOOL

True if DAC allows element to be copied to another DB
DACCRE
BOOL
NOUN
True if DAC allows element to be created
DACDEL
BOOL

True if DAC allows element to be deleted
DACERR
STRING(120)
ATTR
Returns the DAC error
MODATT
BOOL
ATTR
True if attribute of element can be modified
MODDEL
BOOL
ATTR
True if element can be deleted

Attribute Name
Data Type
Qualifier
Description
DACCOH
BOOL
True if DAC allows element hierarchy to be copied to another DB
DACCOP
BOOL
True if DAC allows element to be copied to another DB
DACCRE
BOOL
NOUN
True if DAC allows element to be created
DACDEL
BOOL
True if DAC allows element to be deleted
DACERR
STRING(120)
ATTR
Returns the DAC error
MODATT
BOOL
ATTR
True if attribute of element can be modified
MODDEL
BOOL
ATTR
True if element can be deleted
COPY element_id
NEW EQUI /EQUIPB
COPY /EQUIPA
COPY MEMbers OF element_id
COPY MEMbers integer TO integer OF element_id
NEW BRAN /SIDEARM
COPY MEMBERS 12 TO 20 OF /MAINLINE
COPY ATTributes OF element_id
COPY LIKE element_id
COPY ADJ/ACENT select
... REName    old_name   new_name
COPY  /FRACT1/PIPE  RENAME  /FRACT1  /FRACT2
Note:
If the Current Element already has members, it is not possible to make it a copy of another element in this way.

Create a New Element
Create a New Element
Note
:


SAVEWORK saves the current Model changes without leaving Model. It is good practice to use this command on a regular basis during a long session to make sure maximum data security.
As well as a comment, an optional number n can be used to specify a particular database for the command. The number is the number of the database in the order output by the STATUS command (refer to Project). If no number is given, the SAVEWORK applies to the whole Multiple Database (MDB). An example of Savework syntax is SAVEWORK ‘comment’ 1.
GETWORK refreshes the view of all READ databases to pick up any changes that other users may have made since you first opened them. The optional n works in the same way as for SAVEWORK. You would normally only use GETWORK if you know of specific changes you wish to pick up and use. Please note that GETWORK slows up subsequent database access, as the information has to be re-read from disk. Therefore, you should use this command sparingly.

Project
n
Project
n


Each time you enter Model or save your design changes, a new session is created for each database changed. You can then query when specific items of design data were modified by reference to the corresponding session number(s). Sessions can be used by the System Administrator to backtrack changes to a given date or session if necessary.


You can add a comment for each session, which can help identify the work done in each session.
Lets you associate comment text with the current Model session. You can query this text later to help you identify a particular session in which modifications were made to elements and/or attribute settings. You can enter the session comment before you issue a SAVEWORK command, or as part of a SAVEWORK command for example SAVEWORK ‘MY COMMENTS’.
SESSION COMMENT ’Addition of upper platform’
where integer is the session number.
Each time you enter Model or save your design changes, a new session is created for each database changed. You can then query when specific items of design data were modified by reference to the corresponding session number(s). Sessions can be used by the System Administrator to backtrack changes to a given date or session if necessary.
Example
SESSION COMMENT ’Addition of upper platform’
>-- SESSION COMMENT -- text -->

Q SESSComment integer
Note:
Sessions 1 and 2 are created in ADMIN (when the MODEL DB and its World element, respectively, are created), so the first true session will be Session 3.
Example
SESSION COMMENT ’Addition of upper platform’

before
Note
:
Session 3
SESSION COMMENT ’Addition of upper platform’
text
integer
integer


Multiwrite Databases Claims and Extracts

If a Model or Draw Database (DB) has been created as a multiwrite database, several users can write to it simultaneously, although they cannot change the same element.
Multiwrite databases can either be Standard multiwrite databases, or Extract databases. In both types, an element must be claimed before it can be modified. Claiming an element prevents other users claiming (and modifying) the element; the element must be released before another user can change it.
Claiming can be either explicit, where you must use the CLAIM command before attempting to modify the element, or implicit, where the claim is made automatically when you try to modify the element. The claim mode is set when the DB is created. Refer to Administrator Command Reference Manual for further information.

multiwrite
Standard
Extract
claimed
released
explicit
implicit
Administrator Command Reference Manual
Administrator Command Reference Manual
.


In a Standard multiwrite database, you must claim an element before changing it. This is known as a user claim. If the claim mode is explicit (see below for details of how to check this), you must first claim each element that you want to modify using the CLAIM command. If the claim mode is implicit, the claim will be made automatically (although you can still give explicit CLAIM commands if you want to prevent other users claiming specific elements).
Only primary elements can be claimed, these are listed in the Data Model Reference Manual.
You can claim a specified element only, or a specified element plus all of the significant elements below it in the hierarchy. If the claimed element is not a significant element, the significant element above it in the hierarchy will be claimed.
An element must be unclaimed before another user can claim it and change it. User claims are always unclaimed when you change modules or leaves AVEVA E3D Design, and you can also unclaim elements at any time during an AVEVA E3D Design session using the UNCLAIM command.
CLAIM /ZoneA /EQUIP100 /PIPE-100-A

Claims named elements
CLAIM /ZoneA HIERARCHY

Claims named element and all of its owned hierarchy
CLAIM /ELBOW-33

Claims Branch which owns named component, since ELBO is not a significant element
UNCLAIM /PIPE-100 /PIPE-200

Unclaims named elements
UNCLAIM ALL
Unclaims all elements currently claimed
Examples
CLAIM /ZoneA /EQUIP100 /PIPE-100-A
Claims named elements
CLAIM /ZoneA HIERARCHY
Claims named element and all of its owned hierarchy
CLAIM /ELBOW-33
Claims Branch which owns named component, since ELBO is not a significant element
UNCLAIM /PIPE-100 /PIPE-200
Unclaims named elements
UNCLAIM ALL
Unclaims all elements currently claimed
                .---------------.
               /                |
>-- CLAIM ----*-- elementname --+-- HIERARCHY ---.
                                |                |
                                ‘----------------+-->
                 .---------------.
                /                |
>-- UNCLAIM ---*-- elementname --+-- HIERARCHY ---.
               |                 |                |
               ‘-- ALL ----------+----------------+-->

Data Model Reference Manual
user claim
primary
Data Model Reference Manual
unclaimed
CLAIM /ZoneA /EQUIP100 /PIPE-100-A
CLAIM /ZoneA HIERARCHY
CLAIM /ELBOW-33
UNCLAIM /PIPE-100 /PIPE-200
UNCLAIM ALL


Elements cannot be claimed if recent changes have been made to them by other users. You must issue a GETWORK command first.
Elements cannot be unclaimed if there are updates outstanding. You must issue a SAVEWORK command first.
You can insert/remove primary elements in a members list without claiming the owner. For example, you can add a Branch to a Pipe without claiming the Pipe. Thus two users can add different Branches to the same Pipe: any discrepancies will be resolved when a SAVEWORK is attempted.
Before an element can be deleted, that element and all of its sub-hierarchy must be claimed.
The following potential problems may not be revealed until you try to save changes:
Elements cannot be claimed if recent changes have been made to them by other users. You must issue a GETWORK command first.
Elements cannot be claimed if recent changes have been made to them by other users. You must issue a GETWORK command first.
Elements cannot be unclaimed if there are updates outstanding. You must issue a SAVEWORK command first.
Elements cannot be unclaimed if there are updates outstanding. You must issue a SAVEWORK command first.
You can insert/remove primary elements in a members list without claiming the owner. For example, you can add a Branch to a Pipe without claiming the Pipe. Thus two users can add different Branches to the same Pipe: any discrepancies will be resolved when a SAVEWORK is attempted.
You can insert/remove primary elements in a members list without claiming the owner. For example, you can add a Branch to a Pipe without claiming the Pipe. Thus two users can add different Branches to the same Pipe: any discrepancies will be resolved when a SAVEWORK is attempted.
Before an element can be deleted, that element and all of its sub-hierarchy must be claimed.
Before an element can be deleted, that element and all of its sub-hierarchy must be claimed.
The following potential problems may not be revealed until you try to save changes:
The following potential problems may not be revealed until you try to save changes:


Unlike standard multiwrite databases, extracts allow users to keep elements claimed when they exit from AVEVA E3D Design or change to another module. They can also be used, together with Data Access Control (DAC), to manage workflow. Refer to Administrator User Guide for more information.
An Extract is created from an existing Database. When an Extract is created, it will be empty, with pointers back to the owing or master database . Extracts can only be created from Multiwrite databases. An extract can be worked on by one User at the same time as another user is working on the master or another extract.
When a user works on the extract, an extract claim is made as well as a user claim.
If the claim mode is explicit, the extract claim will be made automatically when you make a user claim using the CLAIM command. You can also claim to the extract only using the EXTRACT CLAIM command.
If an element is claimed to an extract, only users with write access to the extract will be able to make a user claim and start work on the element:
When an extract user does a SAVEWORK, the changed data will be saved to the Extract. The unchanged data will still be read via pointers back to the master Database (DB). The changes made to the extract can be written back to the master, or dropped. Also, the extract can be refreshed with changes made to the master.
EXTRACT CLAIM /STRU1 /STRU2 /STRU3

Claims named elements to the extract
EXTRACT CLAIM /STRU1 /STRU2 /ZONE-A HIERARCHY

Claims the named elements, and all the elements in the hierarchy to the extract
The HIERARCHY keyword must be the last on the command line. It will attempt to claim to the extract all members of the elements listed in the command which are not already claimed to the extract.
EXTRACT FLUSH DB PIPE/PIPE ‘Description of flush’

Writes all changes to the database back to the owing extract. The Extract claim is maintained.
EXTRACT FLUSH /STRU1 /STRU2 /STRU3 ‘Flushing three  structures’

Writes the changes to the named elements back to the owing extract. The Extract claim is maintained.
EXTRACT ISSUE DB PIPE/PIPE ‘Issuing /pipe’

Writes all the changes to the database back to the owning extract and releases the extract claim
EXTRACT ISSUE /ZONE-A HIERARCHY ‘Issuing /zone’

Writes all the changes to the named element and all elements under it in the hierarchy back to the owning extract and releases the extract claim
EXTRACT ISSUE /STRU1 /STRU2 /STRU3 ‘Issuing three structures’

Writes the changes to the named elements back to the owning extract and releases the extract claim
EXTRACT RELEASE DB PIPE/PIPE

Releases the extract claim: this command can only be given to release changes that have already been flushed.
EXTRACT RELEASE /STRU1 /STRU2 /STRU3

Releases the extract claim: this command can only be given to release changes that have already been flushed.
EXTRACT RELEASE /ZONE-A HIERARCHY

Releases the extract claim to the named element and all: elements under it in the hierarchy.
EXTRACT DROP DB PIPE/PIPE ‘Dropping /Pipe’

Drops changes that have not been flushed or issued. Your claim must have been unclaimed before this command can be given.
EXTRACT REFRESH DB MYTEAMPIPING

This will refresh the extract MYTEAMPIPING with changes made on the parent extract,
The elements required can be specified by selection criteria, using a Programmable Macro Language (PML) expression. For example:
Examples
EXTRACT CLAIM /STRU1 /STRU2 /STRU3
Claims named elements to the extract
EXTRACT CLAIM /STRU1 /STRU2 /ZONE-A HIERARCHY
Claims the named elements, and all the elements in the hierarchy to the extract
The HIERARCHY keyword must be the last on the command line. It will attempt to claim to the extract all members of the elements listed in the command which are not already claimed to the extract.
EXTRACT FLUSH DB PIPE/PIPE ‘Description of flush’
Writes all changes to the database back to the owing extract. The Extract claim is maintained.
EXTRACT FLUSH /STRU1 /STRU2 /STRU3 ‘Flushing three  structures’
Writes the changes to the named elements back to the owing extract. The Extract claim is maintained.
EXTRACT ISSUE DB PIPE/PIPE ‘Issuing /pipe’
Writes all the changes to the database back to the owning extract and releases the extract claim
EXTRACT ISSUE /ZONE-A HIERARCHY ‘Issuing /zone’
Writes all the changes to the named element and all elements under it in the hierarchy back to the owning extract and releases the extract claim
EXTRACT ISSUE /STRU1 /STRU2 /STRU3 ‘Issuing three structures’
Writes the changes to the named elements back to the owning extract and releases the extract claim
EXTRACT RELEASE DB PIPE/PIPE
Releases the extract claim: this command can only be given to release changes that have already been flushed.
EXTRACT RELEASE /STRU1 /STRU2 /STRU3
Releases the extract claim: this command can only be given to release changes that have already been flushed.
EXTRACT RELEASE /ZONE-A HIERARCHY
Releases the extract claim to the named element and all: elements under it in the hierarchy.
EXTRACT DROP DB PIPE/PIPE ‘Dropping /Pipe’
Drops changes that have not been flushed or issued. Your claim must have been unclaimed before this command can be given.
EXTRACT REFRESH DB MYTEAMPIPING
This will refresh the extract MYTEAMPIPING with changes made on the parent extract,
EXTRACT CLAIM ALL STRU WHERE (:OWNER EQ 'USERA') HIERARCHY
>- EXTRACT -+- FLUSH ---------------.
            |                       |
            |- FLUSHWithoutrefresh -|
            |                       |
            |- RELEASE -------------|
            |                       |
            |- ISSUE ---------------|
            |                       |
            |- DROP ----------------|    .-------<-------.
            |                       |   /                |
            ‘- REFRESH -------------+--*-- elementname --+- HIERARCHY -.
                                    |                                  |
                                    |                                  |
                                    |                                  |
                                    ‘-- DB dbname ---------------------+->
If the databases are set up with implicit claim, when you modify the element, the element will be claimed both to the extract and then to you. If the element is already claimed to the extract, then the claim will only be made to you.
If the databases are set up with explicit claim, then you will need to use the CLAIM command before modifying the element.
Once you have made a user claim, no other users will be able to work on the elements claimed, as in a normal multiwrite database.
If you unclaim an element, it will remain claimed to the extract until the extract claim is released or issued.
If the databases are set up with implicit claim, when you modify the element, the element will be claimed both to the extract and then to you. If the element is already claimed to the extract, then the claim will only be made to you.
If the databases are set up with implicit claim, when you modify the element, the element will be claimed both to the extract and then to you. If the element is already claimed to the extract, then the claim will only be made to you.
If the databases are set up with explicit claim, then you will need to use the CLAIM command before modifying the element.
If the databases are set up with explicit claim, then you will need to use the CLAIM command before modifying the element.
Once you have made a user claim, no other users will be able to work on the elements claimed, as in a normal multiwrite database.
Once you have made a user claim, no other users will be able to work on the elements claimed, as in a normal multiwrite database.
If you unclaim an element, it will remain claimed to the extract until the extract claim is released or issued.
If you unclaim an element, it will remain claimed to the extract until the extract claim is released or issued.

Administrator User Guide
master
released
issued
EXTRACT CLAIM /STRU1 /STRU2 /STRU3
EXTRACT CLAIM /STRU1 /STRU2 /ZONE-A HIERARCHY
HIERARCHY
EXTRACT FLUSH DB PIPE/PIPE ‘Description of flush’
EXTRACT FLUSH /STRU1 /STRU2 /STRU3 ‘Flushing three  structures’
EXTRACT ISSUE DB PIPE/PIPE ‘Issuing /pipe’
EXTRACT ISSUE /ZONE-A HIERARCHY ‘Issuing /zone’
EXTRACT ISSUE /STRU1 /STRU2 /STRU3 ‘Issuing three structures’
EXTRACT RELEASE DB PIPE/PIPE
EXTRACT RELEASE /STRU1 /STRU2 /STRU3
EXTRACT RELEASE /ZONE-A HIERARCHY
EXTRACT DROP DB PIPE/PIPE ‘Dropping /Pipe’
EXTRACT REFRESH DB MYTEAMPIPING


Attribute Name
Data Type
Qualifier
Description
DACCLA
BOOL
True if DAC allows element to be claimed
DACERR
STRING(120)
ATTR
Returns the DAC error
DACISS
BOOL
True if DAC allows element to be issued
Attribute Name
Data Type
Qualifier
Description
DACCLA
BOOL

True if DAC allows element to be claimed
DACERR
STRING(120)
ATTR
Returns the DAC error
DACISS
BOOL

True if DAC allows element to be issued
CLMID
STRING(120)

Unique system ID of user claiming element
CLMNUM
INTEGER

User or extract number claiming element. Extract num\-bers are negative
CLMTIE
ELEMENT(4)

Reference to elements that are automatically claimed along with this element
EXCLFR
BOOL

True if element claimed from this extract. Only True for Primary elements
EXCLHI
ELEMENT(5000)

Primary elements in descendant hierarchy claimed to this extract (includes this element)
EXCLTO
BOOL

True if element claimed to this extract. Only True for Pri\-mary elements
EXNCLH
ELEMENT(5000)

Primary elements in descendant hierarchy not claimed to this extract
EXTRC
STRING(120)

Name of extract claiming element
NPDESC
ELEMENT(5000)

List of non primary offspring
OKCLA
BOOL

True if element may be claimed
OKCLH
BOOL

True if element and hierarchy may be claimed
OKREL
BOOL

True if element may be released
OKRLH
BOOL

True if element and hierarchy may be released
PRIMTY
BOOL

True if element is primary
PRMMEM
BOOL

True if there are any primary elements amongst descendants
PRMOWN
ELEMENT

Primary owning element (will be itself if primary)
USCLHI
ELEMENT(5000)

Elements in descendant hierarchy claimed to this user
USERC
STRING(120)

User name of user claiming element
USNCLH
ELEMENT(5000)

Elements in descendant hierarchy not claimed to this user
EXHCNC
ELEMENT(5000)

As EXTCNC, but repeat test for all descendants
EXHCNN
ELEMENT(5000)

As EXTCNN, but repeat test for all descendants
EXHCON
ELEMENT(5000)

As EXTCON, but repeat test for all descendants
EXHRCN
ELEMENT(5000)

As EXRCN, but repeat test for all descendants
EXHRCO
ELEMENT(5000)

As EXTRCO, but repeat test for all descendants
EXMOC
BOOL

As EXMOD but ignoring changes to "noclaim" attributes and member lists
EXPMOC
BOOL

As EXPMOD but ignoring changes to "noclaim" attributes and member lists
EXPMOD
BOOL

True if primary and element or non-primary descendants have been modified in this extract
EXTCNC
ELEMENT(5000)

As EXTCON but excluding non modified elements
EXTCNN
ELEMENT(5000)

As EXTCON but excluding modified elements
EXTCON
ELEMENT(5000)

Primary elements connected/disconnected from ele\-ment or non primary descendants in extract
EXTRCN
ELEMENT(5000)

As EXTCNN, but applied recursively to each connection
EXTRCO
ELEMENT(5000)

As EXTCON, but applied recursively to each connection
OKDROP
BOOL

True if element may be dropped
OKDRPH
ELEMENT(5000)

Primary elements preventing hierarchy drop
OKRLEH
ELEMENT(5000)

Primary elements preventing hierarchy release
OKRLEX
BOOL

True if element may be extract released

Attribute Name
Data Type
Qualifier
Description
DACCLA
BOOL
True if DAC allows element to be claimed
DACERR
STRING(120)
ATTR
Returns the DAC error
DACISS
BOOL
True if DAC allows element to be issued
Attribute Name
Data Type
Qualifier
Description
CLMID
STRING(120)
Unique system ID of user claiming element
CLMNUM
INTEGER
User or extract number claiming element. Extract num\-bers are negative
CLMTIE
ELEMENT(4)
Reference to elements that are automatically claimed along with this element
EXCLFR
BOOL
True if element claimed from this extract. Only True for Primary elements
EXCLHI
ELEMENT(5000)
Primary elements in descendant hierarchy claimed to this extract (includes this element)
EXCLTO
BOOL
True if element claimed to this extract. Only True for Pri\-mary elements
EXNCLH
ELEMENT(5000)
Primary elements in descendant hierarchy not claimed to this extract
EXTRC
STRING(120)
Name of extract claiming element
NPDESC
ELEMENT(5000)
List of non primary offspring
OKCLA
BOOL
True if element may be claimed
OKCLH
BOOL
True if element and hierarchy may be claimed
OKREL
BOOL
True if element may be released
OKRLH
BOOL
True if element and hierarchy may be released
PRIMTY
BOOL
True if element is primary
PRMMEM
BOOL
True if there are any primary elements amongst descendants
PRMOWN
ELEMENT
Primary owning element (will be itself if primary)
USCLHI
ELEMENT(5000)
Elements in descendant hierarchy claimed to this user
USERC
STRING(120)
User name of user claiming element
USNCLH
ELEMENT(5000)
Elements in descendant hierarchy not claimed to this user
Attribute Name
Data Type
Qualifier
Description
EXHCNC
ELEMENT(5000)
As EXTCNC, but repeat test for all descendants
EXHCNN
ELEMENT(5000)
As EXTCNN, but repeat test for all descendants
EXHCON
ELEMENT(5000)
As EXTCON, but repeat test for all descendants
EXHRCN
ELEMENT(5000)
As EXRCN, but repeat test for all descendants
EXHRCO
ELEMENT(5000)
As EXTRCO, but repeat test for all descendants
EXMOC
BOOL
As EXMOD but ignoring changes to "noclaim" attributes and member lists
EXPMOC
BOOL
As EXPMOD but ignoring changes to "noclaim" attributes and member lists
EXPMOD
BOOL
True if primary and element or non-primary descendants have been modified in this extract
EXTCNC
ELEMENT(5000)
As EXTCON but excluding non modified elements
EXTCNN
ELEMENT(5000)
As EXTCON but excluding modified elements
EXTCON
ELEMENT(5000)
Primary elements connected/disconnected from ele\-ment or non primary descendants in extract
EXTRCN
ELEMENT(5000)
As EXTCNN, but applied recursively to each connection
EXTRCO
ELEMENT(5000)
As EXTCON, but applied recursively to each connection
OKDROP
BOOL
True if element may be dropped
OKDRPH
ELEMENT(5000)
Primary elements preventing hierarchy drop
OKRLEH
ELEMENT(5000)
Primary elements preventing hierarchy release
OKRLEX
BOOL
True if element may be extract released


It is possible to undo and redo many operations. The undo mechanism is managed by AVEVA E3D Design using a stack of transaction objects.
Each transaction object records the change in the state across the transaction.
The new descriptions are then:
MARKDB ‘comment’ - Complete the current transaction and starts a new transaction.
UNDODB - Undo the last transaction. If there is a current transaction then this is completed. Multiple Undos are allowed.
REDODB - Redo to next mark. Multiple Redos are allowed. A redo is only valid after an UNDO. Any database change after an UNDO invalidates a REDO.


Every time you select an undo operation an entry is taken off the undo stack. The state saved in this transaction is restored, and the transaction object is placed on the redo stack.
When the undo stack is empty, then the Undo button and the Undo menu option will be greyed out indicating that there are no operations remaining that can be undone.
If the operation of undo involves moving into or out of model editing mode, then the switch into that mode will happen automatically, and the model editor button and menu option will reflect the change.
The selection set and handle appropriate to the editing operation that was being used will also be restored.
There are also a number of ways that you can perform an undo:
The undo stack is automatically cleared after a SAVEWORK or GETWORK.
A similar process to the one described above occurs for redo.
When a transaction is taken off the redo stack, it is put back onto the undo stack.
If you perform any operation that changes the database after doing an undo, then the redo stack will be cleared.
Refer to for controlling the undo stack from user defined Programmable Macro Language (PML).
MARKDB 'comment'
Set a Database mark. Multiple marks may be set.
UNDODB
Undo database to last mark. Multiple undos are allowed.
REDODB
Redo to next mark. Multiple Redos are allowed. A redo is only valid after an UNDO. Any database change after an UNDO invalidates a REDO.
MARKDB 'comment'
Set a Database mark. Multiple marks may be set.
UNDODB
Undo database to last mark. Multiple undos are allowed.
REDODB
Redo to next mark. Multiple Redos are allowed. A redo is only valid after an UNDO. Any database change after an UNDO invalidates a REDO.
The list of marks can be obtained from PML function MARKDB.
The system will always create an initial mark the first time the database is changed.
MARKDB 'comment'
Set a Database mark. Multiple marks may be set.
UNDODB
Undo database to last mark. Multiple undos are allowed.
REDODB
Redo to next mark. Multiple Redos are allowed. A redo is only valid after an UNDO. Any database change after an UNDO invalidates a REDO.
AREA 0
MARKDB 'First Mark'
AREA 100
MARKDB 'Second Mark'
AREA 200
MARKDB 'Third Mark'
AREA 300
!MARKS = MARKDB
Q VAR !MARKS
UNDODB
Q AREA - value will be 200
UNDODB
Q AREA - value will be 100
UNDODB
Q AREA - value will be 0
REDODB
Q AREA - value will be 100
REDODB
Q AREA - value will be 200
AREA 99
UNDODB
Q AREA - value will be 200
REDODB
Q AREA - value will be 99
By clicking on the Undo button on the appropriate toolbar.
By selecting the Undo option on the Edit pulldown menu on the main toolbar.
By entering the command UNDODB n where n indicates how many steps are to be undone.
By clicking on the Undo button on the appropriate toolbar.
By clicking on the Undo button on the appropriate toolbar.
By selecting the Undo option on the Edit pulldown menu on the main toolbar.
By selecting the Undo option on the Edit pulldown menu on the main toolbar.
By entering the command UNDODB n where n indicates how many steps are to be undone.
By entering the command UNDODB n where n indicates how many steps are to be undone.

Undo
Undo
Undo
Undo
Edit
UNDODB n
n

Example


Shared Collections (Groups) and Secondary Hierarchies

A shared collection can hold in its members list a number of design elements from any combination of hierarchic levels, they may also span Multiple Databases (MDBs). You can use any appropriate design operation to act upon all of these individual elements simply by carrying out the operation on the shared collection.
Shared collections are particularly useful when there is a need to create a secondary hierarchy of elements. For example a set of elements for a project may span more that one site, if this is the case it is difficulty to identify where in the hierarchy these elements occur. With a shared collection you can easily query its members and see the hierarchy of elements contained within it.
A shared collection is a Model database element in its own right, and is therefore stored automatically for use in later sessions when you save database changes.
The Elements which make up a shared collection within the Model database are shown below:

GPWL (Group World) Is a top level administrative element. A GPWL may hold multiple GPSET (Group Set) elements.
GPSET contains groups of items (GPITEM). A GPSET element has Name, DESC, and FUNCTION attributes.
GPITEM These are elements within a database which are to be grouped under a Group Set (GPSET). Elements from different databases can all be grouped into the same Group Set. A GPITEM has the following attributes Name, DESC and SITEM.
It is possible to nest Group Sets within other Group Sets. To achieve this structure a GPSET can own another GPSET or a GPITEM can point back onto a GPSET. The following figure illustrates this:

GPWL
GPSET
GPITEM


The contents of a shared collection are defined by adding or removing references to or from the list part of the shared collection.
In order to use the commands described in this section, the current element must be the shared collection whose member list you wish to modify. Specified elements are then added to the list part of the current element starting from the current list position or are removed from the list part of the current element such that the current list position becomes the Head position.
The elements to be added to, or removed from, the shared collection’s member list may be specified in any of the following ways:
GADD /ZONE1 /VALVE2

Adds /ZONE1 and /VALVE2 to the current shared collection, starting from the current list position
GREMOVE /ZONE1 /BOX3

Removes /ZONE1 and /BOX3 from the current shared collection and moves the current list position pointer to the Head position
GADD MEM OF /BRANCH1 /BRANCH2

Adds all the pipe Components in Branches /BRANCH1 and /BRANCH2 to the current shared collection, starting from the current list position
GREM MEM OF /PIPE100 MEM OF /EQUI-B

Removes all Branches of the Pipe /PIPE100 and all members of Equipment /EQUI-B from the current shared collection
GREM ITEMS OF /ZONE2

Removes from the current shared collection all occurrences of those offspring of /ZONE2 which are items
GADD ALL EQU BRAN OF /ZONE1 /ZONE2

Adds all offspring of /ZONE1 and /ZONE2 which are of types Equip or Branch to the current shared collection, starting from the current list position
Examples
GADD /ZONE1 /VALVE2
Adds /ZONE1 and /VALVE2 to the current shared collection, starting from the current list position
GREMOVE /ZONE1 /BOX3
Removes /ZONE1 and /BOX3 from the current shared collection and moves the current list position pointer to the Head position
GADD MEM OF /BRANCH1 /BRANCH2
Adds all the pipe Components in Branches /BRANCH1 and /BRANCH2 to the current shared collection, starting from the current list position
GREM MEM OF /PIPE100 MEM OF /EQUI-B
Removes all Branches of the Pipe /PIPE100 and all members of Equipment /EQUI-B from the current shared collection
GREM ITEMS OF /ZONE2
Removes from the current shared collection all occurrences of those offspring of /ZONE2 which are items
GADD ALL EQU BRAN OF /ZONE1 /ZONE2
Adds all offspring of /ZONE1 and /ZONE2 which are of types Equip or Branch to the current shared collection, starting from the current list position
>--+-- GADD -----.     .-------------.
   |             |    /              |
   ‘-- GREMove --+---*-- <selatt> ---+--->
Explicitly, by name or (system-assigned) reference number.
As members of specified elements, where a member of an element is defined as any element immediately below it in the DB hierarchy
As items of specified elements, where an item of an element is any element anywhere below it in the hierarchy which has no list part (such as a Valve, Point, Box, etc.)
By type (such as Equipment, Branch, Pipe, etc.)
Explicitly, by name or (system-assigned) reference number.
Explicitly, by name or (system-assigned) reference number.
As members of specified elements, where a member of an element is defined as any element immediately below it in the DB hierarchy
As members of specified elements, where a member of an element is defined as any element immediately below it in the DB hierarchy
As items of specified elements, where an item of an element is any element anywhere below it in the hierarchy which has no list part (such as a Valve, Point, Box, etc.)
As items of specified elements, where an item of an element is any element anywhere below it in the hierarchy which has no list part (such as a Valve, Point, Box, etc.)
By type (such as Equipment, Branch, Pipe, etc.)
By type (such as Equipment, Branch, Pipe, etc.)

or
member
immediately
item
no
GADD /ZONE1 /VALVE2
GREMOVE /ZONE1 /BOX3
GADD MEM OF /BRANCH1 /BRANCH2
GREM MEM OF /PIPE100 MEM OF /EQUI-B
GREM ITEMS OF /ZONE2
GADD ALL EQU BRAN OF /ZONE1 /ZONE2


The action of this command differs from normal behaviour if the current element is a shared collection.
DELETE GPSET

Only the current element and any Offspring that are GPSETs will be deleted.
DELETE GPWLD

Only the current element and any Offspring that are GPSETs will be deleted.

Examples
DELETE GPSET
Only the current element and any Offspring that are GPSETs will be deleted.
DELETE GPWLD
Only the current element and any Offspring that are GPSETs will be deleted.

DELETE GPSET
DELETE GPWLD


Shared collections can be copied with a slightly different effect to normal elements.
COPY /GROUP21 (At a Group)

The Current shared collection will contain exactly the same Members as /GROUP21. No new elements have been created.

Examples
COPY /GROUP21 (At a Group)
The Current shared collection will contain exactly the same Members as /GROUP21. No new elements have been created.

COPY /GROUP21 (At a Group)


You may specify a dynamic selection for a GPSET. The dynamic selection consists of a PML1 collection expression.
For example:
The selection must be set against the SCOSEL attribute.
For example:
The selection is evaluated dynamically whenever the shared collection is used. Depending on the selection used there is a performance overhead in evaluating the selection.
ALL PIPE WHERE (BORE GT 80)
ALL BRAN MEMBERS WHERE (SPREF EQ /MYSPEC ) for SITE /SITE1

SCOSEL ALL EQUI FROM CLAIMLIST

RE (BORE GT 80)
ALL BRAN MEMBERS WHERE (SPREF EQ /MYSPEC
.


This section explains the PML 1 expressions package. These facilities are needed within AVEVA products, for example, to define report templates in AVEVA E3D Design.
Expressions have types. For example, you can have numeric expressions, text expressions and logical expressions. All the elements in an expression must be of the correct type. For example, if you have a two numbers, x and y, and two text strings text1 and text2, the following expression is meaningless:
x + text1
$
x + text1
$
However, both of the following expressions are valid:
x + y
$ adds the values of the numeric variables.
Text1 + text2
$ concatenates the two text strings.
x + y
$ adds the values of the numeric variables.
Text1 + text2
$ concatenates the two text strings.
Real expressions also have a physical dimension. This may be NONE when all values in the expression are purely numerical, but if any value has a physical dimension (such as being a length or mass) then all other values must be compatible with it and the result of the expression may have a physical dimension, or it may evaluate to a pure numerical value (1inch / 1mm = 25.4).
The following types of expressions are available:
x + text1
$
x + y
$ adds the values of the numeric variables.
Text1 + text2
$ concatenates the two text strings.
Logical Expressions
Logical Array Expressions
Numeric (Real) Expressions
Numeric (Real) Functions
Text Expressions
Logical Expressions
Logical Expressions
Logical Array Expressions
Logical Array Expressions
Numeric (Real) Expressions
Numeric (Real) Expressions
Numeric (Real) Functions
Numeric (Real) Functions
Text Expressions
Text Expressions
Note:
Generally, all these facilities are compatible with PML 2.

Logical Expressions
Logical Array Expressions
Numeric (Real) Expressions
Numeric (Real) Functions
Text Expressions
Note
:
x + text1
x + y
Text1 + text2
Logical Expressions
Logical Array Expressions
Numeric (Real) Expressions
Numeric (Real) Functions
Text Expressions


The format of an expression, for example the use of brackets, spaces and quotes, is important. If you do not follow the rules given below you will get error messages:
Text must be enclosed in quotes.
There must be a space between each operator and operand. For example:
Use round brackets to control the order of evaluation of expressions and to enclose the argument of a function.
In general, you do not need spaces before or after brackets, except when an AVEVA E3D Design name is followed by a bracket. If there is no space, the bracket will be read as part of the name.
'This is text’
x + y
SIN(30)
(NAME EQ /VESS1 )


Operators are evaluated in the order of the following list: the ones at the top of the list are evaluated first.
BRACKETS
Brackets can be used to control the order in which operators are evaluated, in the same way as in normal arithmetic
FUNCTIONS

* /

+ -

EQ, NEQ, LT, LE, GE, GT

NOT

AND

OR

Operator
Comments
BRACKETS
Brackets can be used to control the order in which operators are evaluated, in the same way as in normal arithmetic
FUNCTIONS
* /
+ -
EQ, NEQ, LT, LE, GE, GT
NOT
AND
OR


Expressions can be nested using brackets.
( (SIN(!angleA) * 2)  /  SIN(!angleB) )

( (SIN(!angleA) * 2)  /  SIN(!angleB) )


Logical expressions can contain:
AVEVA E3D Design attributes of type logical e.g. BUILT.
Logical constants. The constants available are: TRUE, ON, YES for true, and FALSE, OFF, NO for false.
Logical operators.
Logical functions.
AVEVA E3D Design attributes of type logical e.g. BUILT.
AVEVA E3D Design attributes of type logical e.g. BUILT.
Logical constants. The constants available are: TRUE, ON, YES for true, and FALSE, OFF, NO for false.
Logical constants. The constants available are: TRUE, ON, YES for true, and FALSE, OFF, NO for false.
Logical operators.
Logical operators.
Logical functions.
Logical functions.