You're right that they should behave the same if you scale time.
Since the error message refers to the minimum increment (time step) size, I'd look at that. The default minimum is supposed to scale with time period but maybe Mecway overrode it inco…
@RPP, I'm not clear on why you want the formula to use the coordinates of the midplane instead of the faces that receive the pressure. From the drawings, it looks like the way it works is ideal for your situation. The midplanes should move as the th…
The eigenvalue solver CCX uses (ARPACK) can't find the highest couple of modes. In this case, it looks like there are only 10 modes in total, so you may have to add some dummy elements with higher frequency modes to occupy the top of the range.
#Hengre, I just look up things for Python 2 and they usually work in IronPython 2.7. The manual for IronPython is just a link to the manual for Python https://ironpython.net/documentation/
Thanks for bringing this up. In some cases, that's the correct behavior, such as when the line elements are laid along the edges of shells, but not here where they're simply joined end-to-end. I'm not sure if I can fix it without creating more stran…
Unfortunately, Mecway intentionally reads only the highest-dimensional elements from UNV files because lower-dimensional ones are usually redundant edges or surfaces and not really part of the mesh for FEA. So that's why Sergio's suggestion of not h…
@Hengre, "\" indicates a special character in Python. For an actual backslash use two:
subprocess.call("C:\\temp\\test.exe")
I guess the Gmsh one works because \g isn't anything while \t is tab.
I prefer forward slash for paths. It works in Wind…
There are a few ways. Here's one that starts an external process and waits for it to exit before continuing with the script: import subprocess subprocess.call("notepad.exe")
The red and error message is because the Dynamic Response 3D analysis type is linear so it can't have contact. But if it's present, CCX quietly changes to nonlinear so it does work but with all the other effects of nonlinear analysis which you told …
Don't read too much into the orientation of the end faces. I think they follow the rotation of the node without regard to the pin so:
When the column is pinned, the beam and node rotate together.
When the beam is pinned, the node remains unrotated …
@Sebastianmaklary you can uninstall OneAPI after making copies of those DLLs so I would just install everything. However, anything to do with Python is probably not needed.
Looks like I need to update the build script and makefiles for the new OneA…
Unfortunately, I don't know what the error code means.
If you're getting a surface mesh but not a solid mesh, it could be that the surface isn't properly closed (manifold). Did that hole you made have a properly connected inner wall? One way to che…
Oh, from looking at @prop_design's model, I think I see what's going on. In the deformed view of the solution, the pin symbols sometimes rotate to funny directions. This is a graphical bug where the rotation of the elements causes their orientations…
Also interested in what this is in case it's a bug. The deflected view doesn't seem to be consistent with the symbol which is supposed to be oriented like a pin in a pin joint.
It looks like Distributing displacement not responding-2.liml fails because of the extreme deformation which is way beyond what a linear material can do correctly anyway. I also get a solver failure with the rotation constraints enabled but the disp…
I've reproduced the failure of Distributing displacement not responding-2.liml that happens when you suppress all 3 node rotation constraints. It happens in both CCX 2.17 and 2.19.
It also happens when I extrude the mesh to solids. I'd rather focus…
Mechanical constraints shouldn't interfere with a thermal analysis. But some of them, such as node-surface coupling and pre-tension section generate extra nodes which would cause that node count mismatch problem.
Could you tell me what mechanical c…
That's the normal way unconstrained rigid body rotation works in FEA (and in real life!). You sometimes get a random rotation or solver failure. It's still a correct solution but there isn't a unique solution.
@disla. I'll try with 2.19 and get back to you. Seems OK on 2.17 with the 3 node rotations suppressed except the solution doesn't complete all the way to 100%.
@prop_design. You can download by clicking the rectangle bar that shows the filename ins…
I think that distortion is really just very large rigid body rotations. If you reduce the deformation scale factor, it looks more like rotation. I can't easily tell where the axis of rotation is and if it's correctly rotating about the reference nod…
You example appears to work correctly for me. I don't get any rotations, and only the (500, 500, 500) mm displacement. This is with CCX 2.17 so I wonder if something has become incompatible in later versions.
Bear in mind that *RIGID BODY isn't k…
Yes but not in a wrong way. Displacement constraints and forces on the Reference node end up on the REF NODE for CCX while rotations and moments on the same Reference node end up as DOF 1-3 constraints and loads on on the hidden ROT NODE.
I'm start…
Thanks for the investigation, disla. You're right that there's a lot of strange-seeming interdependencies between different kinds of constraints, but I don't think what you've found here solves the problems.
A displacement like (500,500,0) doesn't …
Oh, sorry, I didn't notice you were talking about *DISTRIBUTING COUPLING. Yea, they're certainly different. I found something was strange about that and never really used it.
Doesn't explain why it won't solve properly for you though.
Distributing displacement not responding.liml works for me with CCX 2.17 and the offset loads in Distributing.liml don't seem to cause any moments. The displacement also works there. Maybe this is that issue of the latest version of CCX not being co…
Maybe it's changed in the latest version but I didn't think there could be a moment due to an offset reference node. Is that really *DISTRIBUTING, not *RIGID BODY? From what I understand, the position of the reference node is ignored by *DISTRIBUTIN…
This might be too simple to help but here's a test case with Ramberg Osgood which converges. Apparently the YY strain is supposed to be 0.01192736 according to the formula and the solution agrees with that.