You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm been implementing some tests in MAST using Catch2. I've noticed in the 1D and 2D section property cards that the section stiffness properties require a MAST::ElementBase reference as an input parameter, however they are never actually used anywhere in the calculations. From a testing standpoint, this would require the creation of a MAST::ElementBase object which, I believe, would also require the creation of MAST::SystemInitialization, MAST::AssemblyBase, and MAST::GeomElem objects as well in order to test a "section" card.
To get around this in the 2D element, I overloaded those methods (e.g. stiffness_A_matrix, stiffness_B_matrix, etc.) where the overloaded method does not require any input parameters. This removes the need to create those other MAST objects which aren't actually used and simplifies the test. Intuitively, I think this make a bit more sense as well since an element depends on a section, but a section shouldn't depend on an element.
Before, I do the same for 1D elements. I wanted to get thoughts on this. Is there a particular reason these sections are set up to require an MAST::ElementBase input parameter when its not used? Is there any obvious disadvantages to me creating these overloaded methods for testing purposes?
The text was updated successfully, but these errors were encountered:
You are correct, the MAST::ElementBase reference is not being used in any of the derived methods. I don't quite remember why I set it up this way. I may have had some idea of setting up a reference coordinate from the element that is the used to define the orientation for composite material layups.
How does Nastran define composite material property cards? Do you think an element reference may be needed there?
If it is not needed, then it is best to remove it for the reasons you outlined.
How does Nastran define composite material property cards? Do you think an element reference may be needed there?
I'm not sure how Nastran handles composite material property cards. I've never actually used them in any FEA program. Looking at the Nastran card for a composite section, it says "Orientation angle of the longitudinal direction of each ply with the material axis of the element." here it says that MAT1, MAT9, or MAT12 cards can be used with PCOMP, but I don't see a way to define the material coordinate system on those cards. So, I'm assuming that the material coordinate system is probably the same as the element coordinate system. Maybe @jdeaton can confirm this.
If it is not needed, then it is best to remove it for the reasons you outlined.
For now, I've just overloaded the functions so that it's possible to call it without an MAST::ElementBase reference. This simplified the setup of many unit tests. If it turns out that MAST::ElementBase reference is necessary for composite material support in MAST, I can always update the tests in the future to create an element to use with the property card tests.
These overloaded functions should be included in the catch2 unit tests branch which we are currently working towards merging in.
I'm been implementing some tests in MAST using Catch2. I've noticed in the 1D and 2D section property cards that the section stiffness properties require a MAST::ElementBase reference as an input parameter, however they are never actually used anywhere in the calculations. From a testing standpoint, this would require the creation of a MAST::ElementBase object which, I believe, would also require the creation of MAST::SystemInitialization, MAST::AssemblyBase, and MAST::GeomElem objects as well in order to test a "section" card.
To get around this in the 2D element, I overloaded those methods (e.g. stiffness_A_matrix, stiffness_B_matrix, etc.) where the overloaded method does not require any input parameters. This removes the need to create those other MAST objects which aren't actually used and simplifies the test. Intuitively, I think this make a bit more sense as well since an element depends on a section, but a section shouldn't depend on an element.
Before, I do the same for 1D elements. I wanted to get thoughts on this. Is there a particular reason these sections are set up to require an MAST::ElementBase input parameter when its not used? Is there any obvious disadvantages to me creating these overloaded methods for testing purposes?
The text was updated successfully, but these errors were encountered: