Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add Non-Rigid Joints #26

Open
taylormcd opened this issue Jul 1, 2021 · 9 comments
Open

Add Non-Rigid Joints #26

taylormcd opened this issue Jul 1, 2021 · 9 comments

Comments

@taylormcd
Copy link
Collaborator

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
Copy link

ss1870 commented Sep 5, 2022

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
Copy link
Collaborator Author

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
Copy link

ss1870 commented Sep 6, 2022

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
Copy link
Collaborator Author

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:

GXBeam.jl/src/point.jl

Lines 2036 to 2037 in 6d9b8ad

resid[irow:irow+2] .= -F ./ force_scaling
resid[irow+3:irow+5] .= -M ./ force_scaling

and then the element end loads are added here:

GXBeam.jl/src/element.jl

Lines 2457 to 2464 in 6d9b8ad

irow = indices.irow_point[assembly.start[ielem]]
@views resid[irow:irow+2] .-= F1 ./ force_scaling
@views resid[irow+3:irow+5] .-= M1 ./ force_scaling
# equilibrium equations for the end of the beam element
irow = indices.irow_point[assembly.stop[ielem]]
@views resid[irow:irow+2] .+= F2 ./ force_scaling
@views resid[irow+3:irow+5] .+= M2 ./ force_scaling

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

@taylormcd taylormcd changed the title Add Joints Add Non-Rigid Joints Sep 8, 2022
@taylormcd
Copy link
Collaborator Author

taylormcd commented Sep 8, 2022

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
Copy link

ss1870 commented Sep 28, 2022

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:
    Δu = CtCab*(L*e1 + γ) - L*Cab*e1

    tmp2 = 1/2*CtCab*cross(L*e1 + γ, F)
  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:

    GXBeam.jl/src/element.jl

    Lines 1492 to 1494 in 6d9b8ad

    Δu = CtCab*(L*e1 + γ) - L*Cab*e1
    Δθ = Qinv*Cab*κ
  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
Copy link
Collaborator Author

  1. The dropped L term is introduced earlier:

    GXBeam.jl/src/element.jl

    Lines 68 to 70 in 6d9b8ad

    # scale compliance and mass matrices by the element length
    compliance *= L
    mass *= L
  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
Copy link

ss1870 commented Oct 3, 2022

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
Copy link
Collaborator Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants