Following Cadence Design Systems’ acquisition of the Design & Engineering (D&E) business, the D&E Community Forum on the Nexus Community Center has been migrated in the Cadence Physical System Simulation Community. For more details and if you have any questions, please refer to the FAQ.

Stats

  • State Not Answered
  • Replies 8
  • Subscribers 3
  • Views 11
  • Members are here 0
More Content

BCs for flexbodies

Josef K.
Hello,
 
Is there a way to include SPCs in your model when creating and MNF file for a flexbody? I am asking because when I tried creating an mnf file for a table-like structure, the 1st mode was completely off than when running a simple sol103. The points which were supposed to be constrained were moving freely in the modes (even though I had also included them in ASETS).
 
Is there another way that I can ensure the validity of the constraints when creating an mnf file?
 
Thanks,
 
Josef
Parents
  • 0
    Hello Josef,
    ​
    "the modes of an mnf file do not change when it is constrained"
    Yes. This is because the mnf-file (in likely most cases) is an open, free-free representation of the flexible body. Like your table being unconstrained.
    ​
    "I have no way of making it change throught Adams."
    Yes. The mnf file as the representaion of the flexbody remains the same(, regardless how it is constrained).
    ​
    "When running simple eigenmodes analysis (sol103) constraining the body for it to be in its "final state" leads to its true modes (since in real life, it wouldn't be free-free)."
    Yes. Now it is constrained AND you did the eigenmodes analysis. This combination shows real life behaviour.
    ​
    "So the same should hold true in the mnf file generation."
    No. Generally it is recommended (and e. g. in Adams/ViewFlex the default setting) that any interface node should have all 6 dofs in ASET. Then you have the big advantages that you can later apply any kind of joint or force on the interface node AND the modal base of the flexbody is good. The disadvantages are having more constraint-modes and so having minimal performance reduction.
    ​
    "Thatsa why I asked if there was some mistake in the way I constrained the body for the mnf file creation. [...] Can you build an MNF file for a flexbody which will not be free-free?"
    If you know well about your assembly and you have to reduce the number of constraint modes, then sure you can constrain the body in the mnf file generation process. Then you are "directly" closer at its "final state". E. g. in Adams/ViewFlex you can lock DOFs for any Interface Node in mnf-file generation.
    But did you really do this? I suppose no. Again: The attachment method RBE2 only defines the connection between Master Node and Slave Nodes (as rigid). But the RBE2 in no way are Joints which connect the interface node to the surrounding.
    Last but not least the mnf-file creation should not be able to "use" an Interface Node on which all 6 dofs are locked, because then no constraint mode can be built. In my view at least one dof has to be open for the Int Node in the mnf file gen process.
    ​
    -->
    If you want the Flexbody to be in its "final state", then you have to attach the Joints in Adams (if you didnt lock the respective dofs during the mnf file generation (and I suppose you didnt)). The modes of the mnf-file then do not change, because its still the same. But the modes of the Linear Modes Analysis in Adams do change and (only) this is the "true final state modes".
    ​
    Wave
     
    Bruno​
Reply
  • 0
    Hello Josef,
    ​
    "the modes of an mnf file do not change when it is constrained"
    Yes. This is because the mnf-file (in likely most cases) is an open, free-free representation of the flexible body. Like your table being unconstrained.
    ​
    "I have no way of making it change throught Adams."
    Yes. The mnf file as the representaion of the flexbody remains the same(, regardless how it is constrained).
    ​
    "When running simple eigenmodes analysis (sol103) constraining the body for it to be in its "final state" leads to its true modes (since in real life, it wouldn't be free-free)."
    Yes. Now it is constrained AND you did the eigenmodes analysis. This combination shows real life behaviour.
    ​
    "So the same should hold true in the mnf file generation."
    No. Generally it is recommended (and e. g. in Adams/ViewFlex the default setting) that any interface node should have all 6 dofs in ASET. Then you have the big advantages that you can later apply any kind of joint or force on the interface node AND the modal base of the flexbody is good. The disadvantages are having more constraint-modes and so having minimal performance reduction.
    ​
    "Thatsa why I asked if there was some mistake in the way I constrained the body for the mnf file creation. [...] Can you build an MNF file for a flexbody which will not be free-free?"
    If you know well about your assembly and you have to reduce the number of constraint modes, then sure you can constrain the body in the mnf file generation process. Then you are "directly" closer at its "final state". E. g. in Adams/ViewFlex you can lock DOFs for any Interface Node in mnf-file generation.
    But did you really do this? I suppose no. Again: The attachment method RBE2 only defines the connection between Master Node and Slave Nodes (as rigid). But the RBE2 in no way are Joints which connect the interface node to the surrounding.
    Last but not least the mnf-file creation should not be able to "use" an Interface Node on which all 6 dofs are locked, because then no constraint mode can be built. In my view at least one dof has to be open for the Int Node in the mnf file gen process.
    ​
    -->
    If you want the Flexbody to be in its "final state", then you have to attach the Joints in Adams (if you didnt lock the respective dofs during the mnf file generation (and I suppose you didnt)). The modes of the mnf-file then do not change, because its still the same. But the modes of the Linear Modes Analysis in Adams do change and (only) this is the "true final state modes".
    ​
    Wave
     
    Bruno​
Children
No Data
Cadence Guidelines

Community Guidelines

The Cadence Design Communities support Cadence users and technologists interacting to exchange ideas, news, technical information, and best practices to solve problems and get the most from Cadence technology. The community is open to everyone, and to provide the most value, we require participants to follow our Community Guidelines that facilitate a quality exchange of ideas and information. By accessing, contributing, using or downloading any materials from the site, you agree to be bound by the full Community Guidelines.