hexagon logo
Register Sign in
  • State Not Answered
  • Replies 3 replies
  • Subscribers 4 subscribers
  • Views 58 views
  • Users 0 members are here
Options
Related

Model reduction using SOL103, DMIG PCH Format

prasad.guduguntla.external
Hello,
I performed model reduction using SOL103 DMIGPCH format.
  • EIGRL method
 
GRAV or ACCEL loads, Point Loads are applied on the reduced model, Analysis is performed using SOL101. ​
  • From the f06 file, OUTPUT from Weight check matches to the physical model.
  • OLOAD resultant, SPC force resultant, displacements from the GRAV loads shows zero. What could be the reason?
 
for your info:
I performed the same process OP4 format, very thing works out well.
 
Thanks,
Prasad.
Parents
  • 0
    This is a special situation, and it does work for the DMIGPCH method of storing the reduced matrices, but it doesn't work for the DMIGOP2 method of storing the reduced matrices.  The reason it works for the pch method is the .pch file MUST be last in the assembly run, since it has a BEGIN SUPER definition.  This is why if you have multiple external SE, you would include all the .asm files first, then all the .pch files.
     
    Since you put the GRAV loading after the .pch include, it is applying the GRAV loading on these reduced matrices.   This likely only works for the DMIGPCH method, though I haven't tested the op4 method... I did test the DMIGOP2 method and it didn't work.
    ​
    Another consideration- the recovery of upstream results... I had tested this in the past, and while the upstream internal displacements were good, the upstream internal stresses were not.   As long as you aren't expecting upstream stress data recovery, then this ought to be fine.
     
    FYI- the reason the OLOAD, etc was null when the GRAV was above the .pch include is the upstream mass isn't yet include in the assembly run, as the time the GRAV loading is being considered... think of it as being for the Residual only, not the Assembly.  If there were Residual mass, then that portion only would get the GRAV loading.  The Residual is the portion of the model that is physical (SE 0) prior to assembly of any upstream SE.
Reply
  • 0
    This is a special situation, and it does work for the DMIGPCH method of storing the reduced matrices, but it doesn't work for the DMIGOP2 method of storing the reduced matrices.  The reason it works for the pch method is the .pch file MUST be last in the assembly run, since it has a BEGIN SUPER definition.  This is why if you have multiple external SE, you would include all the .asm files first, then all the .pch files.
     
    Since you put the GRAV loading after the .pch include, it is applying the GRAV loading on these reduced matrices.   This likely only works for the DMIGPCH method, though I haven't tested the op4 method... I did test the DMIGOP2 method and it didn't work.
    ​
    Another consideration- the recovery of upstream results... I had tested this in the past, and while the upstream internal displacements were good, the upstream internal stresses were not.   As long as you aren't expecting upstream stress data recovery, then this ought to be fine.
     
    FYI- the reason the OLOAD, etc was null when the GRAV was above the .pch include is the upstream mass isn't yet include in the assembly run, as the time the GRAV loading is being considered... think of it as being for the Residual only, not the Assembly.  If there were Residual mass, then that portion only would get the GRAV loading.  The Residual is the portion of the model that is physical (SE 0) prior to assembly of any upstream SE.
Children
No Data
© 2025 Hexagon AB and/or its subsidiaries. Privacy Policy | Cloud Services Agreement