Message error in inhomogeneous boundary conditions

AndreaAndrea
See the liml file. Is a simple example of wrong message error (If the procedure is right)
A bar must be bended 50 mm 45° direction respect the XY plane (NL analysis). Mecway gives error but the problem can be solved.
Launch inp file and check displacement on XY plane at time 1s (dx^2+dy^2)^0.5.

I don't know if I made a mistake using Mecway.

Regards

Comments

  • AndreaAndrea
    P.S. Other problem. Launching inp file (the attached one) from Mecway you receive a wrong message error. Launching inp from SCITE (same CCX version) there is no problem. Also opening frd file with Mecway you will have the correct postprocessing. See attached liml file
  • VictorVictor
    For the first problem, you're right that it could have solved it but didn't. Mecway is currently more restrictive than CCX in cases like this where the it's complicated to determine if the CCX rules are being satisfied so it errs on the safe side. The particular risk here is that CCX doesn't allow two different time dependent displacement constraints on different DOFs of the same node if there's also a *TRANSFORM card on it. You can solve it by hand here because one of these conditions is met:
    1) The *AMPLITUDE functions can be written to be identical or
    2) The two constraints are aligned with the global axes.
    In general, those might not be true and Mecway assumes they're not.

    However, as the error message suggests, it does check for zero constraints and allows those to be combined. So you can work around it by changing the two orthogonal constraints to one 45 degree time dependent constraint and one -45 degree zero constraint as in the attachment.


    For reading the .inp file. It shows these error messages on the Analysis node of the outline tree. I think they're all correct, aren't they? It's ignoring *PLASTIC and *AMPLITUDE so it won't correctly solve. Importing .inp isn't something I'm developing very much because it doesn't seem to be as widely used as exporting/solving with .inp so a lot of features are missing.

    *PLASTIC line 335: Keyword is not supported.
    *AMPLITUDE line 364: Keyword is not supported.
    *AMPLITUDE line 366: Keyword is not supported.
    *NODEFILE line 394: Keyword is not supported.
    *ELFILE line 396: Keyword is not supported.
    *NODEPRINT line 398: Keyword is not supported.

  • AndreaAndrea
    OK! I understand that combination of boundary with *TRANSFORM, *AMPLITUDE (similar to CLOAD, DLOAD) could lead to error or to lack of a load(constraint). I read that Guido Dhondt, under your suggestion, is going to update the manual, so the situation will be more clear.

    About reading inp file depends from the scope, but I think that's important taking into account the great capabilities of Mecway on postprocessing:

    manually modified inp -> import -> solve -> postprocessing
    inp file found on forum or shared-> import -> solve-> postprocessing

    Maybe it depend also from my own think because I worked several years with Roshaz and I appreciate this kind of procedure (see picture)
  • VictorVictor
    I don't think Mecway will ever be good for that workflow: Open .inp -> edit -> save .inp -> solve because its internal format for everything is so different. The .inp import is mainly for meshes and a lot of the less common cards are missing, as you've found.
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