Twisting in shell solver

Hello Kiwi team:

Glad to say hi to you!:slight_smile:

I have been working through Kiwi for my study recently.

I tried to simulate a basic bending and torsion active beam structure using shell solver in Kiwi.

However, there is some problem comes out related to torsion.

Basically, I used end moment to create twisting:

I added a moment at the end curve to try to rotate the curve support. The result seems that there is even no effect on the shell at all. (no twisting at the end curve)

Could anybody help me with that?

Thanks.


shell solver.gh (36.9 KB)

Hey,

there is not yet the possibility to define specific rotations on shells (still on the ToDo-list). Only displacements are currently possible.
However you could work with point displacements of the corners similar to this example:
Bending_Torsion_Strip_simplified.gh (44.5 KB)
If you want to maintain your clamped edge you have to exchange the following (maybe only similar) lines:
DE-SUP 2 1 DE-BREP 5 CLAMPED --> DE-SUP 2 1 u=1 CLAMPED_Z
and add after LD-COM 1
TYPE=BC-DIRICHLET 2
You can do this with ModifyInput. An example is also in the provided .gh file. Furthermore, you have to check that your boundary conditions are compatible. If you define a fixed support and a moving support at the same location, the behavior is arbitrary.

Regards,
Anna

Hi Anna,

Thanks for the reply and patient answer.:slight_smile: It works properly now. Hope the function to define specific rotation on shells would come out soon!

Could you explain a little bit more about how can I check the DE-SUPs and DE-BREPs visually? Otherwise, it is a little bit annoying that I donot know which element I am working with.:slight_smile:
Besides, what is LD-COM1 and what is the meaning of adding a BC-DIRICHLET TYPE after it?

If you can explain that or if there is any theory behind it, I would be very appreciated!

Unfortunately, you cannot check DE-SUPs and DE-BREPs visually. This is only available in the text file. The only thing you can check is the id of the master element (= element where to add the support).

But in short:
DE-SUP contains all dirichlet boundary conditions. They can either be strong or weak. In the strong case they are defined by u and v at either start or end of the parameter space. They are directly applied to the control points. The location of the weak bcs are defined in the DE-BREP list above. They are defined in the parameter space of the master element.
LD-COM contains a list of all strong boundary conditions (loads and supports). If they are not in this list, they are not considered even if they were defined before.

A more detailed explanation of all parts of the text file can be found here:
http://carat.st.bv.tum.de/caratuserswiki/index.php/Main_Page

And here for the boundary conditions:
http://carat.st.bv.tum.de/caratuserswiki/index.php/Users:Geometry_Generation/Design_Supports

Hello,

Thanks for the reply.
Yes, now I could understand most of it with your explaination. However, I still can’t have a total control of the geometry if I don’t know witch support I am dealing with.
You said it can’t be check visually. Could you please tell me what is the order in the code. For example, here in this model, there seems to have 5 supports. Which one is which?

ok, so a line in the support section has the following components:
DE-SUP 1 1 u=0 DISP_X, DISP_Y, DISP_Z

DE-SUP 1: 1 is the support id, which has to be unique
1: this is the id of the nurbs patch. This id is also shown in the Rhino viewport at the center of the patch
u=0 (v=1): this is the position on the patch in normalized uv-coordinates. Note that it only can be 0 or 1. If there is only u or v defined, it cooresponds to a whole edge. If both are defined, it is one of the corner points. If nothing is defined, the whole patch is subjected to this boundary condition. Instead, there also might be something like DE-BREP 1. This refers to a brep element in the list above including the not-normalized parametric coordinates (or the respective edge).
DISP_X, … : this defines the type of the boundary condition.

So basically, you have to read and interpret the patch id and the parametric coordinates to get the position.
Note that you don’t see any changes in the Rhino viewport as these are still expert functions. Only the automatically detected supports from GHAnalysisModel are there.