🎉Community Raffle - Win $25

An exclusive raffle opportunity for active members like you! Complete your profile, answer questions and get your first accepted badge to enter the raffle.
Join and Win

Does other loads step affect the result of normal mode analysis?

User: "Yinghao_Mei_2025"
Altair Community Member

Description: [I am studying optistruct, and I am doing the analysis of a bracekt with center mass load. I add 2 loadsteps , one is normal mode, and the other is Gload. I found the mode analysis result would be changed per the Gload analysis type. If the Gload analysis type is non-linear static, the modes will be 145HZ 220HZ 351HZ, but if
Gload analysis type is linear static , the modes will be 150HZ 235HZ 266HZ. And if I delete the Gload analysis load step and only keep the normal mode load step, the modes will be 150HZ 235HZ 266HZ. So I guess the result 150HZ 235HZ 266HZ is the correct result , but I don't know why the normal mode result will be affected by other load step. The attachments are the .hm files. thank you.]

Product/Topic Name : [hypermesh and optitruct 2023.1. ]

 

Find more posts tagged with

Sort by:
1 - 3 of 31
    User: "Yinghao_Mei_2025"
    Altair Community Member
    OP

    forget to attachment the .hm files

    User: "yuhaohe"
    Altair Employee
    Accepted Answer

    Theoretically, the normal mode results shouldn't be affected by the presence of another load step (without using PRELOAD), like your case.

    I looked into your model, and it seems the contact is treated differently when there is a nonlinear static load step or not. That causes the difference.

    I don't know exactly what difference in the treatment, but I can get a consistent result by using surface to surface contact (the default is node to surface contact). More details can be found at https://help.altair.com/hwsolvers/os/topics/solvers/os/contact_bulk_r.htm?zoom_highlight=contact

    I attached my model and result using surface to surface contact for your reference.

    User: "yuhaohe"
    Altair Employee

    If you prefer to use node to surface contact, you may add

    CONTPRM,N2SFORM,NOCGAPG

    in the bulk section of the input deck. The problem seems to be related to CGAPG elements that are created for node to surface contact in the backend. NOCGAPG uses a different node to surface contact algorithm.