MASTmultiphysics / mast-multiphysics

Multidisciplinary-design Adaptation and Sensitivity Toolkit (MAST) - Sensitivity-enabled multiphysics FEA for design
https://www.mast-multiphysics.com
GNU Lesser General Public License v2.1
43 stars 24 forks source link

Feature/add beam library #84

Open JohnDN90 opened 4 years ago

JohnDN90 commented 4 years ago

This branch adds support for various cross sections named and parameterized based on MSC Nastran's beam library.

JohnDN90 commented 4 years ago

@manavbhatia and @jdeaton I think this initial beam library is ready to be moved into master. If you two could look it over, I'd appreciate it.

jdeaton commented 4 years ago

As I'm going through this I'm pretty sure that some of the section property classes (and accompanying files need renamed). For example, Solid1DTubeSectionElementPropertyCard doesn't make sense because a hollow tube is not a solid section...should probably be just 1DTubeSectionElementPropertyCard.

I think we could also consider a larger refactoring here for clarity. The more specific classes don't follow the same naming convention as the base classes they inherit from. For example:

What if we refactored everything to more consistent naming like:

This would benefit a number of things with sorting. Related files would be grouped together, classes in IDE's would group, and I believe the API documentation would sort related element property classes closer together.

@manavbhatia do you have any thoughts on this bigger refactoring? We will definitely fix the oddly named 1D sections for the beam library.

manavbhatia commented 4 years ago

I second comments by @jdeaton. One other comment I would add is concerning the if/then/else blocks in the internal_residual and related methods to manage the workflow with or without warping analysis. As I understand, you are also looking to add similar blocks to switch for springs/bush elements in upcoming PRs.

My upcoming changes are looking to address such changes where new types of internal_residual evaluation routines can be added by a user to implement new types of elements without needed to add blocks like these. Once this gets merged, this would provide a new (hopefully, improved) mechanism to address such situations. I don't think it would affect this current implementation, but I am just giving you a heads up.

manavbhatia commented 4 years ago

Once comments from @jdeaton have been addressed, then this can be merged.