Comments (3)
I'll jump in and say that I agree that the package is almost ready for a v1.0 release. I have been using the 1D Member elements in production code for a while now and it has performed flawlessly, though I'll admit it is a little tricky to maintain due to the regular breaking changes. I would like to incorporate the 2D elements (Quads) into production code as well, though it seems they're not quite ready yet.
I think this is a good time to open the discussion around what the API workflow looks like in a v1.0 release. I've addded a few of my own thoughts below:
- I think the use of sections for Member elements should be enforced. At the moment, the user can initiate a Member element with either a section name or by manually passing A, Iy, Iz & J parameters to the constructor. We're not saving much by passing those parameters directly to the member, and storing all section parameters in a specific section class feels much cleaner. Additionally, the section parameters should only be extracted from the section object at analysis time, not copied over to the Member object at member construction. This allows for section properties to be altered between iterative analysis runs without manually having to update the member section parameters before each run.
- As above, but for material properties. Material parameters should be kept stored in the material object until analysis time for the reasons outlined above.
- Does a quad section property class make sense? It would really only need to store the thickness of the quad, but would allow that thickness to be easily changed between analysis runs. I dont feel as strongly about this as for Members.
- Plate elements to be removed. They dont seem to be all that usefull when the Quad element is much more flexible. I undertand the implementation is simpler and there is likely a performance benefit to that, but they really just clutter up the codebase.
- There is a disconnect in the way the user interacts with the model before and after analysis. To set up a model, we only interact with the model via the methods of FEModel3D, but then to extract the results we need to interact directly with the Node/Member/Quad objects, which can only be accessed by accessing the FEModel3D instances lookup dictionaries. I dont necessarily know what the right approach here is, but the current one feels a little odd.
- The Material class is poorly documented. It is also unclear why we need to provide both a shear modulus and a poisson's ratio. Can one not be calculated from the other?
- It is difficult to extract quad internal forces (shears/moments) at a given node without interrogating the topology of the quad. In my opinion, the user should not need to interact with the (r, s) natural coordinate system of the quad
I understand much of the above would constitute breaking changes, but I want to make sure they're considered before pushing ahead with a v1.0 release.
from pynite.
I am also quite interested in solidifying the API since I think this library is working great and I think has a good balance of scope and ease of use. I think it might be a good idea to share our wishlists in this threads so we can decide where potential breaks in the interface might occur and design an interface that wont break when these changes are added if not at the 1.0 release.
I have a couple of changes I would like to make and think some of them are significant changes so It would be nice to get those in before 1.0 vs after to prevent breaking changes.
-
I've taken a stab at integrating a common materials definitions between
sectionproperties
andPyNite
, and in general I think maybe this could be a separate library since we essentially double our user-base for support in this area. It would also be cool to have some kind of scrape of matweb to populate a materials database which is outside the scope ofPyNite
.
https://github.com/Ottermatics/ottermaticslib/blob/master/ottermatics/eng/solid_materials.py -
I have an integration between defined 2D member profiles as per PyNite and shapely-defined sections that rely on
sectionproperties
. This is done with an emphasis on unifying the resultant stress calculation including a prediction of failure for the more computationally intense FEA approach ofsectionproperties
using a Support Vector Machine interface. This works by calculating the true stress via FEA and adding it to a database when the number of points is below a threshold or when the estimated stress is within the (margin of error x safety factor) to failure. An interesting use of this feature is the ability to quickly determine the structure failure loads via iterative solver vs applying loads and then calculating stresses. This might be useful as a 3rd party library if it doesn't fit in here.
https://github.com/Ottermatics/ottermaticslib/blob/7b73db99a784d2da21e1cc599c3ea4b09c5b4d6a/ottermatics/eng/geometry.py -
Using a "KDTree" for node definitions, which replaces identifying duplicate nodes, with the added benefit of searching a region for existing nodes.
-
Saving / Loading Case Results to disk, I've outlined this in #178 but have only progressed a little bit on this
-
I've added a GPU Solver capability enabled via environmental variable since that would likely be an advanced use case.
-
I've improved meshing for cylinders and annular meshes to align the starting node angle
Changes I'd want to integrate are here:
main...Ottermatics:PyNite:structural_integration
Another interesting Idea would be to create a github-organization to integrate engineering oriented libraries that many brilliant people have put together. A library I am using capytaine
receives support funding from the National Science Foundation and NREL, which has accelerated their growth. No reason the same could happen here!
from pynite.
Thanks for the input. Here are my thoughts:
@bjhowie (not completely in the same order as you have):
- Introduce a
Section
class so that aMember
definition is populated with connectivity information,Section
class, andMaterial
class. Basically five parameters (name, start node, end node, section, material). I think that makes sense. I think that might be on @JWock82's road map, too. QuadSection
class for quad sections. From what you are saying, I think that makes sense (even though it seems to be just for name and thickness). It would be consistent with frames and allows for the same behaviour of modifying a section object and have it apply across the model.- I don't know if plate elements should be removed. They seem like they might have their place in membrane-type structures (which I believe are included in the design examples). @JWock82, thoughts?
- Poisson's ratio and shear modulus: Agreed, I always found it odd because it is like duplicated information. Defining one or the other should be sufficient.
- Force extraction from quads: I think @JWock82 is addressing this in the new
DKMQ
branch. - Model interaction before and after analysis: I very much agree with this. It is an awkward but sensible approach. Perhaps the implementation could be wrapped in a method?
model.get_member_results("M1", "shear", "Fy", "Combo 1", n_points=200)
(for the raw arrays) ormodel.get_member_diagram("M1", "deflection", "dy", "Combo 1")
(for the matplotlib figure). As long as the implementation stays the same (i.e. people can still access dicts directly) and these methods are simply added to theFEModel3D
then this does not need to be breaking change but would be a nice quality of life improvement.
- Harmonzing with
sectionproperties
would be fun but I think is outside the scope of PyNite. PyNiteSection
objects would basically take results from asectionproperties
analysis. Perhaps there could eventually be a method on theSection
class that could accept asectionproperties.Section
object and use it to populate a PyNiteSection
object? Would not be a breaking API change, just a new feature. - Sounds cool! As you suggest though, I think it is a 3rd party library extra since there is so much extra scope there.
- A
KDTree
would certainly add a lot of "intelligence" to the nodes. Do you think theNode
andFEModel3D
API could remain as is and this could simply be an implementation detail under-the-hood? It would create the possibility for new method names to do wonderous new things (non breaking changes) but are there any elements of the existing API that would have to change to accommodate theKDTree
? - Saving models and results to disk would be a great feature (have been thinking of it myself). It seems we could eventually do that by just creating new method names to handle these capabilities (non-breaking change). Do you see any elements of the existing API that would have to change to accommodate this?
- GPU solver with an added environment variable. If the variable is simply an added option, this sounds like a non-breaking change.
- I just did a quick read of changes in your branch. I did not see any breaking API changes (just new optional keyword parameters). The one possible breaking change I did see is adding a
__hash__
method to theNode
object. I don't believe theNode
object is immutable so adding a__hash__
method would be an "incorrect" application of the__hash__
method. Making theNode
object immutable certainly would be a breaking change. I don't think this is necessary since we can use the node name as a dict key instead of the actualNode
.
In summary, @bjhowie is proposing a series of API changes too be considered. I think they make sense but I take direction from @JWock82 :) @SoundsSerious has some very cool features suggested and I think they can all be implemented without API breaking changes (except the __hash__
thing).
@JWock82, would love to hear your thoughts whenever you have the capacity :)
Thanks all!
from pynite.
Related Issues (20)
- Rotational Symmetry HOT 3
- Incorrect (Zero) Reaction Observed in Z-Direction for Cantilevered Beam with Spring Supports HOT 4
- 'Quad3D' object has no attribute 'LoadCombos' HOT 2
- RuntimeWarning: divide by zero encountered in double_scalars HOT 2
- Displacement Memory Growth & Purge Option + Disk Caching of Displacements HOT 3
- P-Delta Member Internal Results Incorrect HOT 1
- PyNite Import Issue HOT 3
- Tension-only members HOT 3
- Issue initalising PhysMember HOT 3
- Variable cross-section along member HOT 1
- Issue initalising PhysMember second issue with variable position HOT 1
- Spring Supports: reactions = 2x input forces HOT 2
- Help with unit HOT 2
- Speed Improvement HOT 1
- Visualize Local Coordinate Systems on Members in Finite Element Model Visualization HOT 3
- Quad results in global coordinate system HOT 8
- Possible Skewed Quad Error HOT 4
- Type Hints
- Release on conda-forge
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from pynite.