1
Download PRIMER 10.0 user manual
Transcript
PRIMER User manual Version 10.0, June 2011 How data transferred by NAME gets special treatment When data is transferred by NAME it is possible that more than one object in the target model will match an object in the source model, in which case multiple copies of the source data will be transferred into the target model. For example consider the following case for materials where EITHER name matching is used: Original target model contents Source model contents Resulting output in target model MAT #1 "Steel 316s12" MAT #1 "Aluminium" MAT #2 "Generic steel" MAT #2 "Steel to BS4360" MAT #2 "Generic steel" MAT #2 "Generic steel" MAT #3 "Special steel for supports" MAT #3 "Concrete" MAT #2 "Generic steel" In this case all three target materials contain the word "steel", so they will all be overwritten by material #2 (Generic steel) from the source model. This would leave three materials in the target model with the same label, so how is this resolved? What happens is this: Every existing target object that is about to be overwritten has its properties copied to the highest object label + 1. In this case since superseded data is to be SAVEd, before overwriting the "old" source material properties: • Original target material #1 is copied to #4. • Material #2 is copied to #5 • Material #3 is copied to #6 These new (#4 .. #6) definitions are not referenced by anything, and are placed into a separate include file. If they are not required a CLEANUP_UNUSED operation will delete them. Source object data is copied in verbatim • • Source material #2 is copied verbatim into target materials #1, #2 and #3 At this stage there will be 3 materials in the target model all labelled #2 - clearly illegal A post-transfer check and sorting out takes place Once all transfers by NAME have taken place then any clashes or illegalities in the target model are sorted out. • Where any incoming label from a source object clashes with a pre-existing (but not overwritten) target object of the same label, then that original target object is re-labelled. • Then a check for multiple instances of transferred in objects is made (which will all share the same label), and these are "collapsed" into a single definition. In the example above the three target materials, all labelled #2, would be collapsed into a single material definition and all references to them (eg from *PART cards) are implicitly also rationalised to reference this single material definition. How are objects such as loadcurves which might be referenced by transferred data handled? For example you might transfer a material which contains references to loadcurves in the source model. In this situation these "supporting" objects are also transferred, although the logic for handling label clashes in the target model differs from the data above: • If there is no label clash they are copied in "as is". • If there is a label clash the original definition in the target model is renumbered to a free slot, and the new data is copied in. Page 6.392
