Suggestion Box / Priorities for Future Development

[JWock82]

I'm looking for input from the community. What features would you like to see prioritized in PyNite?

Please add only one feature per response so that individual features can be upvoted. Before answering, see if someone else has already suggested that feature and upvote it if you want. I've started a few suggestions.

[JWock82]

Triangular plate elements. I usually try to avoid these, but they can be useful for some complex mesh geometries.

[janetunde]

(And also opening shapes) Thank you!

[JWock82]

I do plan to eventually provide more examples and documentation on how to use meshes and plates. There are a few minimal examples. Right now only a few basic meshes are supported: Rectangles (with rectangular openings), cylinders, discs, donuts, cones/frustrums. They can be combined with each other (carefully) to form more complex meshes. I need to add more examples of how to do it.

[SoundsSerious]

This would be great! I would love the ability to connect the annulus mesh to a central point for a beam.

I have a problem where I need to model a central driveshaft to an annulus mesh, currently I have to use a cylinder mesh which increases dimensionality alot.

Triangles would also be great since they would allow you to use GMSH or similar out of the box

This looks to be a good implementation for a MITC type element
https://www.sesamx.io/blog/triangular_shell_finite_element_formulation/

[JWock82]

Have you tried using the frustrum mesh with a radius of zero at the tip? I can't remember if I programmed it to handle that case or not. I've done it for other programs I've written for work. I just can't remember if I did that for Pynite.

[SoundsSerious]

@JWock82 No I haven't I'll give that a shot. Does that still use MITC4 elements?

I did try the annulus mesh with a near zero inner radius, and then combining the nodes. I wasn't sure if that would have valid results since i'm not sure its a valid use case of MITC4.

In light of combining duplicate elements I have added a few features that you might be interested in my fork (planning on getting a PR together sometime). Here's the highlights main...Ottermatics:PyNite:structural_integration:

1. GPU Solver integration! Still lots of work to do to make this fool proof but figured It would be a nice to have. I've setup a PyNite.solvers module that gracefully fails if GPU's arent enabled, and this functionality works when the environmental variable PYNITE_GPU=True
2. Using a KDTree to identify duplicate nodes efficiently, and to search nodes by position which i think is an interesting feature. These are really cool data structures that can have lots of uses. One idea i had was to allow the merging of different structures via KDTree + Offsets as there is a a builtin method for that in the scipy toolbox. https://www.youtube.com/watch?v=BK5x7IUTIyU
3. Cylindrical / Annulus meshes alighn to the startnode with an angle offset which is a nice quality of life thing.
4. I added the ability to run load_combos parallel to the combo_tags feature, since I had already defined my runs per load_combos. I'm not sure if this conflicts with the vision you had but happy to drop that before my PR.

[JWock82]

Ability to read/write to Excel spreadsheets.

[roger1017]

It does not need to be Excel spreadsheet. A json input/output file would also be nice.

[JWock82]

Better meshing algorithms. Meshing for domes, elipsoids, circular plates, polygons, etc.

[JWock82]

AISC steel design capabilities, including integration with the AISC shapes database.

[SoundsSerious]

Checkout sectionproperties since you can simply input in a polygon and it gives you the material properties quickly, as well as the 2.5d stress concentration for given loads relatively quickly (350ms per fea case)

[JWock82]

[JWock82]

This feature is now complete

[JWock82]

Change the default quad to a DKMQ quad instead of an MITC4 quad. I believe the DKMQ gives better corner stress results. The MITC4 gives accurate corner forces, but when it comes to stresses it tends to report center stresses for corner stresses.

[JWock82]

Better documentation

[JWock82]

More examples and starter models

[drewh615]

Rigid diaphragm capabilities

[drewh615]

Add option to rotate local axis by angle as alternative to auxiliary point.

[drewh615]

Option to include shear deformations in analysis.

[roger1017]

Simple linear dynamic solver

[roger1017]

Stress results for 3d beam element

[SoundsSerious]

@roger1017 I've integrated PyNite with sectionproperties to get this result here. To evaluate a whole structure with sectinoproperties FEA takes a relatively short time, however I'm implementing an SVM failure prediction system for the beams to speed up this even further so you only need to run FEA when youre close to failure calculation.https://github.com/Ottermatics/ottermaticslib/blob/neptunya/ottermatics/eng/structure_beams.py

[roger1017]

Option to include self weight automatically in load combinations

[SoundsSerious]

Checkout https://github.com/Ottermatics/ottermaticslib/blob/neptunya/ottermatics/eng/structure.py I have some methods for doing this out of the box

[doug-sw]

Calculate available strengths per AISC 360-16 D-H, compare to required strengths, and report results.

[mehdibeban]

Better system visualization of the static system and an option to save the diagrams

[Abdulkariim]

Hello and thanks to the pynite development team for the great work done.

I would like non-uniformly distributed loads to be added to pynite

[doug-sw]

The add_member_dist_load function allows for monotonically increasing/decreasing distributed loads.

    def add_member_dist_load(self, Member, Direction, w1, w2, x1=None, x2=None, case='Case 1'):
        '''
        Adds a member distributed load to the model.
        
        Parameters
        ----------
        Member : string
            The name of the member the load is being appied to
        Direction : {'Fx', 'Fy', 'Fz'}
            The direction in which the load is to be applied. Note that
            typical beam sign convention is used. Forces acting toward the beam
            are positive.
        w1 : number
            The starting value (magnitude) of the load.
        w2 : number
            The ending value (magnitude) of the load.
        x1 : number
            The load's start location along the member's local x-axis. If this argument
            is not specified, the start of the member will be used.
        x2 : number
            The load's end location along the member's local x-axis. If this argument
            is not specified, the end of the member will be used.
        '''

reference

[Abdulkariim]

Now for example this type of loading, how can I embed it in pynite

[connorferster]

Approximate the loading as piece wise linear with numpy? That would be my approach.

[Abdulkariim]

I would also suggest that curved members be added to Pynite.
For example:

[reubenr-holmes]

I'd like the ability to add nonlinear springs, or forces that are some function of displacement. I'm not sure how easy this would be to do.
(And thanks for PyNite, @JWock82!)

[JWock82]

Eventually this would be a nice feature to add, and I don't think it'd be too difficult to do so. The program already iterates to do tension/compression only springs.

As it is right now, I think you could force PyNite to do it by adjusting spring stiffnesses after analysis and then rerun the analysis. Then repeat that process until equilibrium is reached. Maybe that's not quite right though, as there are some initial strains in the members you'd need to account for in the subsequent iterations. I would like to add prestressing forces to PyNite. That would help bridge that gap.

[roger1017]

I'm looking for input from the community. What features would you like to see prioritized in PyNite?

Please add only one feature per response so that individual features can be upvoted. Before answering, see if someone else has already suggested that feature and upvote it if you want. I've started a few suggestions.

Hi Craig,

Many thanks for the efforts to further developing PyNite. I can see this discussion has been here for a little over than 1 year. Based on the discussions here, could you maybe update us what will be your priorities for the PyNite in the coming months?

BR
Roger

[JWock82]

Certainly.

I'm still planning on improving PyNite, but the pace this last year was slower. That's largely because implementing plates took so much effort the prior year that I needed a break. I do this in my free time. If I could find someone to click that "Sponsor" button a few times development would move much faster, but alas...

What may be hard to notice is that under the hood I've still been squishing bugs, simplifying, and reorganizing code, improving solution speed, adding unit tests, and polishing subtle behaviors that were quirky. The biggest recent change has been the addition of physical members just a few months ago.

As far as a future roadmap goes, below is what I'm thinking in order of priority. Don't make any major business decisions on this information because I change my mind frequently.

• Material definitions: It's low-hanging (easy to implement) fruit, and it would be a first step toward a self-weight feature, non-linear materials, and toward a mass matrix for modal analysis. It just makes sense to add this.
• Section definitions: Another easy one that would put PyNite one step closer to concrete and steel design, and the stress results people keep requesting. As a side note, I don't fully see the utility of stress results myself, as very few material design codes are written in terms of stresses. They are usually written in terms of force effects, which PyNite already handles well.
• Excel: I started tinkering with a graphic user interface (GUI) using wxPython just to see what it would take. I got a few things working pretty well, but to make it really useful would be too big project for the time I have available. I would welcome help on a GUI, but in the meantime, I think publishing an Excel spreadsheet that integrates with PyNite via xlwings would be a simpler project with a lot of utility, so I've started work on that.
• Beam rotation angle instead of auxiliary nodes: It's really time to ditch auxiliary nodes in exchange for beam rotations. This would be another simple fix.
• Further code simplification and organization: I see this as a key to attracting maintainers. More maintainers = more features faster.
• Better visualization: I'd like to improve the graphics experience as well by offering member internal force diagrams plotted on members, visibility for springs, maybe a few buttons to change the view on the fly, and better color schemes for integrating with Jupyter Lab.
• Plate improvements: I'd like to streamline meshing. That likely means adding triangle elements and fancy meshing algorithms. A very big project that would likely take a year or two to get right in my spare time.
• Transverse shear deformations: I think this would be pretty easy to knock out in a weekend or two. I just don't deal with a lot of problems that need that level of accuracy, so I haven't taken it up yet.
• Rigid diaphragms - I started tinkering with this in one of my models. It's a little trickier than I thought. A simple "rigid link" between nodes solution creates unintentional out-of-plane restraint that alters behavior significantly. I may come back to this.
• Modal analysis - This interests me greatly just as an opportunity to learn it better for myself. That said, it's a big project and I'd like to knock out the easier ones first.

All this will take some time. My hope is as the user base expands, a few sponsors will trickle in and I'll have time to develop features like this more rapidly. I would love to develop this program for the community for a living, but I don't see that in the cards in the near future. I do think more users will lead to a larger pool of maintainers and contributors. The traffic on the repository is much more than I ever thought it would receive, and it's still getting "starred" pretty regularly - It recently broke 200 stars which was an exciting milestone. The user base is definitely growing rather than receding.

I hope this helps you see where the project is headed.

[JWock82]

Just an update on this. I'm nearly done coding material definitions into PyNite. I ran into a slight snag with meshes, but should have that sorted out soon. Brace for this as it will affect every PyNite user. Members and plates will soon require a material definition rather than inputting properties directly. I think it's necessary. This will be a small step toward both self-weight and non-linear materials.

[connorferster]

Whoa! Exciting!

In sectionproperties, we defined a default material as a constant with all properties set to 1 to allow for a fast analysis option for calculating the geometric properties. If the user did not supply a material, the default material was used.

I am wondering if it could be worthwhile to do something similar here. The idea being that if a user is looking to solve shear and moment diagrams, they can access a fast solution.

Thoughts?

[JWock82]

I can see the utility of that. PyNite already has a default load case and load combination for users who don't really use those much (mechanical engineers for example). Since PyNite is unitless, an assumption will have to be made about the units system the user wants. Nothing against the rest of the world, but if I do it, it's going to be 'merican units.

[connorferster]

Lol, I hear you: it's your tool so shape it how you wish!

When I have been doing 2D beam analysis with PyNite, I have been using values of 1 for material properties that do not affect my analysis, e.g. J, Iy, G. What are your thoughts on just setting all values to 1 in a default material? This way, no assumptions need be made about units.

EDIT: Setting all values to 1 except G=0.5

[Abdulkariim]

Hello, Members. I would like to give some examples on how to use the PhysMember class

[PetrKryslUCSD]

Beam rotation angle instead of auxiliary nodes: It's really time to ditch auxiliary nodes in exchange for > beam rotations. This would be another simple fix.

I was just wrestling with this concept in the STAAD manual. It got so complicated and tangled in special cases that I at this point much prefer the concept of a direction vector + rotation about the axis.
https://github.com/PetrKryslUCSD/pystran/blob/09ba8f2ffb570eeeb5f48d0b06378c606519b334/examples/weaver_1.py#L56