Applies To Product(s): AutoPIPE, Version(s): 2004, XM, & V8i Environment: N/A Area: Translator Subarea: 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, 999 12 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.0 00000,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). 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,1800400 1 PROP,RB, 6388004EG, 2,CL150,CL150,0.000000 PROP,RB, 6388004 EG, 3,6.0,6.625000,WN,NREQD, 3881100G PROP,RB, 6388004 EG, 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 200 9 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. See Also Bentley AutoPIPE External Links Bentley Technical Support KnowledgeBase Bentley LEARN Server Comments or Corrections? Bentley's Technical Support Group requests that you please submit any comments you have on this Wiki article to the "Comments" area below. THANK YOU!
↧