Linear buckling of composite laminate shells

StureSture
My analysis is running on both the native and CCX solver. However, on the CCX solver I cannot use rotational boundary conditions, which I need on a symmetry plane. The native solver can take rotational boundary conditions. According to your net page the native solver cannot solve laminate buckling.

Is it a bug in CCX?
Is the native solver giving correct answers?

Sture

Comments

  • VictorVictor
    I think CCX is OK with rotational DOF constraints on composites but you have to align them with the shell edge tangents. The Symmetry constraint in Mecway does this.

    Internal solver composite buckling is probably wrong.
  • StureSture
    Hi,
    Alignment with the shell edge is difficult when there are three shells sharing an edge.
    How do I solve that.
    Sture
  • VictorVictor
    It seems easy in simple cases like this. Is yours different, maybe a curved edge shared by multiple shells?

  • StureSture
    Hi,

    This is the geometry. The node lie on a symmetry plane (the xz-plane).

    Sture
  • StureSture

  • VictorVictor
    Oh, I see. At the intersections, I'm not sure what CCX does - maybe it'll tolerate any orientation or maybe almost none. I would just leave them whatever arbitrary orientation the symmetry constraint picks because they're discrete points so errors due to insufficient constraints should disappear with refinement.

    Either way, do use the symmetry constraint, not that way. That will put only a single rotation constraint on each node and align it properly for CCX. Two rotation constraints like that can cause error.
  • StureSture
    Hi,
    CCX returns with an error and stops. I also tried the symmetry BC, but it does not work where several elements meet.
    Sture
  • VictorVictor
    You might need to exclude those edges from the symmetry. You should be able to at least put a displacement BC on them. The rotational BCs are what usually causes the the problem.
  • disladisla
    edited September 2025
    Hello,

    I think I can help with this.
    To solve the problem one needs to keep in mind that when applying a Symmetry BC in ccx , Victor is first transforming the coordinate system to align it to the shell lip.
    Then 1 Translational DOF and 1 ROT In the new coordinate system are constrained for each node.
    That means that in the GUI, additional BC applied do not refer to the Global CSYS but to the local. X should be now read as (1) , Y should be now read as (2), Z should be now read as (3) with their associated Rotational DOFS 4, 5 and 6.
    If one tries to constrain a DOF that has already been constrained by the Symmetry BC the model fails with the message:

    Error generating inp file: Displacement and rotation constraints cannot be converted to the same rectangular coordinate system on node XXXX.

    To solve it, one needs to open the inp and look at the BC that has come up from the transformation.
    *BOUNDARY 1,3,,0 1,4,,0 2,3,,0 2,4,,0 3,3,,0 3,5,,0 4,3,,0 4,5,,0 5,3,,0 5,5,,0 6,3,,0 6,5,,0 7,3,,0 7,4,,0 8,3,,0 .....
    In this case *BOUNDARY shows that Symmetry has constrained Translational DOF 3 and Rotational DOF 4 or 5 depending on the node.
    So, to end up constraining the base we need to constrain DOF 1 (X) and DOF 2 (Y) no matter the shell orientation.

    Find Example.

    To fully fix the base one should also fix the pending rotational degrees of freedom. That needs a more detailed scrutiny of the inp to find which are the two free Rot DOFs on each node.

    TO VICTOR: ¿Would it be possible to apply the transform in a more consistent way such that in a Symmetry BC , constrained DOFS would always end up as a *BOUNDARY card on DOF1 and DOF5 for example?
    That would make things much easier for the user to complete additional constraints on those nodes and circumvent the actual error. Or even automate it internally for you.

  • disladisla
    edited September 2025
    By the way.
    I’m not aeronautical engineer.
    The proposed example is not intended to show how to constrain the base of a wing. It is just to point or make more evident why the error message emerge.
    Constraining all translational DOFs goes beyond what a strict Symmetry condition is. Constraining additionally 1 and 2 certainly removes rigid body motion in the lift direction, but it also removes other potential failure modes.

  • VictorVictor
    I'd be careful putting any rotation constraints on a shell that isn't parallel to the surface, otherwise the CCX bug may overstiffen it. It think it's safer to exclude the intersections from the symmetry constraint and optionally manually add displacement constraints to them.

    @disla I don't think I can get Mecway to be consistent about which transformed DOFs it uses here because the algorithm also favors using the global axes when they happen to be aligned with them to make it more convenient in the common case of axis-aligned constraints.
Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Sign In Register