application of known displacements to nodes

[dmorchard]

Is your feature request related to a problem? Please describe. In addition to nodal and member loading I'd like to be able to apply a known nodal displacement to a structure, to examine the internal loading that arises from foundation settlement for example.

Describe the solution you'd like At the moment I don't believe there's a way to do this - no purposely written sub/function that I've seen anyways. Is that correct? If so it's something I will work towards including, although I have a feeling it'll require much more familiarity with the existing code than I currently have, not to mention a better grasp of OOP.

[JWock82]

I've looked into this before, and if I recall correctly it's a matter of changing the way the matrix equations are written and solved. Instead of an unknown displacement to solve for we get an unknown force to solve for. I don't think it's terribly difficult to do, but it would require some time researching how to do it and modifying the program's core solver.

[dmorchard]

Agreed. I'm looking into it, but first I need a better understanding of what's going on under the hood. It's happening organically, in bits and pieces as experiment; however, I might get there more quickly if I was looking at the same references you based your code on. I see a lot of your test routines are based on a pair of textbooks: Finite Element Method and Structural Analysis; could you tell me more about those? Author(s)? Editions?

My own non-OOP VBA plane frame analysis code is based largely on Kassimali's Matrix Analysis of Structures (1st & 2nd editions) and Hibbeler's Structural Analysis (6th & 8th editions).

[JWock82]

I used Structural Analysis, 3rd Edition by Aslam Kassimali and A First Course in the Finite Element Method, 4th Edition by Daryl L. Logan.

[dmorchard]

Great, thanks! I'm gonna try to track those down for my own personal library.

[dmorchard]

Hey @JWock82, while experimenting with spring support (issue #8) I built this non-VBA spreadsheet solution, and having this issue also floating around in my brain I purposely built this worksheet to accept non-zero support displacements.
GUC 4.3.xlsx

When you have a minute fire it up and scroll down to range R36:R39 (a.k.a. "Dk", displacements/rotations which are known by virtue of their association to a support condition). Enter a non-zero value in any of those cells and [Du] & [Qu] (below [K]) will update. The key formula is [Du] = [K_11]^-1 ([Qk] - [K_12][Dk]), which is an alternative form of Hibbeler's equation 14-21 (see below) where [Dk] <> 0.

Now bear with me because I'm still struggling to form an overall mental flow diagram of xlFrame, but I think the key code we'd need to alter is in FEModel's Analyze sub, where it appears to be forcing [Dk] = 0 after performing [Du] = [K_11]^-1 * [Qk] (Hibbeler's initial Eq. 14-21), with [Qk] = (known nodal forces - FERs from member forces) ... https://github.com/JWock82/xlFrame/blob/90c7a97de0ea69ee84d98ba90679b708c91356a5/Class%20Modules/FEModel.cls#L340-L369

[JWock82]

In order to prevent the stiffness matrix [K] from being singular (no inverse) all terms having to do with support degrees of freedom get eliminated from the stiffness matrix by xlFrame. They also get eliminated from the the nodal force matrix [P] and the fixed end reaction matrix [FER], where [Q] = [P] - [FER]. In other words, they get partitioned out of the equations as the author above is showing. What xlFrame then has is Equation 14-19, substituting in [Dk] = 0, which is [Qk] = [K11][Du]. After xlFrame solves for [Du] on line 342 above, the remaining part of the displacement matrix [Dk] is taken as a zero vector, which your seeing on lines 352, 359, and 366.

In order to add support displacements the parts I've partitioned out will need to be dealt with. Partitioning these matrices will be a little tricky, since they are not ordered like your textbook suggests with the lowest code numbers representing supported degrees of freedom. The k_Condense() function in the StaticCondensation.bas module has a good algorithm for partitioning matrices in lines 29-88 that could be adapted to suit our needs. I already had to partition the matrices once to add end-releases to the members. You'd have to change the if statements to partition based on whether or not a support is present.

Once it's all solved we'll need to put it all back together in a way that users can ask for results from any given node based on its name. This may take some book-keeping, since partitioning these matrices into sub-matrices could cause some renumbering of degrees of freedom as terms take new positions in sub-matrices.

This will be a big task, so I definitely recommend starting a separate branch for this. I also recommend breaking it down into multiple subroutines and functions that are easy to isolate, test and debug on their own. I don't think it's a one weekend project if you know what I mean.

[dmorchard]

I'll keep all this in mind as I continue to chip away at various sub tasks.

Thanks for getting into the weeds with me here! I imagine I'm turning into more of a time sink than you'd hoped for in a collaborator :)

[JWock82]

No problem. I'm glad to have your help.

[JWock82]

I successfully added this feature to PyNite. For anyone interested in adding this feature to xlFrame, the algorithm is there in PyNite, and just needs to be converted to VBA.