Open JohnDN90 opened 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.
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:
ElementPropertyCardBase
-ElementPropertyCard1D
-Solid1DSectionElementPropertyCard
ElementPropertyCardBase
-ElementPropertyCard1D
-Multilayer1DSectionElementPropertyCard
ElementPropertyCardBase
-ElementPropertyCard1D
-xxx1DxxSectionElementPropertyCard
andElementPropertyCardBase
-ElementPropertyCard2D
-Solid2DSectionElementPropertyCard
ElementPropertyCardBase
-ElementPropertyCard2D
-Multilayer2DSectionElementPropertyCard
What if we refactored everything to more consistent naming like:
ElementPropertyCardBase
-ElementPropertyCard1D
-ElementPropertyCard1DSolidSection
ElementPropertyCardBase
-ElementPropertyCard1D
-ElementPropertyCard1DMultilayerSection
ElementPropertyCardBase
-ElementPropertyCard1D
-ElementPropertyCard1DxxxSection
ElementPropertyCardBase
-ElementPropertyCard2D
-ElementPropertyCard2DSolidSection
ElementPropertyCardBase
-ElementPropertyCard2D
-ElementPropertyCard2DMultilayerSection
ElementPropertyCardBase
-ElementPropertyCard2D
-ElementPropertyCard2DxxxSection
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.
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.
Once comments from @jdeaton have been addressed, then this can be merged.
This branch adds support for various cross sections named and parameterized based on MSC Nastran's beam library.