Double Elements in StructuralMechanicsApplication

[AndreasWinterstein]

I have a question concerning the elements in the StructuralMechanicsApplication. There is the SmallDisplacementBeamElement3D2N and two membrane elements. The new CrBeamElement3D2N I recently committed in the feature-porting-element branch can be used for both (tests have to changed a bit and come soon), linear and nonlinear analysis since it has both types of stiffness matrices implemented. Is it necessary to have both beam elements then? Is the SmallDisplacementBeamElement3D2N working?

What about the membrane elements? What is the difference between them? Otherwise we should think about a proper naming in order to avoid confusion.

What do you think?

[loumalouomega]

The new membrane element is called PresstressedMembrane if I remember well (at least the name for use, not the used inside the element). Maybe is a good idea to use the same name for the class than for the final user registration name.

[longchentum]

The new membrane element is called PreStressMembrane now. However, the underlying theory is the same. Difference lay in different derivation and thus the implementation of the same theory.

Best,

[RiccardoRossi]

Hi, i agree with Andreas that only one element of the same type should be left. I add that i have no interest in preserving the old one, so as soon as the Prestressed membrane is tested and is deemed to be production quality i am willing to give up the old one.

regarding the beam, SmallDisplacementBeamElement3D2N is SMALL STRAIN, the new one is corotational, so i guess it can do large rotations/displacements. What happens if one attempts to use the CR beam with a linear solver? what if one does multiple Solves within a time step?

[KlausBSautter]

Hi, the new CrBeamElement3D2N has a bool in its constructor thus you can use CrLinearBeamElement3D2N with a linear solver for small strain analysis.

[RiccardoRossi]

H Klaus, But how are u going to specify one behaviour or the other in the mdpa?

aside of this please do not use elemental variables for the material properties. if you need the young_modulus do smthg like

const E = GetProperties()[YOUNG_MODULUS)

cheers Riccardo

[KlausBSautter]

you can either choose CrBeamElement3D2N or CrLinearBeamElement3D2N as an element in the .mdpa file. yes Im using the GetProperties function in my element.

[RiccardoRossi]

Hi again,

this is offtopic here, so most probably i should add a new issue, however the CRBeam has the following:

private:
    double mArea, mYoungsModulus, mLength, mDensity, mInertiaX, mInertiaY;
    double mInertiaZ, mCurrentLength, mPsiY, mPsiZ;
    double mEffAreaY, mEffAreaZ, mShearModulus, mPoisson, mtheta;
    double mdPhi_x_a, mRotInertiaY, mRotInertiaZ;
    Vector mNX, mNY, mNZ, mRHS, mTotalDef, mTotalPos;
    Vector mTotalNodalDeformation, mTotalNodalPosistion, mBodyForces;
    Vector mDeformationModes, mIncrementDeformation;
    Matrix mLHS, mRotationMatrix, mRotationMatrix0;
    Vector mNX0, mNY0, mNZ0;
    Vector mQuaternionVEC_A, mQuaternionVEC_B;
    double mQuaternionSCA_A, mQuaternionSCA_B;
    Vector mPhiS, mPhiA;
    Vector mNodalForces;

you should definitely not store so much information in the element.

just to make an example mArea, mYoungsModulus should be fetched from the properties and mLenght from the geometry

i am insisting on this since we need to minimize memory allocation.

similarly @longchentum, your membrane element is currently storing Geometry< Point<3, double> >::Pointer mpReferenceGeometry;

Vector mDetJ0;

double mTotalDomainInitialSize;
double mdensity;
double mThickness0; //thickness in the reference configuration
double mThickness;                                  // thickness in actual configuration

std::vector< array_1d<double, 3> > mStrainsVector;  //container of Strain
std::vector< array_1d<double, 6> > mStressesVector; //container of Stress
std::vector< array_1d<double, 6> > mCauchyStressesVector;   //container of Stress

std::vector< array_1d<double, 3> >  mV1;
std::vector< array_1d<double, 3> >  mV2;
std::vector< Matrix >              mG_Vector;

std::vector< array_1d<double, 3> > mGab0;
std::vector< array_1d<double, 3> > mG1;
std::vector< array_1d<double, 3> > mG2;

array_1d<double, 3> mPreStress;         // Pre-Stress which cannot be read through mpda file. this is a temporary solution

why it is definitely possible to avoid essentially all of such storage. Recompute it instead when you need it

[KlausBSautter]

Ok I see, I will try to improve this.

[AndreasWinterstein]

@RiccardoRossi I will check the element together with Klaus. I would suggest that we first add the tests in order to see that the element is still working after we do those modifications. Concerning the SmallDisplacementBeam3D2N we will have to test it. I suggest that we use the linear tests we are anyway writing for the linear version of the CrBeamElement3D2N. Or are there any tests for the SmallDisplacementBeam3D2N?

[RiccardoRossi]

Hi Andreas. +1 for your suggestion.

I also agree about taking out the old beam if the new one is tested and has the same capabilities (I am sure it is actually better)

El 16 jun. 2017 8:44 a. m., "AndreasWinterstein" notifications@github.com escribió:

@RiccardoRossi https://github.com/riccardorossi I will check the element together with Klaus. I would suggest that we first add the tests in order to see that the element is still working after we do those modifications. Concerning the SmallDisplacementBeam3D2N we will have to test it. I suggest that we use the linear tests we are anyway writing for the linear version of the CrBeamElement3D2N. Or are there any tests for the SmallDisplacementBeam3D2N?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/KratosMultiphysics/Kratos/issues/498#issuecomment-308947046, or mute the thread https://github.com/notifications/unsubscribe-auth/AHr7EdpT2G_03rUG8bNWQUDqafTNjE_Qks5sEiREgaJpZM4N58a4 .

[longchentum]

Hi Riccardo,

I got the point and I am working on the pre-stress membrane. I think it would be also good that we discuss about it when you come to Munich in one week.

Best, Long

[RiccardoRossi]

On the same thread, i think there is a similar issue with the corotational_truss element. Shouldn't we implement a TL one instead? The implementation is straight forward, and it is more general than CR...

[RiccardoRossi]

hi all,

did we reach some conclusion on this? What about the two membrane elements? which one should be kept?

[longchentum]

Hi,

Yes, we can keep prestress element.

[loumalouomega]

Hi, do we solved this issue?

[AndreasWinterstein]

I think this issue is open quite long. Since there is a pull request out for the tests in the new format for the beam (CR) and truss (TL) elements and there is also a linear version of the beam I think we can replace the SmallDisplacementBeam element by the CrBeamElement. I also tested beams and trusses for "real world" problems and they work perfectly. I do not know aboubt the current state of the membrane element. Conclusion: I would remove the SmallDisplacementBeam element, make a pull request, close this issue and open a new one when I know more about the membrane.

[philbucher]

following @AndreasWinterstein comment, closing this, see #877