When I create a liner element adjacent to an existing liner element, I get the warning “+++ Element 558 has duplicated or same-position nodes of Element 530”. But I want the new element to use the same nodes that already exist in the old element. How do I force it to do that? (I see the distinct keyword, but I actually need the opposite of that).
If using the same structure ID (e.g., ID=1), they will share the same nodes at the same position. However, for different type of structures (e.g., cable & liner), this method is discouraged. For this case, just use the “structure joint” command.
Also be aware that if you simply wish to modify the liner properties (E, nu, thickness), then you should do that to the existing liner. Note that FLAC3D is an incremental formulation, and so the current loads acting on the element will not be affected if you change its properties. But the new stiffness will be used to subsequent motion. Also, note that if you put two liner elements together using the same nodes, then the stress recovery scheme will not work properly.
Thanks for the tips. Why does the stress recovery not work for liner elements joined with the same nodes? Surely most of the elements share nodes when you install the liner. Do you mean that it’s a problem if a section of liner is added later that shares the nodes? Presumably stresses in the old section will be different from stresses in the new section and the stress recovery scheme doesn’t work well? Do you recommend NOT sharing nodes when new sections of liner are added?
I should say “merge” rather than “join”. I’m thinking that you want to use existing nodes when you create new adjacent elements. But maybe you don’t?
It is no problem if Element A shares one or two nodes with new Element B. But my understanding is that the warning “+++ Element 558 has duplicated or same-position nodes of Element 530” means Element 558 and 530 have the same position for all (more than 2) nodes.
My understanding is that there will be only one element if all its nodes are the same using the same ID method. If two overlapped elements are wished, then just use the “structure join” command.
My understanding is that the warning “+++ Element 558 has duplicated or same-position nodes of Element 530” means Element 558 and 530 have the same position for all (more than 2) nodes. and it just is a warning. If you get an error, you can enter points in the range with the tolerance(~0.01).
Just a minor complaint on “structure node join”: I found it is risky and do not understand the reason for the by-default treatment: "if the node does not already possess a node-to-node link, then any existing link is deleted and a new node-to-node link is created. ". Recently I modelled a foundation with intersection liners and these two intersecting liners were joined with “structure node join”. However, during joining, apparently the existing gridpoint-node link was removed and I found soil can be squeezed out of the intersection between the two liners, which is of course not reasonable. After help from Itasca support, I solved this issue by “struct node join side 3 …”. However, this subtlety is likely to be ignored by many.
Hi Cheng, I have a question on the fish function “struct.liner.normal.stress(p,inode<,i>)”. Since the nodes are share by a few liner elements, Is the normal stress obtained for one liner element only for the specifc element? In another word, Is it correct to assume that the total normal stress on the node will be sum of those contributed by each liner elements which share the same node? I found it would be more useful if the normal (and shear) stress can be for each element at the center of the element.
I have to apologise first as my question is not directly related to this topic. However, I cannot post a new topic, so this is currently my only way to communicate on this forum (I had raised this issue to Itasca Support, but apparently this issue is still there in the latest version of FLAC3D, i.e. 147).
Recently when I was checking the results, I found the normal stress distribution along liner elements (maybe shell as well) is not reasonable, for the elements located on the edge of the liner or along the region where two different liners are connected. Then I looked at the example “EmbeddedRetainingWall”. I found the command “struct liner initialize coupling” is not working properly if I use a non-uniform mesh. You can see odd normal stress distriubtion at the bottom edge if you generate the grid using “zone create brick size 11,11,11 ratio 1.2 1.2 group ‘right’”. The results will become worse if the mesh become more non-uniform. However, if I remove “struct liner initialize coupling”, the normal stress calculated by FLAC3D becomes even worse. I have some concern on the robustness of the liner (and shell) elements, though so far the soil capacity seems to be reasonable.
If you want to post new topics, you need to enter a valid license number when you sign up.
If you missed this during the signup, please send a message to firstname.lastname@example.org and send us your license number.
Thanks for the comments. In the manual, however, there is a warning: “This command creates node-to-node links on all nodes in the range by attempting to find another node in the range that is at the same position. If found, and if the node does not already possess a node-to-node link, then any existing link is deleted and a new node-to-node link is created. The new link is rigidly attached in all six degrees-of-freedom to the target node.”
For structures without intrinsically defined node local system, e.g., beam and shell, this should not be a critical issue. For structures with intrinsically defined node local system, e.g., cable/pile and geogrid/liner, the “node join” command should be avoided when connecting different structures because the node normal direction will be averaged at the join. To avoid this issue, just not use “node join” command, but use a node-to-node rigid link for different nodes, even at the same positions.
Again, this is the issue of joined nodes, where the local direction is averaged. Using rigid node-to-node links should improve.
Thanks, Cheng, for your reply!
On my first comment, I guess what I tried to say is that this by-default treatment (deleting any existing link) is risky since intuitively users will think any existing link is retained (at least I was thinking that way). Anyway, just a comment.
On the 2nd and 3rd questions, I will post them again as seperate topics since they are not related to the topic of this thread and you have misunderstood the questions.
Does anyone know if it is possible to join unlike structural elements using links? Specifically I’m looking at a situation where I would like to connect shells and beams at common node points to simulate a floor/column system. I’ve been able to join two shells with a beam acting as a vertical column between them but I would like to extend up to a third level with a new shell and vertical column to basically create a 3-level floor and column system. I’m having some difficulty determining how to create the shell and beam elements and appropriately link them.
You can connect them by node-to-node rigid links. Using the commands:
structure link create …
structure link attach …
Thanks, I’m aware of the general syntax. The issue I’m trying to solve is that it seems like I can only create one link per node, so attaching two beams to the same shell node (i.e. a pair of columns above and below the shell at the same point) is problematic. Is there any way of doing this that you know of?
In one side, one node cannot be more than one source of link. However, you can set a different side number to solve this problem. See the keyword “side” in the doc of “structure link create”.