Add Non-Rigid Joints

[taylormcd]

This package currently only allows rigid connections. A nice feature would be expand this to allow other types of joints. My thoughts for making this happen is to introduce a new type JointAssembly which combines two or more Assembly objects with some joints. Then we can dispatch on the JointAssembly in a special manner to handle the joints. The theory for adding joints is covered in the paper on which this code is based.

[ss1870]

Hi, I would personally be very interested to see this as a feature. Is it something you will be implementing any time soon? Kind regards.

[taylormcd]

I currently don't have any plans to work on this. A pull request for this would be welcome, but it would likely require a significant amount of work.

[ss1870]

I have read and understood the part in the paper where the modification of equilibrium and compatibility equations is described. Could you point me to where exactly in the code these equations are assembled? i.e. Equation 49 and 50 in the Yu and Blair 2012 paper. Thanks very much.

[taylormcd]

The code differs slightly from the paper now. While equilibrium is still enforced in the same manner, compatability equations are enforced for each element instead of at the nodes.

For the static case, point loads are first added here: https://github.com/byuflowlab/GXBeam.jl/blob/6d9b8ad37ec6fe62173561c9cdb540462c04513b/src/point.jl#L2036-L2037 and then the element end loads are added here: https://github.com/byuflowlab/GXBeam.jl/blob/6d9b8ad37ec6fe62173561c9cdb540462c04513b/src/element.jl#L2457-L2464

The position of each residual in the residual vector is defined by the system_indices function.

[taylormcd]

Actually, now that I think about it, the simplest solution is probably just to modify PrescribedConditions to allow prescribed displacements to be linked to the displacements of another node.

[ss1870]

Thank you for the replies Taylor, I've finally got some time to get stuck into this now. I've been looking through the code, making comparisons to the paper, and have a few questions:

1. Eq 39 and 40 of the Yu/Blair 2012 paper - why have you dropped the multiplication of L with gamma? Relevant equations here: https://github.com/byuflowlab/GXBeam.jl/blob/6d9b8ad37ec6fe62173561c9cdb540462c04513b/src/element.jl#L1492 https://github.com/byuflowlab/GXBeam.jl/blob/6d9b8ad37ec6fe62173561c9cdb540462c04513b/src/element.jl#L1910
2. Am I correct in understanding that the 2012 paper defines compatibility equations for each node, whereas you have implemented them for each element? Which means you can drop the 1/2 multiplier from eqs 40 and 41? Relevant lines here: https://github.com/byuflowlab/GXBeam.jl/blob/6d9b8ad37ec6fe62173561c9cdb540462c04513b/src/element.jl#L1492-L1494
3. Moving forward with an implementation that includes joints, do you think it is worth sticking with compatibility being defined for each element, as opposed to each node? One element may have a normal starting node, but an end node that has some freedom, so the overall compatibility equation would be the sum of the start node compatibility, and the end node equilibrium.

[taylormcd]

1. The dropped L term is introduced earlier: https://github.com/byuflowlab/GXBeam.jl/blob/6d9b8ad37ec6fe62173561c9cdb540462c04513b/src/element.jl#L68-L70
2. Yes, I switched to element based compatibility equations as part of a general move from element-based state variables to point-based state variables. This was necessary in order to implement structural damping.
3. The compatibility for the individual element would still need to be enforced. I think the easiest way to add joints would be to add joints between two distinct points, rather than by modifying the equations associated with the element endpoints, as described in my previous comment about modifying PrescribedConditions

[ss1870]

Hi Taylor, I went with your approach suggested in point 3 of your previous comment and I think I've got it working. I forked the repo and have pushed my changes. Currently I've only implemented the joints for a static analysis, perhaps I'll look into it for steady/dynamic analyses in the future. Could you please take a look at my branch and let me know what you think / if anything needs modifying? https://github.com/ss1870/GXBeam.jl

[taylormcd]

I didn't do a thorough review, but it looks good. Extending it to the other analyses is trivial since it would involve the exact same operations.