[Daniel_Khazaei]

Originally Posted by bigphil

Hi Daniel,


If you search for "Aitken acceleration" on google, you will finds lots of explanations, but essentially the acceleration factor does not have to be limited to be less than 1 or even positive.
As regards application of the Aitken's method to under-relaxation in FSI procedure, sometimes people may limit it but I am not sure of the reasoning (maybe they feel uncomfortable with relaxation factor >1 and/or <0)


You should be able to find descriptions of movingWallVelocity on the forum or at least in the code.
As far as I know, it is a boundary condition for the fluid velocity field for a wall that is moving.
This should not be used as a solid boundary condition.


I don't think you have set the correct boundary condition types for FSI in U and DU.
As regards what boundary condition to use for the patch shown, this depends on what physical condition you want to enforce. Typically you don't use zeroGradient as a solid boundary as it does not really correspond to a physical condition (it's kind of like zero strain).

Philip

thanks Dr. Cardiff

As for the last comment, yes you are right. Now I am clamping those patches with fixed displacement in every direction.

I will work on FSI patch boundary condition. Actually the solver does not allow any other boundary conditions exept fixedDisplacement types and solidTreaction.

-----------------

edit: I have talked to the author of that paper, they have used prescribed pressure and traction for FSI interface and No load for outer wall.

How can I apply No load boundary condition in OpenFOAM?


regrads

[VincentChai]

Hi Philip,

Thanks for your answer. At this moment, i cannot able to plot the tip deflection from the solver. May I have the code for generate the file as "historySolid.dat"? Very sorry for keep troubling you and thanks a lot for your help.



Regards,
Vincent

[VincentChai]

Hi Philip,

sorry for troubling you with questions again.
I tried to plot with smaller time step, but it still gave the same error message as:

ERROR: In /home/vin-82/OpenFOAM/OpenFOAM-1.6-ext/ThirdParty/rpmBuild/BUILD/ParaView-3.12.0/VTK/Filtering/vtkTable.cxx, line 353
vtkTable (0x9676cb0): Column "Probe Coordinates (Magnitude)" must have 1 rows, but has 2.

Please help me on plotting the tip deflection
Thanks.

Regards,
Vincent

[AsDF]

Hello,

while trying to run the icoFsiElasticNonLinULSolidFoam solver in parallel as described in the info file of the tutorial I experience the exact same error as the error Daniel mentioned earlier.
After that I recompiled the solver with the moveSolidMeshLeastSquares.H file from Philip but the simulation keeps stopping at 0.065s.
As I'm new to OpenFoam I don't know how to fix this problem and would really appreciate some help.

Time = 0.065, iteration: 2
Current fsi under-relaxation factor: 0.01
Maximal accumulated displacement of interface points: 0.0084761
Courant Number mean: 0.0443861 max: 0.522711 velocity magnitude: 1.31938
DILUPBiCG:  Solving for Ux, Initial residual = 4.75368e-05, Final residual = 3.94291e-07, No Iterations 1
DILUPBiCG:  Solving for Uy, Initial residual = 0.000110373, Final residual = 8.77263e-07, No Iterations 1
GAMG:  Solving for p, Initial residual = 0.000543828, Final residual = 8.25319e-07, No Iterations 30
GAMG:  Solving for p, Initial residual = 0.000102911, Final residual = 9.47413e-07, No Iterations 10
time step continuity errors : sum local = 3.23041e-10, global = -4.55244e-11, cumulative = 5.6536e-10
GAMG:  Solving for p, Initial residual = 0.000131358, Final residual = 7.9384e-07, No Iterations 24
GAMG:  Solving for p, Initial residual = 1.99396e-05, Final residual = 7.79756e-07, No Iterations 6
time step continuity errors : sum local = 2.65822e-10, global = 2.4541e-11, cumulative = 5.89901e-10
Setting traction on solid patch
Total traction force = (0.00431445 -7.4879e-06 3.43629e-22)
Solving for DU, Initial residual = 0.00589588, Final residual = 9.88846e-07, No outer iterations 41
Current fsi residual norm: 0.981515

Time = 0.065, iteration: 3
Current fsi under-relaxation factor (Aitken): 0.362946
Maximal accumulated displacement of interface points: 0.00876687
[0] 
[0] 
[0] --> FOAM FATAL ERROR: 
[0] face 41 area does not match neighbour by 0.0103705% -- possible face ordering problem.
patch: procBoundary0to1 my area:0.000239443 neighbour area: 0.000239418 matching tolerance: 0.0001
Mesh face: 42167 vertices: 4((0.574801 0.214706 0.025334) (0.574854 0.20998 0.025334) (0.574854 0.20998 -0.025334) (0.574801 0.214706 -0.025334))
Rerun with processor debug flag set for more information.
[0] 
[0]     From function processorPolyPatch::calcGeometry()
[0]     in file [1] 
[1] 
[1] --> FOAM FATAL ERROR: 
[1] face 41 area does not match neighbour by 0.0103705% -- possible face ordering problem.
patch: procBoundary1to0 my area:0.000239418 neighbour area: 0.000239443 matching tolerance: 0.0001
Mesh face: 42054 vertices: 4((0.574801 0.214706 0.025334) (0.574801 0.214706 -0.025334) (0.574854 0.209981 -0.025334) (0.574854 0.209981 0.025334))
Rerun with processor debug flag set for more information.
[1] 
[1]     From function processorPolyPatch::calcGeometry()
[1]     in file meshes/polyMesh/polyPatches/constraint/processor/processorPolyPatch.C at line 216.
[1] 
FOAM parallel run exiting
[1] 
meshes/polyMesh/polyPatches/constraint/processor/processorPolyPatch.C at line 216.
[0] 
FOAM parallel run exiting
[0] 
--------------------------------------------------------------------------
MPI_ABORT was invoked on rank 1 in communicator MPI_COMM_WORLD 
with errorcode 1.

NOTE: invoking MPI_ABORT causes Open MPI to kill all MPI processes.
You may or may not see output from other processes, depending on
exactly when Open MPI kills them.
--------------------------------------------------------------------------

Best regards

Michael

[davidsblom]

Hi Philip,

I'm currently validating the FSI solver, and as a first step I am trying to run the CSM3 test from the cylinder flap benchmark. So only a structure solver is used. I was wondering which settings to use, because with my current setup, the displacement of the flap is much larger than expected. I have used the elasticGravitySolidFoam solver.

What is the best approach for this problem? And I was wondering which divSigmaExpMethod to use. I'm currently using the standard approach, but I'm not aware of the differences between the different settings settings/surface/decompose/laplacian.

Best regards,
David

[bigphil]

Originally Posted by davidsblom

Hi Philip,

I'm currently validating the FSI solver, and as a first step I am trying to run the CSM3 test from the cylinder flap benchmark. So only a structure solver is used. I was wondering which settings to use, because with my current setup, the displacement of the flap is much larger than expected. I have used the elasticGravitySolidFoam solver.

What is the best approach for this problem? And I was wondering which divSigmaExpMethod to use. I'm currently using the standard approach, but I'm not aware of the differences between the different settings settings/surface/decompose/laplacian.

Best regards,
David

Hi David,

All divSigmaExp methods should produce very similar results; in theory "decompose" is the most accurate and I have found that "surface" is a bit more robust on bad meshes.

As regards gravity, the elasticGravitySolidFoam is a small strain solver so it's not appropriate for such large rotations as in the benchmark.
Essentially you should take elasticNonLinULSolidFoam and add the body force increment in the first time step (i.e. small modification to the solver).

Best regards,
Philip

EDIT:

Add something like this after DUEqn is created and before DUEqn.solve() is called:

           if (runTime.timeIndex() == 1)
            {
                // Add gravity increment on first time step
                DUEqn -=
                    rho*dimensionedVector("gravity", dimLength/(dimTime/dimTime), vector(0,-9.81,0));
            }

[davidsblom]

Originally Posted by bigphil

Hi David,

All divSigmaExp methods should produce very similar results; in theory "decompose" is the most accurate and I have found that "surface" is a bit more robust on bad meshes.

As regards gravity, the elasticGravitySolidFoam is a small strain solver so it's not appropriate for such large rotations as in the benchmark.
Essentially you should take elasticNonLinULSolidFoam and add the body force increment in the first time step (i.e. small modification to the solver).

Best regards,
Philip

EDIT:

Add something like this after DUEqn is created and before DUEqn.solve() is called:

           if (runTime.timeIndex() == 1)
            {
                // Add gravity increment on first time step
                DUEqn -=
                    rho*dimensionedVector("gravity", dimLength/(dimTime/dimTime), vector(0,-9.81,0));
            }

Hi Philip,

Thanks for your quick response. This fix seems to have solved the problem. At first I also tried to add the gravity force at each time step before trying the elasticGravitySolidFoam solver. What is the reason that the gravity forces is only applied during the first time step? It seems counterintuitive.
Thanks alot.

Another question. Currently, a slightly different solid solver is used in the icoFsiElasticNonLinULSolidFoam fluid-structure interaction solver. Are there a lot of differences between the two solid solvers? I'm considering of replacing the structure solver of icoFsiElasticNonLinULSolidFoam with the elasticNonLinULSolidFoam solver.
Thanks alot!

Best regards,
David

[bigphil]

Originally Posted by davidsblom

Thanks for your quick response. This fix seems to have solved the problem. At first I also tried to add the gravity force at each time step before trying the elasticGravitySolidFoam solver. What is the reason that the gravity forces is only applied during the first time step? It seems counterintuitive.
Thanks alot.

The momentum equation in the elasticNonLinULSolidFoam/FSI solvers are cast in their incremental form i.e. the increment of momentum is conserved for each time-step, the primary variable is then the increment of displacement DU.
Therefore the gravity body force need only be added in the first increment and then you are only solving for changes in momentum/forces (gravity force stays constant).
Hope this makes sense.

Originally Posted by davidsblom

Another question. Currently, a slightly different solid solver is used in the icoFsiElasticNonLinULSolidFoam fluid-structure interaction solver. Are there a lot of differences between the two solid solvers? I'm considering of replacing the structure solver of icoFsiElasticNonLinULSolidFoam with the elasticNonLinULSolidFoam solver.
Thanks alot!

The FSI solid solver uses the same approach so they are essentially the same, maybe just a few minor differences.

Philip

[davidsblom]

Originally Posted by bigphil

The momentum equation in the elasticNonLinULSolidFoam/FSI solvers are cast in their incremental form i.e. the increment of momentum is conserved for each time-step, the primary variable is then the increment of displacement DU.
Therefore the gravity body force need only be added in the first increment and then you are only solving for changes in momentum/forces (gravity force stays constant).
Hope this makes sense.


The FSI solid solver uses the same approach so they are essentially the same, maybe just a few minor differences.

Philip

Hi Philip,

I've calculated the first 4 seconds of the CSM3 cylinder flap benchmark, and it seems that the displacement of the flap is growing over time. I've attached a plot of the displacement over time. Any idea what is causing the "growing/diverging"?
I have similar problems with the fluid structure interaction case where the displacement grows over time. Possibly because the mesh is deformed at every time step?
I've tried to use the elasticNonLinTLSolidFoam solver, but this solver crashes directly at the first time step.
Thanks alot for your help.

flappingConsole_velocity2.jpg

[bigphil]

Originally Posted by davidsblom

Hi Philip,

I've calculated the first 4 seconds of the CSM3 cylinder flap benchmark, and it seems that the displacement of the flap is growing over time. I've attached a plot of the displacement over time. Any idea what is causing the "growing/diverging"?
I have similar problems with the fluid structure interaction case where the displacement grows over time. Possibly because the mesh is deformed at every time step?
I've tried to use the elasticNonLinTLSolidFoam solver, but this solver crashes directly at the first time step.
Thanks alot for your help.

It looks like the amplitude of the displacement oscillation is getting smaller (not growing), is that what you meant?

It would make sense if the oscillation was getting smaller: this would be due to the use of Euler time discretisation which is first order accurate in time.
Two possible remedies:

• smaller time steps
• more accurate time discretisation, such as backward d2dt2 scheme.

Philip

[davidsblom]

Originally Posted by bigphil

It looks like the amplitude of the displacement oscillation is getting smaller (not growing), is that what you meant?

It would make sense if the oscillation was getting smaller: this would be due to the use of Euler time discretisation which is first order accurate in time.
Two possible remedies:

• smaller time steps
• more accurate time discretisation, such as backward d2dt2 scheme.

Philip

Thanks. I was thinking that it was caused by the time integration scheme. Unfortunately, backward differencing d2dt scheme is not implemented in OpenFOAM.

I'm currently looking into the structure solver used by the fluid-structure interaction solver, and I've created a seperate solver with just the structure code. Can I add the same code snippet to this solver in order to simulate the same CSM3 problem?
Thanks in advance.

[bigphil]

Hi David,

The backward d2dt2 scheme is implemented in the forthcoming next release of OpenFOAM Extend (the nextRelease git branch can be downloaded).
The code is found at:
OpenFOAM-1.6-ext/src/finiteVolume/finiteVolume/d2dt2Schemes/backwardD2dt2Scheme

Alternatively a smaller time-step should help.

I'm currently looking into the structure solver used by the fluid-structure interaction solver, and I've created a seperate solver with just the structure code. Can I add the same code snippet to this solver in order to simulate the same CSM3 problem?

Yes that should work, assuming you create all the relevant fields.

Philip

[ben1793]

I have solved my previous problem but have a new one. I used the github for the official OpenFOAM 2.2x (I am using OpenFOAM-2.2.2). I tried to run the plate hole tutorial by using the blockMesh command then the elastricSolidFoam command, I then get the following error:

/*---------------------------------------------------------------------------*\
| =========                 |                                                 |
| \\      /  F ield         | OpenFOAM: The Open Source CFD Toolbox           |
|  \\    /   O peration     | Version:  2.2.2                                 |
|   \\  /    A nd           | Web:      www.OpenFOAM.org                      |
|    \\/     M anipulation  |                                                 |
\*---------------------------------------------------------------------------*/
Build  : 2.2.2-9240f8b967db
Exec   : elasticSolidFoam
Date   : Dec 15 2013
Time   : 12:37:57
Host   : "sk-VirtualBox"
PID    : 4790
Case   : /home/sk/OpenFOAM/sk-2.2.2/run/solidMechanics/tutorials/elasticSolidFoam/plateHole
nProcs : 1
sigFpe : Enabling floating point exception trapping (FOAM_SIGFPE).
fileModificationChecking : Monitoring run-time modified files using timeStampMaster
allowSystemOperations : Disallowing user-supplied system call operations

// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //
Create time

Create mesh for time = 0

Reading field U

Patch hole    Traction boundary field: U


--> FOAM FATAL IO ERROR: 
Unknown grad scheme extendedLeastSquares

Valid grad schemes are :

9
(
Gauss
cellLimited
cellMDLimited
edgeCellsLeastSquares
faceLimited
faceMDLimited
fourth
leastSquares
pointCellsLeastSquares
)


file: /home/sk/OpenFOAM/sk-2.2.2/run/solidMechanics/tutorials/elasticSolidFoam/plateHole/system/fvSchemes.gradSchemes.grad(U) at line 26.

    From function gradScheme<Type>::New(const fvMesh& mesh, Istream& schemeData)
    in file /opt/openfoam222/src/finiteVolume/lnInclude/gradScheme.C at line 72.

FOAM exiting

It cant seem to find the extendedLeastSquares grad scheme, is this something that needs to be changed or have I installed this feature incorrectly?

Thank you.

[Daniel_Khazaei]

Hello Dr. Cardiff

I have a question about running a turbulence case with FSI solver. I have successfully changed the fluid solver according to pisoFoam solver. Now the FSI solver is able to model a turbulence flow.

However I have a little problem in running the tutorial case in turbulence regime. At the first time step the pressure equation leads to very wrong values for pressure distribution in the fluid domain. Also I have tested the fluid part of your case separately with pisoFoam solver and I can see the same problem there. So I think that the turbulence FSI solver is working fine (at-least working like pisoFoam solver).

This problem leads to the divergence of solid solver in FSI solver.

I have done a few tests with pisoFoam solver and it seems that the pressure distribution becomes reasonable after a few time steps ( 4 or more ). Also the steady state solution of the case is in well agreement with fluent.

So I am guessing that the solver just needs a few time step to get rid of that wrong prediction. This is not going to produce any problem in fluid domain simulation, but FSI simulation will definitely diverges because of this. So I have changed the strongly coupled algorithm as follow:

         do
        {
            outerCorr++;

#           include "setInterfaceDisplacement.H"

#           include "moveFluidMesh.H"

#           include "solveFluid.H"

	    if (runTime.timeIndex() >= 4)
	    {
		#include "setInterfaceForce.H"
	    }

#           include "solveSolid.H"

#           include "calcFsiResidual.H"
        }

This will skip setting the pressure on solid side for a few time steps (4). By adding the above modification I am now able to run the tutorial case in turbulence regime.

Is there any side effects (skipping a few time steps) that I need to know?


regards

[codder]

@ Daniel_Khazaei

Originally Posted by Daniel_Khazaei

Hello Dr. Cardiff

I have a question about running a turbulence case with FSI solver. I have successfully changed the fluid solver according to pisoFoam solver. Now the FSI solver is able to model a turbulence flow.

Could you expand on this a bit, if possible? For instance, does that mean you were able to apply a fixedDisplacement boundary condition using a weak coupling on the FSI solver.

I'm looking into the feasibility (???) of using a dynamic mesh with this new class of solid domain solvers. Please excuse my ignorance I have attempted to put this question in the correct terms.

[davidsblom]

Originally Posted by bigphil

Hi David,

The backward d2dt2 scheme is implemented in the forthcoming next release of OpenFOAM Extend (the nextRelease git branch can be downloaded).
The code is found at:
OpenFOAM-1.6-ext/src/finiteVolume/finiteVolume/d2dt2Schemes/backwardD2dt2Scheme

Alternatively a smaller time-step should help.


Yes that should work, assuming you create all the relevant fields.

Philip

Hi Philip,

I'm currently testing foam extend 3.0. When running the CSM test of the cylinder flap benchmark with the elasticNonLinULSolidFoam solver, the correct solution is found. However, both the first order and second order time integration scheme give the same results. The order of the backward differencing scheme seems to be one.
Any idea what is causing this?

Also, I've tested the structure solver which is used by the fluid-structure interaction solver and looked at the two time integration schemes. The first order scheme gives the same results as the elasticNonLinULSolidFoam solver. But the second order backward differencing scheme does not give the correct result. Zero-th order behaviour is shown for the total displacement U, whereas the first order scheme shows the correct order.
Any ideas?

Many thanks.

Best,
David

[bigphil]

Originally Posted by davidsblom

Hi Philip,

I'm currently testing foam extend 3.0. When running the CSM test of the cylinder flap benchmark with the elasticNonLinULSolidFoam solver, the correct solution is found. However, both the first order and second order time integration scheme give the same results. The order of the backward differencing scheme seems to be one.
Any idea what is causing this?

Also, I've tested the structure solver which is used by the fluid-structure interaction solver and looked at the two time integration schemes. The first order scheme gives the same results as the elasticNonLinULSolidFoam solver. But the second order backward differencing scheme does not give the correct result. Zero-th order behaviour is shown for the total displacement U, whereas the first order scheme shows the correct order.
Any ideas?

Many thanks.

Best,
David

Hi David,

Hmnn, I haven't played with the backwardD2Dt2 scheme much but it should work: it was developed and implemented by Željko Tukovic as outlined in
this paper. See Fig 5 and Fig 6 comparing Euler and backward schemes; the backward scheme certainly reduces the dissipation, although I don't thing that second order accuracy was actually shown. Did you examine the 2nd Order slope of the error plot?
Did you notice that the backward scheme is more accurate (irregardless of order)?

As regards the structural solver within icoFsiElasticNonLinULSolidFoam, it should be the same but it is fine to comment out all the time scheme stuff and just use the built-in backward/Euler schemes like elasticNonLinULSolidFoam.

Best regards,
Philip

[davidsblom]

Originally Posted by bigphil

Hi David,

Hmnn, I haven't played with the backwardD2Dt2 scheme much but it should work: it was developed and implemented by Željko Tukovic as outlined in
this paper. See Fig 5 and Fig 6 comparing Euler and backward schemes; the backward scheme certainly reduces the dissipation, although I don't thing that second order accuracy was actually shown. Did you examine the 2nd Order slope of the error plot?
Did you notice that the backward scheme is more accurate (irregardless of order)?

As regards the structural solver within icoFsiElasticNonLinULSolidFoam, it should be the same but it is fine to comment out all the time scheme stuff and just use the built-in backward/Euler schemes like elasticNonLinULSolidFoam.

Best regards,
Philip

Hi,

Thanks for your quick response. Since the first order and second order scheme are giving me the exact same response, I looked at the source.

This is the code in backwardD2dt2Scheme.C:

template<class Type>
tmp<fvMatrix<Type> >
backwardD2dt2Scheme<Type>::fvmD2dt2
(
const dimensionedScalar& rho,
GeometricField<Type, fvPatchField, volMesh>& vf
)
{
tmp<fvMatrix<Type> > tfvm
(
new fvMatrix<Type>
(
vf,
rho.dimensions()*vf.dimensions()*dimVol
/dimTime/dimTime
)
);

fvMatrix<Type>& fvm = tfvm();

scalar deltaT = mesh().time().deltaT().value();
scalar deltaT0 = mesh().time().deltaT0().value();

scalar coefft = (deltaT + deltaT0)/(2*deltaT);
scalar coefft00 = (deltaT + deltaT0)/(2*deltaT0);

scalar rDeltaT2 = 4.0/sqr(deltaT + deltaT0);

if (mesh().moving())
{
notImplemented
(
type()
+ "::fvcD2dt2"
+ "("
+ "const dimensionedScalar& rho, "
+ "GeometricField<Type, fvPatchField, volMesh>& vf"
+ ")"
);
}
else
{
fvm.diag() = (coefft*rDeltaT2)*mesh().V()*rho.value();

fvm.source() = rDeltaT2*mesh().V()*rho.value()*
(
(coefft + coefft00)*vf.oldTime().internalField()
- coefft00*vf.oldTime().oldTime().internalField()
);
}

return tfvm;
}

This is the code in EulerD2dt2Scheme.C:

template<class Type>
tmp<fvMatrix<Type> >
EulerD2dt2Scheme<Type>::fvmD2dt2
(
const dimensionedScalar& rho,
GeometricField<Type, fvPatchField, volMesh>& vf
)
{
tmp<fvMatrix<Type> > tfvm
(
new fvMatrix<Type>
(
vf,
rho.dimensions()*vf.dimensions()*dimVol
/dimTime/dimTime
)
);

fvMatrix<Type>& fvm = tfvm();

scalar deltaT = mesh().time().deltaT().value();
scalar deltaT0 = mesh().time().deltaT0().value();

scalar coefft = (deltaT + deltaT0)/(2*deltaT);
scalar coefft00 = (deltaT + deltaT0)/(2*deltaT0);

scalar rDeltaT2 = 4.0/sqr(deltaT + deltaT0);

if (mesh().moving())
{
scalar halfRdeltaT2 = 0.5*rDeltaT2;

scalarField VV0 = mesh().V() + mesh().V0();

scalarField V0V00 = mesh().V0() + mesh().V00();

fvm.diag() = rho.value()*(coefft*halfRdeltaT2)*VV0;

fvm.source() = halfRdeltaT2*rho.value()*
(
(coefft*VV0 + coefft00*V0V00)
*vf.oldTime().internalField()

- (coefft00*V0V00)*vf.oldTime().oldTime().internalFi eld()
);
}
else
{
fvm.diag() = (coefft*rDeltaT2)*mesh().V()*rho.value();

fvm.source() = rDeltaT2*mesh().V()*rho.value()*
(
(coefft + coefft00)*vf.oldTime().internalField()
- coefft00*vf.oldTime().oldTime().internalField()
);
}

return tfvm;
}

Seems to be the same... Not sure how this is possible for a higher order scheme.
Any clues? To my knowledge, mesh().moving() returns false, since the dynamic mesh class is not used.

[bigphil]

Ah, I see now, there are three implicit functions defined in backwardbackwardD2dt2Scheme but only the first implemented backward scheme:

        tmp<fvMatrix<Type> > fvmD2dt2 // This is correct
        (
            GeometricField<Type, fvPatchField, volMesh>&
	);

	tmp<fvMatrix<Type> > fvmD2dt2 // this is just Euler
        (
            const dimensionedScalar&,
            GeometricField<Type, fvPatchField, volMesh>&
	);

	tmp<fvMatrix<Type> > fvmD2dt2 // this is just Euler
        (
            const volScalarField&,
            GeometricField<Type, fvPatchField, volMesh>&
        );

The code should give a not implemented error if either of the bottom two functions are called but the notImplemented functions were not added: I will let them know.

So, for now, you can try out the backward d2tdt2 scheme by changing:

                  fvm::d2dt2(rho,DU)

to

                  rho*fvm::d2dt2(DU)

in the solver code: this essentially assumes constant density for the calculation of inertia which is probably fine in most case.
It is probably straight-forward to implement the second two functions if you get an urge

Best regards,
Philip

[danny261083]

Hi Dr. Cardiff,

I was attempting to run the tutorial problem involving large deflections of a cantilever beam using the total lagrangian solver 'elasticNonLinTLSolidFoam' (in OpenFoam version 2.2.x). I received an error message stating that the extended least squares method was not a recognized solution method. I attempted to run the simulation using least squares, which resulted in small displacements, as can be seen in the enclosed image. I would like to know whether I might be implementing the test case incorrectly.

Thanks