[Discussion]: Column buckling calculations in continuum mechanics module

[ishanaj]

As we plan to implement column buckling calculations in the continuum mechanics module, here is what I have thought of regarding the API and its implementations:
The API can be seen from the stage -II of the proposal here
I think we need some discussions regarding how the API looks and how it would work.

Since the beam calculations are different from those of Column, we would require a different class which probably would be a subclass of Beam.
Some initial questions:

• Is there any good source from where some additional research could be done?
• I have found only 4 end-conditions: pinned-pinned, pinned-fixed, fixed-fixed, pinned-free.
  Are there any other end-conditions?
• Although we won't be implementing indeterminate columns, I would still need to study about
  it, to make the code extensible to it in future.

@jashan498 @moorepants @oscarbenjamin

[moorepants]

You should consider whether the class needs to be mutable or not. If you can make a non-mutable class which takes everything it needs in the constructor, I'd recommend that. This is different than the Beam class. I also don't immediately see the value of have Beam and Column be derived from the same class. The only thing they share are a cross section and material properties.

[ishanaj]

I worked on making a non-mutable column class. These are the things that we would need in the constructor for further calculations.

def __init__(self, height, elastic_modulus, second_moment, load, eccentricity=None, top="pinned", bottom="pinned"):

Things that have not been included in the constructor:

• Boundary conditions: We might need some other boundary conditions in calculating reaction moments and reaction forces, apart from those that correspond to the end-conditions. Not sure how to add them as a parameter in the constructor.

• Variable: We can directly use a variable x for distance from bottom and y for deflection at any arbitrary section, (as in this figure), when we are returning moment at any section at a distance x in terms of y. Or do we want these to be specified by the user as Beam does?
  

• base_char: Which specifies the variable to be used in if any constant remains unsolved

Do we want these three to be taken as an input?
I guess we can skip variable and base_char and use conventional symbols instead.

[jashan498]

I guess we can skip variable and base_char and use conventional symbols instead

Yeah, you can skip these but don't forget to mention the conventions used in the docstring of the class.
For Boundary conditions, you can use something similar to what is used in beam.

Not sure but won't it be better if we make load and second_moment mutable? I understand with other attributes which describe the physical property of the column being fixed but maybe we should allow the user to apply and remove load and second_moment, or they will end up making a new object for every slight variation.

[oscarbenjamin]

or they will end up making a new object

What's wrong with making a new object?

If I was designing the Beam class from scratch I wouldn't bother with any of the setters and getters. I would add all properties in the __init__ method as normal attributes without underscore names. Then I would document how users should use the class treating it as immutable but without expending any effort in the code to enforce immutability. Rewriting the Beam class like that now would remove a lot of methods and could maybe end up with maybe half as many lines of code.

Another point about code design is that the Beam class has some methods that probably shouldn't be there. For example max_shear_force has a load of code for finding the maximum shear force. Really it should return the shear force and there should be a general SymPy function for finding the maximum of that expression. The effort that goes into writing a function like that should have gone into improving the general purpose maximum function (if needed) so that a user can do:

max_shear_force = maximum(abs(b.shear_force()), x)

There are also cases like max_bmoment which duplicates the code in max_shear_force so that the code that shouldn't be there at all in fact appears twice.

All of this happens because more and more contributors arrive wanting to add new methods without considering the overall design. It's not possible to remove those methods from Beam now (although the code can certainly be simplified).

It's important to design a clear API so that people aren't tempted to keep adding unnecessary things to it. Avoiding mutability is a big simplification that I would make from the start.

[ishanaj]

Is there any specific reason why we are intending to make column class non-mutable? I think it would be good if I mention it somewhere in the blogs or in any wiki page.

[jashan498]

If I'm not wrong it is basically to reduce the number of lines of code spent in setters and other methods to modify the properties of the object and thus making the class simpler.

[oscarbenjamin]

@ishanaj it is really up to you to think what is best here. Do you see any benefit in making it mutable/immutable?

I suggested making it immutable because that's (usually) simpler. Most things are immutable in SymPy which is useful for caching etc. Matrix is an example where allowing mutability has lead to many problems that are now impossible to fix without breaking backwards compatibility. Your class is relatively isolated though so those concerns probably don't apply.

Another point is that you need to think about consistency with Beam. Unfortunately users will compare these two so you should consider whether they will have any particular reason for wanting this class to be mutable.

Another important point: from a backwards compatibility perspective it is always possible to change your mind and add mutability later but not the other way around.