External Mapping Files

Structural Design User Guide

SDNF Export/Import : External Mapping Files

While setting up the Export or Import variables, the external mapping files are initially tested to see if they are valid. At the top of each file is a check line indicating the external package to which the file is related. The check line must be of the form:

AVEVA TargetPackage

For example:

AVEVA XSteel

The target package name must be as it appears in the data list, !!SDNFExtProgList (see External Packages). This list is picked up automatically by the Export and Import forms.

Note:

Tab characters are not permitted in the mapping files, as they interfere with the field separation.

Comments may be included in the mapping files. They are indicated by a hash (#) character as the first non-blank character on the line.

Blank lines are also permitted.

Error and Log File Messages


Suitable Mapping Table File not found	File specified in the mapping table is not found.
Not a suitable Mapping Table File - Is it empty?	The header may not be of the correct format. The header does not match the target package.

Space-Separated Format for Profile Mapping Files

Because AVEVA element names cannot contain spaces, space-separated mapping files receive special treatment to allow spaces in external Profile names, but not in AVEVA names. A description of the individual fields in the Profile Mapping Files is given after this section. The four fields are read in the following order.

The first field is the AVEVA name (with no leading, trailing or embedded spaces).

The fourth field is the Profile type (with no leading, trailing or embedded spaces).

The third field is the Steel Standard (with no leading, trailing or embedded spaces).

The second field is the external profile name, once the leading and trailing spaces have been removed.

See External Mapping File Separator for information on how the user can specify which separator which the interface will use to discriminate between fields.

CSV Format for Profile Mapping Files

The user can also use Comma Separated Variable (CSV) format for the Profile mapping. In CSV format, the fields are separated by commas rather than by spaces. This means, therefore, that the names of profiles must not contain commas, but the external profile name can still contain spaces.

CSV format allows the user to manage the mapping files in a spreadsheet program. If the user is constructing a CSV file by hand, the user should be aware how a CSV file handles commas in fields.

Profile Mapping Files

This section describes the formats for the mapping files between AVEVA catalogues and those of external 3D steel detailing packages. The mapping files will indicate a correlation between the catalogue item in AVEVA and its equivalent in the other system, to which, or from which, data are to be transferred. It is the user’s responsibility to make sure that any geometrical modelling required in either system is suitably reproduced in the other. The mapping files supplied are modifiable and extensible by the user.

There are two similar mapping files required: one for AVEVA and the other for the 3D steel detailing package. This will allow greater modularity and independence of each software component in the interface.

Important:

It is assumed that the package importing the data will perform the mapping to local names. Any system exporting data will export its own local names without performing any translation process whatsoever. This interface, however, checks that there is a valid mapping for a Profile before it is exported, even though the local AVEVA profile name is still exported. This can also be a cause for misunderstanding if the SDNF output file is inspected, and the user still sees AVEVA profile names, and not the names translated for the target package.

Record Structure for Profile Mapping File

The database file consists of records of AVEVA catalogue profile name matched with the external profile name and two other fields giving the origin and profile type as recognised by the external package. A typical record is as follows:

300X300X214.00SHS TUB30030025.0 BRI 12

The fields are described below:


Field	Description
1	AVEVA E3D™ catalogue profile name (without leading / )
2	External catalogue profile name
3	Steel standard. See below.
4	Profile type. See below.

The catalogue names for the external package must be ascertained by the user and matched correctly with the equivalent AVEVA E3D™ name.

Steel Standard Field

Some 3D steel detailing packages cannot mix profiles from more than one steel standard at the same time. The external package may stop if it finds a profile from a different steel standard. Therefore, we need to record the origin of the profile. This is done in the third field, the Steel Standard field, which is currently codified as follows:


Country	Code
America	AME
Britain	BRI
Canada	CAN
Euronorm	EUR
Germany	GER
Japan	JAP

If the user wants to include profiles or joints from another standard or country, the user must add a new and unique three-character identifier.

Profile Type Field

The Profile Type field defines exactly what type the profile is. This is because there may be many occurrences of the same profile name in the 3D steel detailing package, but used in different manners. For example, only those T shapes which are derived from cutting up I shapes may be stored. This could be recorded in the file as follows:


AVEVA E3D™	External	Origin	Type	Description
W21X44	W21X44	AME	1	I shape
WT10.5X22	W21X44	AME	6	Tee ex W21X44


AVEVA E3D™	External	Origin	Type	Description
L4X3.5X.25	L40354	AME	9	L shape
2L4X3.5X.25.L	L40354	AME	10	2L long leg
2L4X3.5X.25.S	L40354	AME	11	2L short leg

We have assumed that double angles may have a gap (i.e. 0 or more) corresponding to type 10 below, but to differentiate between short-leg and long-leg double angles we have used type 10 to identify the long and type 11 the short leg back-to-back double angles. There are no genuine type 11 profiles in the supplied data set.

The profile type codes are as follows:


Type Code	Profile/Joint
1	Beams (UB, W)
2	Columns (UC, M)
3	Joists (RSJ)
4	Piles (UBP, HP)
5	Composite
6	Tee (T, WT)
7	I with cover plate
8	Channels (C, MC,UNP)
9	Angles (L)
10	Double angles with gap (2L)	Note 1
11	Double angles without gap (2L)	Note 1
12	Tube (rectangular, square) (RHS, SHS)
13	Pipe (circular) (CHS)
14	Prismatic
15	Bulb shapes
16	Z shapes
20	HEA (Columns, beams)
21	HEB (Columns, beams)
22	HEM (Columns, beams)
23	IPE
25	INP
26	Flat Steel
27	Round Steel
28	Dummy Sections (ASL)
29	Grating
30	Chequered Plate
31	Treads
32	Anchor Bolts
33	Earthing Boss
34	Bent Plates	Note 2

Note:

Types 10 and 11 are often not available in external 3D steel detailing packages as a single Catalogue entry. In those cases, they must therefore be modelled as two single sections.

If Bent Plates are to be treated as angles with regard to mirroring etc., they must be classified as angles (type 9).

Extending the Profile Mapping File

To extend the facilities provided by the system, the ASCII file may be extended. Once the user have found a match between the AVEVA E3D™ catalogue profile name and the equivalent profile in the external detailing package, the name pair may be added to the file, along with the catalogue origin and profile type.

Sample Profile Mapping File

Below is a short extract of a Profile mapping file between AVEVA E3D™ and XSteel.

Note:

The identification line at the top of the file which indicates the Target Package.

Note:

Also that it is not complete in any way.

L40x20x3 L40*20*3 EUR 9

L40x5 L40*5 EUR 9

L45x30x3 L45*30*3 EUR 9

L45x30x4 L45*30*4 EUR 9

L45x30x5 L45*30*5 EUR 9

L45x4 L45*4 EUR 9

OD355.6x12.2 PD355.6*12.2 EUR 13

OD355.6x8 PD355.6*8 EUR 13

OD406.4x12.5 PD406.4*12.5 EUR 13

OD42.4x3.2 PD42.4*3.2 EUR 13

OD42.4x4 PD42.4*4 EUR 13

OD457x10 PD457*10 EUR 13

OD457x14.2 PD457*14.2 EUR 13

OD457x17.5 PD457*17.5 EUR 13

Error and Log File Messages


Profile cannot be mapped	The profile is not in the Profile Mapping File.
Profile is not in the standard	The profile is in the Profile Mapping File but is not in any one of the set of standards.
Profile is not the default	The profile is in the Profile Mapping File and is in one of the set of standards, but not the default standard.
Multiply defined entries in Profile Table	Either a profile to be mapped or a mapped profile appears more than once in the Profile Mapping File.

Material Mapping Files

Elements cannot be transferred through the SDNF if they do not have a valid material associated with them.

The existing AVEVA E3D™ material description may not be recognised in the external 3D steel detailing package; consequently, there must be a means by which we can translate the material description between systems. This is performed by means of a Material mapping file which relates the AVEVA E3D™ text description of a material to that output to, or found in, an SDNF file.

The user can modify and extend the mapping file.

There are two similar mapping files required: one for AVEVA E3D™ and the other for the 3D steel detailing package. This will allow greater modularity and independence of each component in the interface.

Important:

It is assumed that the package importing the data will perform the mapping to local names. Any system exporting data will export its own local names without performing any translation process whatsoever. This interface, however, checks that there is a valid mapping for a Material before it is exported, even though the local AVEVA E3D™ material text is still exported. This can also be a cause for misunderstanding if the SDNF output file is inspected, and the user still sees AVEVA E3D™ material texts, and not the text translated for the target package.

When the SDNF interface is started, the Properties database is searched for SOLI elements which may define materials used to fabricate elements in the Design. An internal list is then built for rapid reference.

Materials are usually associated with AVEVA E3D™ elements using the Material Reference attribute, MATR, which points to a SOLI element in the Properties database. However, the user may want to use the local :SDNFMGRADE attribute to specify the material. Either of these should be set for the interface to be able to export elements successfully.

If the above system is still not specific enough, there is a mechanism by which the user can define from where the material information is to be derived. See the next section for details.

When an element is exported, its material is determined by inspecting the :SDNFMGRADE attribute first, then the Description attribute of the SOLI element to which the MATR refers. If that fails, the user configurable mechanism is invoked. The text is then transferred locally to the :SDNFMGRADE attribute on the SCTN or PANE element. The text is then looked up in the Material mapping file to check that there is a translation into the SDNF file replacement text. The local material text is still exported.

When an element is to be imported, the SDNF file material description is looked up in the material mapping file and translated into the AVEVA E3D™ equivalent text string. This is then initially copied into the :SDNFMGRADE attribute of the element before any attempt is made to rationalise the MATR. If a SOLI element with this material text is found, the interface will set the MATR to point to the correct SOLI element.

As with the profile mapping file, the first line is an identifier which indicates the external package or system with which the file is associated.

Error and Log File Messages


Multiply defined entries in Material Table	Either a material to be mapped or a mapped profile appears more than once in the Material Mapping File.
No match for material	The material is not in the Material Mapping File.
Syntax Error	Other, less specific, errors.
Unrecognised Parse State	This should not occur. If it does then it indicates a system error. Although the error is non-fatal it should be reported. A number representing the parse state will also be output.

User-Definable Material Macro

The user may modify the sample macro, sdnfgetusermatl.pmlfnc, as named by the !!SDNFMaterialMac global variable and given in the SDNF\dflts\user\SDNFPML\functions folder in the user data folder, if the user has specific requirements as to where the material information resides. As is the case for customising the sdnfuserdata.pmlfnc file, the entire user folder along with its contents should be copied to the user's local space as defined by the AVEVA_DESIGN_USER environment variable. The sdnfgetusermatl.pmlfnc function can then be modified. Once modified, the user should execute a PML REHASH ALL command.

The example macro is as follows:

define function !!SDNFGetUserMatl( ) is STRING

-- Initialisation

!material = STRING( )

!material = |unset|

!start = ( ref )

-- Set default material

!defaultMaterial = |St 37-2|

-- Some User specific PML to get the required info

!type = ( type )

if( !type eq |SCTN| )then

-- Material stored on Catalogue component

goto catr

handle any

-- Bad or null reference

!material = !defaultMaterial

golabel /Finished

endhandle

!material = ( :Material )

handle any

!material = !defaultMaterial

golabel /Finished

endhandle

if( !material eq |unset| or $

!material.unset( ) or $

!material.length( ) eq 0 )then

-- Use default material

!material = !defaultMaterial

endif

elseif( !type eq |PANE| )then

-- Try to return :SDNFMGRADE or default material

!material = ( :SDNFMGRADE )

if( !material eq |unset| or $

!material.unset( ) or $

!material.length( ) eq 0 )then

-- Use default material

!material = !defaultMaterial

endif

-- Return string and exit

The above example assumes that the material information for Sections resides on the catalogue component in the UDA :MATERIAL. If, for any reason, a material cannot be identified, a default value of 'St 37-2' is assigned.

The interface assumes, by default, that this file exists under the above name in a folder below the %PMLLIB% search path, and that the starting point for database navigation is the current Design element under consideration, i.e. a Section or Panel. See the previous sections for details of how the user can configure the system to use a material macro with a name of the user’s choice.

Note:

In writing the user’s own macro, the user must handle all errors encountered so that the macro will always safely return a valid PML string, whatever it may be.
Also, that materials for Panels must also be determined using this macro.

See User-definable Material Macro regarding the naming of this macro.

Error and Log File Messages


User macro nnnn not found	Cannot find user macro.
Error in user macro nnnn	PML programming error in user macro.

Sample Material Mapping File

Below is a sample comma separated mapping (CSV) file to map between the AVEVA E3D™ materials found in the Properties database and the SDNF file targeted at XSteel.

AVEVA,XSTEEL

"unset","unset"

"TREAD-ALU","TREAD-Aluminum"

"ALUMINIUM","Aluminum"

"GR 420 I","GR 420 I"

"Pyrocrete","Fire concrete"

"Tread Grade","Tread Grade"

"LDPHP-GRADE","LDPHP-GRADE"

"Aluminium, cast","Aluminium, cast"

"Aluminium, wrought","Wrought Aluminium"

"Aluminium, Duralumin","Duralumin"

"Brass, red 80% Cu","Red Brass "

"Brass, yellow 65% Cu","Yellow Brass "

"Brass, cast","Cast Brass"

"Steel, carbon","Carbon Steel"

"Steel, chrome","Chrome Steel"

"Steel, Ni-chrome","Ni Steel"

Profile Orientation Mapping Files

Using the Profile Orientation Mapping File the user can define how SDNF translates a profile from AVEVA E3D™ format into the SDNF Neutral File format on Export, or from it on Import. Refer to the SDNF User Guide for details of how the Neutral File understands default orientations of certain profiles.

If the user defines their own catalogue profiles, or modify the supplied ones, and need to transform them into or from the SDNF format, this mapping file should be used. In all cases an Orientation mapping file should be available, even if it is empty apart from the first line.

Below is an example file:

The first line is the file identification line, described as for the Material or Profile mapping files. The structure of the rest of the mapping file is of a comma or space separated file with four fields per line.

The first two fields provide the identification of the profile for treatment. The first of the identification fields states the steel standard from which the profile is to be taken. The second is the actual profile type code according to the codes given. Thus, in the example above, the user can see that the channels (type 8) and angles (type 9) from the Euronorm, DIN and British Standard catalogues have been identified for special treatment.

The third and fourth fields describe what the user wants to do with the profile shape. The third is the mirroring flag, which should be set to 1 if the profile is to be reflected about the Y-axis. This will commonly be the case for angle profiles. No mirroring is indicated by a value of 0 in this field.