Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unused ElementBase parameter in section stiffness methods #53

Open
JohnDN90 opened this issue Jan 2, 2020 · 2 comments
Open

Unused ElementBase parameter in section stiffness methods #53

JohnDN90 opened this issue Jan 2, 2020 · 2 comments

Comments

@JohnDN90
Copy link
Member

JohnDN90 commented Jan 2, 2020

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?

@manavbhatia
Copy link
Member

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.

@JohnDN90
Copy link
Member Author

JohnDN90 commented Feb 6, 2020

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants