Feature/add beam library #84
Conversation
… no bending. Addresses enhancment discussed in GitHub Issue #40 This was done to increase intuitiveness of MAST and bring it more closely inline with commerical FEA programs. This was originally done on Oct 11 2019 in GitLab develop branch with commit b0647ec.
Added virtual set_material method to element_property_card_base.h Allows enhanced polymorphism between derived section classes by allowing 1D, 2D, and 3D section pointers to be stored in the same data structure (i.e. std::map), while still having access to the set_material method. Added init() and y_vector() methods to element_property_card_base to increase the polymorphism capability of 1D sections. Originially added on Sept 23 2019 in commits 635ba2c and a04a113 on GitLab in develop branch.
…nter, and stress evaluation points (and the derivative of these points) to 1D section. This was originally done over multiple commits on the GitLab MAST-Library repository on the develop branch.
This was originally done on GitLab MAST-Library repo in develop branch.
…perties. Added ROD cross section and corresponding supporting base classes.
Added missing MPI tests for ROD section.
TODO: Still need to add MPI tests and sensitivity test.
Added missing MPI tests for TUBE section Added missing sensitivity tests for TUBE section.
… and derivatives.
Fixed bug which resulted in errors when run with MPI. Fixed bug which resulted in 1 extra (unused) DOF was added to global system.
…n section initialization.
This bug seemed to only affect non-symmetric cross sections.
This reduces computational costs for warping systems. Refer to Robbie van Leeuwen paper.
…ethod. Created an Aluminum 7075-T6 and Titantium 6Al-4V materials for reuse in tests. Created an Aluminum 7075-T6 L cross section for reuse in L section tests. Created helper function to approximate field function derivatives via finite difference.
… refactored tests by J. Deaton merged in.
Removed some leftover libMesh::out statements from debugging.
…ard. Previously hardcoded values for a rectangular section were used.
JohnDN90
force-pushed
the
feature/add_beam_library
branch
from
8b2ffd8 to
9f9f9ed
Compare
This was done to maintain compatibility with PETSc versions older than 3.9.
… 1.4.1 and newer.
|
@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. |
| * Only used by 1D sections. Added for polymorphism enhancement. | ||
| * Added by DJN. | ||
| */ | ||
| virtual RealVectorX& y_vector() { |
There was a problem hiding this comment.
@JohnDN90 Why do we need these here? I agree with the adding the material above for sure. It seems like it would make more sense for the ones only used by 1D sections to be in the 1D section card class as pure virtual methods.
Is there somewhere else in the code (like in element creation I guess) where we use ElementPropertyCardBase and need these here?
There was a problem hiding this comment.
For elements, the property card is stored as a ElementPropertyCardBase here.
I believe I added it to be able to access it from something like that. I added a lot of that "polymorphism" enhancement stuff a while back when I first started and was getting back in the groove of writing C++. Most likely there is a better way to handle it that I'm not familiar with at the moment.
There was a problem hiding this comment.
Based on that I'm assuming that during the element construction process, those functions are called in a general way in the different "xxx_operator()" methods so they probably need to be there.
I'm thinking then in the 1st level child classes for each type, we need to implement the methods that aren't used with an assertion and the final specifier for completeness.
https://en.cppreference.com/w/cpp/language/final
I'll look into it and try some stuff out. I'm beefing up the documentation on some of the older base classes as I go through.
|
As I'm going through this I'm pretty sure that some of the section property classes (and accompanying files need renamed). For example, 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. |
|
I second comments by @jdeaton. One other comment I would add is concerning the My upcoming changes are looking to address such changes where new types of |
|
Once comments from @jdeaton have been addressed, then this can be merged. |
In other words, this moves the defintion of the PointLoad class definition from the examples into the library itself. This was implemented a long time ago but was never merged into master.
…dual degrees of freedom. This was implemented a long time ago, but is just now being moved to GitHub.
…nt RHS. Backwards compatibility of the adjoint_solve method is maintained.
…t_loads Feature/simplified point loads
…et-dof-bcs Feature/nonzero dirichlet dof bcs
Modified "adjoint_solve" method to allow user to explicitly set adjoi…
This branch adds support for various cross sections named and parameterized based on MSC Nastran's beam library.