Hello everyone,
Is it correct to import a surface then create a liner from it even if its mesh doesn’t correspond to the zones mesh ? The targets of link are zones, but I want to make sure if it is a correct method or shall I coincide the zones mesh to the surface mesh.
Thank you
Hello @Zakaria,
The liner nodes do not need to correspond with zone gridpoints. Links will automatically detect zone targets and distribute force, mass, stiffness etc. to the zones automatically based on weighting functions (i.e. were the end lands in the zone).
Hi again @dblanksma
Could you please tell me if it is possible to change the liner nodes local system ? I see that struct.node.system.local — Itasca Software 9.0 documentation (itascacg.com) can only get the local system but not set it.
Are there any specific requirements or guidelines regarding the local system in relation to the surrounding zones?
One last question, while assigning a groupName to zones, gridpoints also get the groupName. Isn’t it the case for structure nodes ?
Thank you for your help.
Hello @Zakaria,
You can set the node local coordinate system with the command - structure node system-local …
For one-sided liners here is how the orientation of the node-local coordinate system is defined in the online documentation:
The orientation of the node-local system for all nodes used by liner elements is set automatically at the start of a set of cycles (or when the
model cycle 0command is executed) such that the 𝑧-axis is aligned with the average normal direction of all liner elements using the node, and the 𝑥𝑦-axes are arbitrarily oriented in the liner element tangent plane
For two sided liners (also called embedded liners) the orientation of the node local coordinate system may not always be consistent and using the above command may be necessary.
@Zakaria,
And for the grouping name inheritance. I believe structure nodes do inherit the same group name as their parent elements. But I could be wrong on this.
Thank you @dblanksma
I have encountered another issue in my exercise. While attempting to import certain liners, I chose a one-sided liner for some and added the embedded keyword for others to make them two-sided.
For the one-sided liners, I can manipulate the links without any issues. However, when dealing with the two-sided liners, I consistently receive the message: ‘No valid nodes were found, no links were created’ . Strangely, when I switch back to using one-sided liners, everything works fine.
Could be there something I am overlooking or not aware of?
Hello @Zakaria,
In this case, the only thing I can think of is that you may need to separate the zone faces where you intend to place the imported embedded liner. I’d suggest using the zone separate by-face command before importing the liner to see if that resolved the issue.
Thank you so much Derrick, it works and motivation’s back.
Have a good day man !
Hello again,
I’m back with another issue : is there any explanation to why imported liners behave like this ? Despite extracting its mesh from Griddle’s global mesh and imposing the number of segments, it still generates additional elements.
I’m starting to believe that using commands or FISH to generate liners might be a more effective solution for automating this process.
Hi,
The plot being labels of link models for structural nodes, each node is represented/colored by its representative area. In regions where adjacent nodes have the same link model, limits between node representative areas are not shown, but only element edges. In regions where adjacent nodes have different link models, such as in this case, these limits are shown. So it does not look like you have additional elements, but may be target detection for those links.
Thank you @xpnguyen, I get it.
Have a good day !
