| Applies To | |||
| Product(s): | AutoPIPE, | ||
| Version(s): | 2004, XM, & V8i | ||
| Area: | Translator | ||
| Original Author: | Bentley Technical Support Group |
Note: The mapping files use a series of abbreviated names for supports and piping components, see the PCFIN.MAP file in the PCF translator folder for descriptions of the abbreviations.
Error Message: E33
E33 No component was found that matches the database search criteria
An error occurred while trying to use the pipeline name keyin value. Either the value is missing, or word 12 is set incorrectly.
Confirm DEFSTR.dat file has word 12 = correct attribute 0 to 3 as below
e.g. 3 = STRESS_SYSTEM_NO
INTERGRAPH OPTIONS BLOCK
!note: refer to PRO_DD_PDSSTRESS:PDSSTRESS.DOC. Maximum 45 options
1, 1, 901, 2001, 0, 6, 1, 1, 0, 1, 1, 0, 0, 20, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 99912
0 Extracts the network by substring of the pipeline name attribute,
LINE_NUMBER_LABEL (Refer to Appendix B, table 12, column 2.)
1 Extracts the network by substring of the stress analysis ID attribute,
STRESS_SYSTEM_NO (Refer to Appendix B, table 12, column 52.)
2 Extracts the network by equality of the pipeline name attribute,
LINE_NUMBER_LABEL (Refer to Appendix B, table 12, column 2.)
3 Extracts the network by equality of the stress analysis ID attribute,
STRESS_SYSTEM_NO (Refer to Appendix B, table 12, column 52.)
Error Message: E35
Error searching for PDS item name in PDS to STRESS map
Item name : STTS
PDS to STRESS map :
\\DESCLTPDS02\ddrive\173101\pds\stress\data\strmap.tbl
This means the path to the TBL file is incorrect the DEFSTR.dat file
Error Message: Error retrieving Support Type: ***** - #1
1) Example File #1: 560004i.n
The following warning is displayed:
---------- NEUTRAL FILE TRANSLATOR LOG ------------
Neutral File Input = 560004i.n
Error retrieving Support Type: 81801B3GG
Now first thing to check is to see what is wrong with Support Type at 81801B3GG. Please keep in mind that multiple supports at a point will need a multiple support mapping entry in the support mapping file too!
DS, 81801B3GG,5FS1S2,CODE1, 5, 901
MPROP,DS, 81801B3GG, 2,5FS1S2,0.000000,0.000000,0.000000,0.000000,0.000000,0.000000
MPROP,DS, 81801B3GG, 4,0.0,0.0,-1.0,0.673,0.7396,0.0
DS, 81801B4GG,5US-050,CODE1, 5, 902
MPROP,DS, 81801B4GG, 2,5US-050,0.000000,0.000000,0.000000,0.000000,0.000000,0.000000
MPROP,DS, 81801B4GG, 4,-0.673,-0.7396,0.0,0.7396,-0.673,0.0
Now as can be seen above. There is a valid support type defined for 81801B3GG which is 5FS1S2. Now when referring to Supports.map file for a relevant mapping – the closest found was following.
5FS(2)(S,C)(1,2)- VSTP
Now clearly the above mapping can only allow 5FS2S2 but not 5FS1S2 so update it like following:
5FS(1,2)(S,C)(1,2)- VSTP
Secondly as see above. There are two DS supports at the same node i.e. 5. One is 5FS1S2 and other is 5US-050. We need to make sure that support mapping file contains a mapping for combination of these 2 at the same point. Again the mapping was not available so the following line was added to Supports.MAP file.
5U(S,G)-+5FS(1,2)(S,C)(1,2)- VSTP
This fixes the errors for 560004i.n and of course some errors for the other files too if they were using similar combinations of supports like above.
2) Example File #2: 560005i.n
See following 1 error for 560005i.n
---------- NEUTRAL FILE TRANSLATOR LOG ------------
Neutral File Input = 560005i.n
Error retrieving Support Type: 81804D4GG
Now let’s look at what is wrong with support type at 81804D4GG
NS, 81804D4GG,,CODE1, 11
MPROP,NS, 81804D4GG, 2,,0.000000,0.000000,0.000000,0.000000,0.000000,0.000000
Looking at the above NS element tag in .N file, it is clear that there is no Support Type parameter mentioned (blank) and thus a warning during import. Issue was fixed by updating the .N file by a support type of 5G1 which maps to a GUIDE. You can choose any other appropriate support type too.
NS, 81804D4GG,5G1,CODE1, 11
MPROP,NS, 81804D4GG, 2,5G1,0.000000,0.000000,0.000000,0.000000,0.000000,0.000000
This solves the problem with 560005i.n
3) Example File #3: 560001i.n
See following 12 errors for 560001i.n
---------- NEUTRAL FILE TRANSLATOR LOG ------------
Neutral File Input = 560001i.n
Error retrieving Support Type: 8180400GG
Error retrieving Support Type: 81804D2GG
Error retrieving Support Type: 81804D3GG
Error retrieving Support Type: 81804DDGG
Error retrieving Support Type: 81804DEGG
Error retrieving Support Type: 81804DFGG
Error retrieving Support Type: 81804E0GG
Error retrieving Support Type: 81804E1GG
Error retrieving Support Type: 81804E2GG
Error retrieving Support Type: 81804E4GG
Error retrieving Support Type: 81804E5GG
Error retrieving Support Type: 81804E6GG
Lets start by looking at 8180400GG
DS, 8180400GG,5US-080,CODE1, 73, 906
MPROP,DS, 8180400GG, 2,5US-080,0.000000,0.000000,0.000000,0.000000,0.000000,0.000000
MPROP,DS, 8180400GG, 4,0.673,0.7396,0.0,0.0,0.0,-1.0
It appears to have a valid support type 5US-080 that does have an entry in the support map file as well.
5U(S,G)- VSTP
So there must be another support at the same point and there may be a missing mapping for the combination of 2 supports like that. A nother another support at the same node 73 which is listed below
DS, 81803FFGG,5HR2,CODE1, 73, 909
MPROP,DS, 81803FFGG, 2,5HR2,0.000000,0.000000,0.000000,0.000000,0.000000,0.000000
MPROP,DS, 81803FFGG, 4,0.7396,-0.673,0.0,0.0,0.0,-1.0
5HR2 is also a valid support type from mapping file. But what we are looking for is a mapping that allows these 2 supports together i.e. 5US-080 and 5HR2 at the same node. Typically no such mapping exists and thus ended up adding the following mapping to the SUPPORTS.MAP file
5U(S,G)-+5HR(1,2,3)- VSTP
This solves the problem for 8180400GG. All of the remaining 11 errors are caused by an NS with no support type much like 560005i.n. This was fixed that by updating all of NS to use a 5G1 support type that maps to a guide. You can change it a more appropriate support.
Error Message: Error retrieving Support Type: ***** - #2
---------- NEUTRAL FILE TRANSLATOR LOG ------------
Neutral File Input = 560001i.n
Error retrieving Support Type: 81804E9GG
This was caused by following two supports:
NS, 81804E9GG,560-MS-053,CODE1, 8
MPROP,NS, 81804E9GG, 2,560-MS-053,0.000000,0.000000,0.000000,0.000000,0.000000,0.000000
DS, 818045DGG,5UG-090,CODE1, 8, 902
MPROP,DS, 818045DGG, 2,5UG-090,0.000000,0.000000,0.000000,0.000000,0.000000,0.000000
MPROP,DS, 818045DGG, 4,0.673,0.7396,0.0,0.0,0.0,-1.0
Looking at default Supports.map file, it was obvious that first support did not have any support type mappings i.e. for 560-MS-053. Solution was file needed a line in the mapping file for NS support like
560-
Now since this NS support is used in conjunction with another support which has a support type = 5UG-090 - we would need our mapping to reflect the fact that 560- support can come along with the other support:
So by adding only 1 line in Support.Map file will fix this.
560-+5U(S,G) VSTP
Error Message: Error Retrieving Support Type: ***** - # 3
The following warning messages in the *.err file
Warning: invalid spec code; pipe name ignored: 60.00000
Error retrieving Support Type: 82800003G
Error retrieving Support Type: 82800013G
Warning: invalid spec code; pipe name ignored: 20.00000
Error retrieving Support Type: 82800016G
Adding the following assemblies in supports.map fixes the support type errors above.
Assemblies do provide mapping many supports at one location to 1 or many different Autopipe support types.
Note: supports at node 12 are 5FSX1-W and 5G2 which are both mapped to VSTP
5G(1,2,3);+5S(1,2,3)(C,G,M)(3,4,5,6)(L,#); GUID,VSTP
5FSX1-W;+5S(1,2,3)(C,G,M)(3,4,5,6)(L,#); VSTP
Note: Amended supports.map to the following.
!5S(1,2,3)(C,G,M)(3,4,5,6); VSTP
5S(1,2,3)(C,G,M)(3,4,5,6)(L,#); VSTP
Note: In some cases guides and vstops are mapped at the same point which makes the vstop redundant.
"Warning: invalid spec code...."
Option 6 for pipe identifiers is limited to 6 characters
Using option 6 = 3 in strait.cnf is causing this warning message we recommend changing this option to 0
Error Message: Error retrieving Coordinates for Node: 0
Block switch change is ok in Defstr.dat but it appears the STRMAP.TBL and Defstr.dat files were not used by PDSstress module to create the 5000.n file
The path in Defstr.dat is not updated - is this your correct path?
c:\win32app\ingr\pdstress\dat\strmap.tbl !PDS TO STRESS MAP
Other clues to not using the provided configuration files, For example, There are components like "RE" and "TW" in the neutral file that we don't support. Another example is that the number of comma-delimited items in the PI card should be 6, but in 5000.n, the number of items is 7.
Error message: ** Starting model at node 0 **
No. Index Type Comp.Id P1 P2 P3 P4 P5 P6 P7
--- ----- ---- ---------- ---- ---- ---- ---- ---- ---- ----
The systemname.n pds file did not convert correctly because
The did not use DEFSTR.DAT to create the PDS neutral file sktest.n.
Typical PI component using DEFSTR.DAT:
PI, 580001GG,6"4001_01_02_07,CODE0, 7, 6
MPROP,PI, 580001GG, 1,API-5L-B,0.000000,0.000000,0.000000,001
MPROP,PI, 580001GG, 3,6.0,168.300003,BW,S-40, 80001GG
MPROP,PI, 580001GG, 4,6.0,168.300003,BW,S-40, 80001GG
Contrasting PI component from sktest.n:
PI, 5CB00FE7,10"STD5356030,,CODE1, 7, 8
MPROP,PI, 5CB00FE7, 1,A106-
B,0.0000E+00,0.0000E+00,,0,,0.0000E+00
MPROP,PI, 5CB00FE7, 3,10.0,273.049996,BW,9.271,, CB01421
MPROP,PI, 5CB00FE7, 4,10.0,273.049996,BW,9.271,, CB01421
Try re-creating the *.n file using the DEFSTR.DAT sent by Bentley.
PDS Interface Error Report
PDSSTR version 06.04.01.10
o21091.n & pw16034.n
! Date : 13-MAR-2002 11:12:06
*** WARNING - W4 ***
Unable to locate end prep, default end prep used
End prep : 300
*** WARNING - W4 ***
Unable to locate end prep, default end prep used
End prep : 300
*** ERROR - E35 ***
Error searching for PDS item name in PDS to STRESS map
Item name : 5LP
PDS to STRESS map : c:\win32app\ingr\pdstress\dat\strmap.tbl
This warning message can be ignored *** WARNING - W4 ***
In both your PDS model neutral files (pw16034.n & o21091.n), the files appear to have terminated prematurely because of an error during the PDS neutral file creation process. Hence, the information in the files is not complete. In one model (pw16034.n), it appears that the mapping data for the component item name “5SLE” is missing from the PDS to STRESS map file as reported in the first pdsstr.err file. In the other model (o21091.n.n), it appears that the mapping data for the component item name “5LP” is missing from the PDS to STRESS map file (strmap.tbl) as reported in the second pdsstr.err file. To fix this problem, you will need to provide the missing component items in the PDS to STRESS map file (c:\win32app\ingr\pdstress\dat\strmap.tbl) and re-generate the PDS neutral files. Please let me know if you need further assistance.
Partial completion of NTL file
Open up and review the *.n file created by Intergraph, Sometimes PDS stress interface module generates a bad file or an (*.n) file was created by some other program where the format cannot be read by STRAIT. Here are some of the anomalies that were observed in such a file:
1. The same component identifier "31B000CBG" is defined twice in the PDS neutral file but with different node numbers:
RB, 31B000CBG,6"WCAAAAWAAA,CODE0, 914, 36
RB, 31B000CBG,6"WCAAAAWAAA,CODE0, 902, 36
2. Some components are defined twice in the PDS neutral file. For example, component 51B0010BG is defined on line 167 and again on line 447. Similarly, component 31B000B9G is also defined twice on line 162 and again on line 442.
3. Not all the end nodes (node > 900) are referenced by the components in the PDS neutral file. In other words, how is possible that only 2 of 24 end nodes are referenced by the model (nodes 902 and 914). STRAIT relies on an end node or nozzle (LNOD) to start an AutoPIPE segment. Consequently, after starting segments at nodes 902 and 914, there were no other end nodes left in the model for STRAIT to start from. It would be possible for me to modify STRAIT to start from a free end, but this would require a lot of processing time to identify all the free ends in a large model.
4. The processing history of 020524b.n is given in 020524b.dbg. Notice that after processing the olet component 31B000B9G, STRAIT does not search for a connecting component at node 37 of the olet. STRAIT is designed to stop at the olet in order to avoid 90 degree kinks in the segment. The assumption is that STRAIT will process the header later and connect it to the olet at that time. In the model you sent me, the corresponding header for the olet had no end nodes and consequently, STRAIT could not start a new segment from the beginning of the header (see comment 3 above). It might be possible for me to modify STRAIT to start a new segment from an olet node in the special case where there are no other nodes to start from as in 020524b.n.
Support Delimiter string
The Strait.cnf file contains a Support Delimiter string as shown below which the default is "-" which signifies the end of the callout.
SETTINGS
0.25 ! Minimum Pipe Size
SSTD ! Default Schedule/Thickness
CS ! Default Materials
- ! Support Delimeter string
This can be changed to any other character e.g "&", "$" etc especially if "-" character exists in the PDS support numbering e.g 5ASW-10
In PDS 2 support types are available NS = non-directional supports e.g typically v-stops and
DS = directional supports e.g. anchors where the direction cosine is defined by a pipe point (<900) and end point (>900).
PDS 1-way support
STRAIT can process 1-way PDS supports if they are mapped to either INCL, ROTA, or DAMP in the supports.map file. It works for both “DS” and “NS” component types. For “DS”, STRAIT calculates the direction cosing using the “from” and “to” nodes in the “DS” card. For NS, STRAIT defaults the direction cosines to 0,1,0.
Support not translated #1
There are 3 issues with the .N file that are causing the error messages.
A support cannot be defined at a tee or olet point – node 26 in an olet point as defined on the line “ 5 21 OU 32B0023EG 26“ in the .N file. You can confirm by moving the support to node 27, i.e. change 26 to 27 for the support in the .N file and the problem does not occur.
23 NS 82B000DBG 26
Disconnected segment – Node 21 do not connect back to any other components in the main part of the model.
57 32 PI 52B07531G 20 914
58 3 PI 52B000D3G 21 20
Disconnected supports – the two supports below do not connect to any piping node, e.g. nodes 19 and 29 are not defined in any of the piping components.
4 NS 82B000D9G 19
30 NS 82B000DCG 29
Component Mapping #1
Several of warning messages we get are related to supports because we do not have your updated supports.map file.
Note: The filename.err file contains list of all the warning and error messages.
Several of following components appear to not have all fields written to PDS neutral file:
Warning: mismatched fields; Component ignored: 6180032GG
Warning: mismatched fields; Component ignored: 6180033GG
e.g. only 5 instead of 6 fields plus properties for this Olet, We believe this is mapping issue in your strmap.tbl for these 2 components.
OL, 6180033GG,, 927, 109
Several warning messages related to line numbers not found in the project.lst file but also there is a column missing for corrosion, see updated project.lst attached.
Error reading Line List File: 1001
Error reading Line List File: 1029
Error reading Line List File: 1010
Error reading Line List File: 1341
Warning: invalid spec code; pipe name ignored: 100.0000
Using option 6 = 3 in strait.cnf is causing this warning message we recommend changing this option to 0
2 unprocessed components - check connectivity of the PDS model because these PDS components do not have any other nodes connected to.
These appear to be part of the orifice plate e.g instrument piping and may be best to ignored this message.
Warning: unprocessed Component found: 6200022GG
Warning: unprocessed Component found: 6180031GG
Appears orifice plate needs to be mapped to flange, FL (or RB ,rigid body) in the Strmap.tbl
STRAIT component not mapped
The component type discrepancy between E24 and E25 is a mapping issue when generating the PDS neutral file. In the PDS neutral file (HPS.N), the component type "RB" is specified for the PDS component ID "6388004EG". The "RB" was assigned based on a component mapping file, "strmap.tbl", when generating the PDS neutral file (*.n). AutoPIPE then converts any "RB" components in the PDS neutral file to a rigid pipes which are shown in magenta color in the AutoPIPE model.
RB, 6388004EG,Inst-**PV-007,CODE0, 82, 107
PROP,RB, 6388004EG, 1,,3.000000,0.000000,0.000000,18004001
PROP,RB, 6388004EG, 2,CL150,CL150,0.000000
PROP,RB, 6388004EG, 3,6.0,6.625000,WN,NREQD, 3881100G
PROP,RB, 6388004EG, 4,6.0,6.625000,WN,NREQD, 3881100G
If the component defined between E24 and E25 is actually a valve, then the component map file (strmap.tbl) need be updated to assign "VA" instead of "RB" to the PDS component type defined between E24 and E25. Additionally, if there is no component mapping information for the PDS component type in strmap.tbl, it will be mapped to "RB" by default.
Material Default
Material defaults to CS instead of A106-B
You have setup to use the materials.map file in the strait.cnf file i.e option 8 = 1, hence Strait will try to map materials found in
the PDS neutral file to Autopipe materials - if not found then defaults to material in strait.cnf file.
There are no material names (i.e blank) defined in the PDS neutral file - appears no materials defined in the PDS model.
You can set the default material A106-B in the strait.cnf for all materials for all pipes to be set to A106-B
Disconnected segments and DBG file
Besides tees and olets, supports cannot be added to bend centers. This is a just a logical condition programmed in the translator. Please log a request if needed to be removed.
The disconnected components and supports are reported in the DBG file. In the example below, nodes 19 and 29 are not defined on any other piping components in the PDS neutral file.
Warning: Unprocessed Components:
Index Type Comp.Id P1 P2 P3 P4 P5 P6 P7
----- ---- ---------- ---- ---- ---- ---- ---- ---- ---
4 NS 82B000D9G 19
23 NS 82B000DBG 26
30 NS 82B000DCG 29
For the disconnected segments, you need to check the error message file and look for any warnings like the one below.
Warning: possible unconnected segment found: I1
Then, you need to look in the DBG file for the block of components that belong to the disconnected segment as shown below. In the example below, node 914 is an end point and node 21 is not defined on any other piping components in the PDS neutral file. So, the entire segment is “disconnected”
** Starting new segment from I1 **
51 32 PI 52B07531G 20 914
52 3 PI 52B000D3G 21 20
The DBG file has all the information one needs to troubleshoot modeling problems created by PDS
Scenario 1
The two supports below defined in the “plantsteam.n” model neutral file could not be processed because the “P1” nodes are not defined on any piping component in the model neutral file. The “P1” node appears to be the center node of a component but the component itself is not included in the model neutral file. This problem could be caused by improper modeling in the PDS model or invalid mapping of some of the PDS components in the “strmap.tbl file” or improper mapping of the two supports in the “supports.map” file.
Type Comp.Id P1 P2 P3 P4 P5 P6 P7
---- ---------- ---- ---- ---- ---- ---- ---- ---
DS 86080001D 2032 936
DS 860800020 2047 940
Scenario 2
There are two set of pipe segments below in which both ends of the segments are not connected to any other component in the main model.
Segment 1: node 913 is a free end node. By definition, a free end node are not connected to any other component. Node 423 is not defined on any other piping components in the model neutral file.
RB 36080000F 913 430
NP 36080000E 428 430
VA 36080000D 426 428 2009
NP 36080000C 423 426
Segment 2: nodes 966 and 970 are both free end nodes. By definition, a free end node is not connected to any other component.
RB 3608001EA 966 6
NP 3608001F3 6 5
VA 3608001F4 5 4 2069
NP 3608001F5 4 3
RB 3608001F6 970 3
If there are actually components defined in the PDS model at nodes 913, 423, 966, or 970, then the problem could be caused by improper modeling in the PDS model or invalid mapping of some of the PDS components in the “strmap.tbl file”.
AutoPIPE Crashes when importing file
AutoPIPE program crashes when import the STRAIT converted file.
Answer: Confirm that there is not a close loop in the original PDS model. At this time AutoPIPE V8i 9.6 and lower does not support a close loop, segment connected back onto it self.
Enhancement has been logged: CAE-CR-9416: Add ability to import closed loop segments from PDS
Auto-numbering to exceed the point name character limit
When using long file names on the Intergraph PDS neutral file (.n), for some reason the strait system uses the tenth character of the filename as a prefix for the autopipe point name. This additional character causes the auto-numbering to exceed the point name character limit (4) in most pipe systems.
Examples:
File name = 1234567890.n, corresponding AutoPIPE node name A020
File name = 1234567895.n, corresponding AutoPIPE node name A520
File name = 0987654321.n, corresponding AutoPIPE node name A120
Answer:
This a memory override in the application as the file names should adhere to DOS naming convention. In additon, from STRAIT documentation:
System Name: Enter the name to be given to the system. A maximum of eight (8) characters can be used to specify the system. The Batch Input File will have this name with a ".NTL" extension, and the AUTOPIPE data file will have this name with a ".DAT" extension. Use this name with the ".DAT" extension to work on the model in AutoPIPE.
The following enhancement has been logged: CAE-CR-11095 Add support of long file names (> 8 chars).
Until this has been added, the only option is to use 8 or less characters for actual file names.
Update: A new version of the translator is available, 06.00.00.14, to be automatically included in AutoPIPE V8i 09.06.01.xx and higher. Log a service request if you need this feature before the version release.