CFD Online Discussion Forums - [Other] solids4foam developping new nonLinearGeometry mechanicalLaws looks for volScalarField

CFD Online Discussion Forums (https://www.cfd-online.com/Forums/)

- OpenFOAM Community Contributions (https://www.cfd-online.com/Forums/openfoam-community-contributions/)

- - [Other] solids4foam developping new nonLinearGeometry mechanicalLaws looks for volScalarField (https://www.cfd-online.com/Forums/openfoam-community-contributions/243783-solids4foam-developping-new-nonlineargeometry-mechanicallaws-looks-volscalarfield.html)

solids4foam developping new nonLinearGeometry mechanicalLaws looks for volScalarField

Hi,

I am trying to develop new nonLinearGeomtry Mechanical law based on the class

mechanicalModel/mechanicalLaws/linearGeometryLaws/linearElasticFromFile

I am doing this by modifying neoHookeanElastic model so that the mechanicalProperties looks for files "mu" and "K" as volScalarField

@bigphil did a similar linearGeometryLaws linearElasticFromFile.

@Daniel_Khazaei did a mechanicalLaw with time-varying E timeVaryingNeoHookeanElastic.

code in neoHookeanElasticFromFile.C :

Quote:

mechanicalLaw(name, mesh, dict, nonLinGeom),
rho_(dict.lookup("rho")),
mu_
(
IOobject
(
"mu",
mesh.time().timeName(),
mesh,
IOobject::MUST_READ,
IOobject::AUTO_WRITE
),
mesh
),
K_
(
IOobject
(
"K",
mesh.time().timeName(),
mesh,
IOobject::MUST_READ,
IOobject::AUTO_WRITE
),
mesh
),

Any help is highly appreciated

Hi Smail,

You seem to be on the right track.

To make a neoHookeanElasticFromFile, I would take the following steps:

Make a copy of the neoHookeanElastic directory and rename it neoHookeanElasticFromFile
Rename the C and H files
Find and replace neoHookeanElastic in the C and H files with neoHookeanFromFile
Add the new C file to Make/options and check it compiles with "wmake libso"
Next, make changes to the C and H files as required (see next steps)
Change mu_ to a volScalarField in the H file and update the mu_ constructor in the C file (as you have done above); check everywhere mu_ is used in that class, as some code may need to be updated. To begin with you could even comment out any failing code until it compiles
Do the same thing for K_
Then make sure all functionaltiy compiles. I suggest making small changes and then checking the code compiles each time.
If you get a compilation error you don't understand then post it (the entire thing) here

Philip

As Phil was already replying, I guess there is no need to give any further information. Please note: I am not very active on researchgate and hence, saw your message luckily inside my inbox :)

Good luck and keep foaming.
Thanks for your support Phil - its good to have you around here on cfd-online.com (as well as all other volunteers).

Quote:

Originally Posted by bigphil (Post 832941)

Hi Smail,

You seem to be on the right track.

To make a neoHookeanElasticFromFile, I would take the following steps:

Make a copy of the neoHookeanElastic directory and rename it neoHookeanElasticFromFile
Rename the C and H files
Find and replace neoHookeanElastic in the C and H files with neoHookeanFromFile
Add the new C file to Make/options and check it compiles with "wmake libso"
Next, make changes to the C and H files as required (see next steps)
Change mu_ to a volScalarField in the H file and update the mu_ constructor in the C file (as you have done above); check everywhere mu_ is used in that class, as some code may need to be updated. To begin with you could even comment out any failing code until it compiles
Do the same thing for K_
Then make sure all functionaltiy compiles. I suggest making small changes and then checking the code compiles each time.
If you get a compilation error you don't understand then post it (the entire thing) here

Philip

Hi Philip,

Thanks for your guidance. I appreciate it.
That is exactly the procedure I am following.

The new model is now successfully compiled and I am testing on few cases and will let you know if the model is fitting the needs of nonLinearGeomtryLaw functionalities.

If everything goes fine I will request a commit into repository solids4foam-release.

I started first by duplicating neoHookeanElastic and rename everything into new model, and commenting out other constructors contents.

Just I like to highlight the errors I debugged while the conversion of the dimensionedScalar into volScalarField.

By switching mu and K into volScalarField , it turns out while compiling that the member function requires some modifications in other parts of the code, such as in the constructor for example, to correctly account for these volsScalarFields.

Code:

error:  cannot convert ‘Foam::volScalarField’ {aka  ‘Foam::GeometricField<double, Foam::fvPatchField, Foam::volMesh>’}  to ‘const dimensionedScalar&’ {aka ‘const  Foam::dimensioned<double>&’}



  202 |     if (updateFf(sigma, mu_, K_))

      |                         ^~~

      |                         |

      |                         Foam::volScalarField {aka Foam::GeometricField<double, Foam::fvPatchField, Foam::volMesh>}

Which needed to add interpolations into the constructors :

Code:

    muf_(fvc::interpolate(mu_)),

    Kf_(fvc::interpolate(K_))

As a consequence also surface field should be added to the class header should

Code:

surfaceScalarField muf_; 



surfaceScalarField Kf_;

other error in the member Functions:

Code:

 error:  no match for ‘operator=’ (operand types are  ‘Foam::surfaceSymmTensorField’ {aka  ‘Foam::GeometricField<Foam::SymmTensor<double>,  Foam::fvsPatchField, Foam::surfaceMesh>’} and  ‘Foam::tmp<Foam::Field<Foam::SymmTensor<double> > >’)

  219 |     sigma = (1.0/J)*(0.5*K_*(pow(J, 2) - 1)*I + s);

      |                                                  ^

I commented out linearised elasticity NOT to allowing solver enforceLinear switch.

Would you have any other comments feel free to let me know here.

Additional changes required in mechanicalLaw

Additional changes required in mechanicalLaw to overcome the error:

Code:

error: cannot convert ‘Foam::volScalarField’ {aka ‘Foam::GeometricField<double, Foam::fvPatchField, Foam::volMesh>’} to ‘const dimensionedScalar&’ {aka ‘const Foam::dimensioned<double>&’}



  202 |     if (updateFf(sigma, mu_, K_))

      |                         ^~~

      |                         |

      |                         Foam::volScalarField {aka Foam::GeometricField<double, Foam::fvPatchField, Foam::volMesh>}

It turned out that the current mechanicalLaw needs other changes in order to allow conversion of mu and K into volScalarField.

since the two quantities are defined in the mechanicalLaw.H as:

Code:

 



        bool updateF

        (

            volSymmTensorField& sigma,

            const dimensionedScalar& mu,

            const dimensionedScalar& K

        );



        //- Equivalent to the updateF function, except instead for the Ff

        //  surface field

        bool updateFf

        (

            surfaceSymmTensorField& sigma,

            const dimensionedScalar& mu,

            const dimensionedScalar& K

a newMechanicalLaw.H is needed with the changes made to dimensionedScalar into volScalarField.

I am saying that since there is a definition of the mu and K in the original mechanicalLaw as dimensionedScalar and I need to convert that to volScalarField.

In other word, Do I need to compile another newMechanicalLaw classe to supply to the my model.

Hi Aero_Smail,

In this case, the easiest thing is to re-write the "updateF" function directly in your new neoHookeanElasticFromFile class correct function, e.g.

Code:

void Foam::neoHookeanElasticFromFile::correct(volSymmTensorField& sigma)

{

    // We need to call the updateF procedures manually as mu and K are fields

    // if (updateF(sigma, mu_, K_))

    // {

    //     return;

    // }



    // Copied and modified from mechanicalLaw::updateF(...) where I have removed the enforceLinear stuff



    // Check if the mathematical model is in total or updated Lagrangian form

    if (nonLinGeom() == nonLinearGeometry::UPDATED_LAGRANGIAN)

    {

        if (!incremental())

        {

            FatalErrorIn(type() + "::correct(volSymmTensorField& sigma)")

                << "Not implemented for non-incremental updated Lagrangian"

                << abort(FatalError);

        }



        // Lookup gradient of displacement increment

        const volTensorField& gradDD =

            mesh().lookupObject<volTensorField>("grad(DD)");



        // Calculate the relative deformation gradient

        relF() = I + gradDD.T();



        // Update the total deformation gradient

        F() = relF() & F().oldTime();

    }

    else if (nonLinGeom() == nonLinearGeometry::TOTAL_LAGRANGIAN)

    {

        if (incremental())

        {

            // Lookup gradient of displacement increment

            const volTensorField& gradDD =

                mesh().lookupObject<volTensorField>("grad(DD)");



            // Update the total deformation gradient

            // Note: grad is wrt reference configuration

            F() = F().oldTime() + gradDD.T();



            // Update the relative deformation gradient: not needed

            relF() = F() & inv(F().oldTime());

        }

        else

        {

            // Lookup gradient of displacement

            const volTensorField& gradD =

                mesh().lookupObject<volTensorField>("grad(D)");



            // Update the total deformation gradient

            F() = I + gradD.T();



            // Update the relative deformation gradient: not needed

            relF() = F() & inv(F().oldTime());

        }

    }

    else

    {

        FatalErrorIn

        (

            "void " + type() + "::correct(volSymmTensorField& sigma)"

        )   << "Unknown nonLinGeom type: " << nonLinGeom() << abort(FatalError);

    }



    // ... rest of your correct function

}

In terms of a more permanent fix, I need to add an updateF function that takes mu and K as fields; I have added an issue on the git repo: https://bitbucket.org/philip_cardiff...d-allow-mu-and

compiled successfully

Dear Big Philip

That's very helpful to overcome this situation. Thank you for your guidance.
It is successfully compiled and the new library should be called in the controlDict.

I did add the updateF function into the new model and I did similarly to the other field function updateFf .

This is updating the sigma and I am testing on some cases to check the calculations are rational and let you know as soon as.

Thanks a lot Big Philip.