[bigphil]

Originally Posted by brant

Hi Bigphil,

I am experienced at 3D modeling and have limited math skills..

I would like to model a hollow sphere or shell with interior resonant modes as well as shell modes, driven either from the interior or exterior... For extra credit I would like to model electric currents in the shell and use a material like iron to show magnetostrictive motions...

Is this at all possible in openFOAM? I would like to know if at least the shell with modes could be modeled before I invest a lot of time into FOAM...

What about plasma/solid interactions?

Thanks for your time,

Brant

Hi Brant,

In short, there are no ready to use solvers that will do what you want.
But if you have time and persistence, it is possible to do.

Main stumbling blocks: currently the solidMechanics solvers do not contain "shell elements", just continuum elements. Also, I am not aware of any solvers which solve for vibration frequencies.

However, implementing electromagnetic coupling should not be too much trouble, and plasma-solid interactions could follow a similar approach to FSI using a partitioned strategy.

Philip

[rockgatherer97]

As a bit of a hobby I've been playing around with solid mechanics using FV methods (not using OpenFOAM). Part of the inspiration has been some of the OpenFOAM approaches.

The approach I've been using has migrated into variants on mixed elements in order to do multi-materials, plasticity, viscosity, in structured and unstructured grids but much of the basic formulation remains the same (although the solution method is different).

The one area I haven't got working yet is anisotropy in unstructured grids - I note that you mentioned earlier in this thread that you were working on this in OpenFOAM. As a newbie to OpenFOAM I would be very interested in any documentation you might have - as a newbie I stand more of a chance with the maths rather than decoding the source code!

Have you written anything on this that you could point me in the direction of, or know of anything suitable?

Many thanks

[bigphil]

Hi rockgatherer97,

Yes I have an orthotropic solver working for large strain including updating/rotation of the constitutive tensor.
I am currently waiting for the paper to be published and then I will add the orthotropic solvers to the solidMechanics branch.

If you pm me your email address I can share some of my documentation.

Best regards,
Philip

[Agni]

Hi Phil,

At the very beginning I want to thank you for contributing such an excellent solid mechanics solver family to the community. It is quite sophisticated already and easy to use.

I am specifically interested in modelling fluid structure interaction of materials of biological nature in the density ratio range of 1 (0.9-1.2 to be exact) having E in the range 10^8 10^10 under a variety of oscillatory flow conditions. I found your strongly coupled icoFsiNonULSolidFoam very convenient for the purpose (though I am unsure about the impact on accuracy due to the almost 1:1 density ratio in my case and have not tested on any benchmark cases yet) but the ability of the solver to handle the said range of mechanical properties seems quite good (at least they are not blowing up). I have a few issues though which I would be very glad if you could help me out with:

1. Parallelization issue: I tried to run the HronTurekFsi tutorial in parallel but the simulation blows up after 0.1s, here is the error message at the end of the log file:

Time = 0.113, iteration: 5
Current fsi under-relaxation factor (Aitken): 0.636384
Maximal accumulated displacement of interface points: 0.00816615
Courant Number mean: 0.0610339 max: 0.718992 velocity magnitude: 1.83207
DILUPBiCG: Solving for Ux, Initial residual = 2.46273e-06, Final residual = 2.18431e-07, No Iterations 1
DILUPBiCG: Solving for Uy, Initial residual = 4.56057e-06, Final residual = 7.18109e-07, No Iterations 1
GAMG: Solving for p, Initial residual = 0.0119086, Final residual = 9.79583e-07, No Iterations 68
GAMG: Solving for p, Initial residual = 0.00341528, Final residual = 9.7922e-07, No Iterations 36
time step continuity errors : sum local = 2.95849e-11, global = -6.79251e-12, cumulative = 1.50034e-09
GAMG: Solving for p, Initial residual = 0.00199529, Final residual = 9.62323e-07, No Iterations 34
GAMG: Solving for p, Initial residual = 0.000339308, Final residual = 9.32171e-07, No Iterations 18
time step continuity errors : sum local = 2.81752e-11, global = 4.62707e-12, cumulative = 1.50497e-09
Setting traction on solid patch
Total traction force = (0.00638315 8.51814e-08 1.25197e-24)
Solving for DU, Initial residual = 0.0297478, Final residual = 9.87692e-07, No outer iterations 112
Current fsi residual norm: 0.150793

Time = 0.113, iteration: 6
Current fsi under-relaxation factor (Aitken): 0.807517
Maximal accumulated displacement of interface points: 0.00806282
[0]
[0]
[0] --> FOAM FATAL ERROR:
[0] face 41 area does not match neighbour by 0.0102527% -- possible face ordering problem.
patch: procBoundary0to1 my area:0.000239405 neighbour area: 0.000239429 matching tolerance: 0.0001
Mesh face: 42167 vertices: 4((0.575048 0.214638 0.025334) (0.575099 0.209913 0.025334) (0.575099 0.209913 -0.025334) (0.575048 0.214638 -0.025334))
Rerun with processor debug flag set for more information.
[0]
[0] From function processorPolyPatch::calcGeometry()
[0] in file meshes/polyMesh/polyPatches/constraint/processor/processorPolyPatch.C at line 216.
[0] [1]
[1]
[1] --> FOAM FATAL ERROR:
[1] face 41 area does not match neighbour by 0.0102527% -- possible face ordering problem.
patch: procBoundary1to0 my area:0.000239429 neighbour area: 0.000239405 matching tolerance: 0.0001
Mesh face: 42054 vertices: 4((0.575048 0.214638 0.025334) (0.575048 0.214638 -0.025334) (0.575099 0.209913 -0.025334) (0.575099 0.209913 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]

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.
--------------------------------------------------------------------------
--------------------------------------------------------------------------
mpirun has exited due to process rank 0 with PID 30367 on
node coastal-5.lsu.edu exiting without calling "finalize". This may
have caused other processes in the application to be
terminated by signals sent by mpirun (as reported here).
--------------------------------------------------------------------------
[coastal-5.lsu.edu:30366] 1 more process has sent help message help-mpi-api.txt / mpi-abort
[coastal-5.lsu.edu:30366] Set MCA parameter "orte_base_help_aggregate" to 0 to see all help / error messages



Now my openfoam parallelization skills are not very good to understand what is going on here. It appears there is a threshold set on meshes/polyMesh/polyPatches/constraint/processor/processorPolyPatch.C as far as neighbour face areas on processor patches are concerned and whenver this is exceeded the solver blows. This is the same problem on all other geometries that I tested. When fsi is set to 'no' however they run fine. Btw serial runs are perfectly okay for every one of them (so its not a Co or solidMechanics fpe problem). I believed at first this might be a moving mesh problem but my other fvDynamicMesh based solvers (derived primarily from interDyMFoam) work fine in parallel. I am puzzled and don't know whether it has to do something with the solidMechanics portion? My settings are exactly the same as in the HronTurek tutorial with 2 processors for the solid and 2 for the fluid.


2. Different elastic modulus (E) values for the 2 axes (2D problems): Currently I understand the E value is isotropic for the entire solid body. If I wanted to model a structure with varying E (say 10^8 in horizontal and 10^15 in the vertical direction), is that possible. If so can you give me any leads as how to modify the code. Basically I'd want to limit tensile and compressive strains along a given direction while not impacting the bending nature along that axis (I know this sounds kind of contradictory as for continuum bodies this is unnatural, but in reality my bio structure is actually made of composite shells so I have to resort to some numerical trick here).

3. 3D runs: Can this be run in 3D? I actually set up a 3D case and though it runs but the deformations are totally wrong. Also I seem to get the following warning in the log files:

Time = 1.1, iteration: 5
Maximal accumulated displacement of interface points: 0.0318624
--> FOAM Warning :
From function twoDPointCorrector::twoDPointCorrector(const polyMesh& mesh, const vector& n)
in file twoDPointCorrector/twoDPointCorrector.C at line 157
the number of vertices in the geometry is odd - this should not be the case for a 2-D case. Please check the geometry.
--> FOAM Warning :
From function twoDPointCorrector::twoDPointCorrector(const polyMesh& mesh, const vector& n)
in file twoDPointCorrector/twoDPointCorrector.C at line 169
The number of points in the mesh is not equal to twice the number of edges normal to the plane - this may be OK only for wedge geometries.
Please check the geometry or adjust the orthogonality tolerance.

Number of normal edges: 7018 number of points: 10527
Courant Number mean: 0.14769 max: 2.58191 velocity magnitude: 0.688377
GAMG: Solving for p, Initial residual = 0.000624781, Final residual = 7.64904e-07, No Iterations 5
time step continuity errors : sum local = 5.46083e-07, global = -1.12797e-07, cumulative = 4.53182e-06
GAMGPCG: Solving for p, Initial residual = 0.000212171, Final residual = 4.0408e-08, No Iterations 3
time step continuity errors : sum local = 2.90242e-08, global = -3.75851e-10, cumulative = 4.53144e-06
Setting traction on solid patch
Total traction force = (-0.000732346 8.22296e-05 0.000250634)
Solving for DU, Initial residual = 0, Final residual = 0, No outer iterations 0
Current fsi residual norm: 0.949729


As I understand from src/meshTools/twoDPointCorrector/twoDPointCorrector.C it can only handle 2D cases as it puts a check on the motion in the 3rd direction, thus even though our solid body may be modelled to "deform" somehow in the 3rd direction the mesh won't (and thus the un-physical nature of my 3D body!). How can I modify the code if I want to run a 3D case if that is even possible at this point that is. I am sorry my knowledge of low level OF classes are not extensive so I could not make any headway with that. I understand there might be complexities when you have basically a 9DOF solid body problem and the resulting issues that will be created within the constitutive relations themselves. Any inputs as to how to handle it or any info as to if you are planning to launch a 3D solver in the future will be very much appreciated.

Pls let me know if you want to look at the setup files I'll email them to you. Btw I'm running this on OpenFOAM1.6-ext as usual.


Once more thank you and to all the developers who made this brilliant toolbox possible for the OpenFOAM community.

Cheers,

[bigphil]

Hi Agnimitro,

Sorry for the delay in replying - it takes time to read such a long post .

You are welcome, hopefully you will find the solvers useful.

Point 1
This error is related to the faces on processor boundaries not being moved consistently across processors - there must be a problem with the least squares interpolation...
You could try moving the mesh with using inverse distance interpolation instead of least squares interpolation (use moveSolidMesh.H_old instead of "moveSolidMeshLeastSquares.H" at the bottom of the solver and recompile).

Point 2
You need an orthotropic solver. As I mentioned previously in this thread, I have developed an orthotropic solver and intend to add it to this repository once it is published. Hopefully that will be soon. If you urgently need the code, then you can contact me and we can collaborate.

Point 3
The solver should work fine in 3-D, the twoDCorrector code should only modify mesh motion when the case is actually 2-D. If this is a problem then just comment out the twoDCorrector stuff from the solver.

Best regards,
Philip

[Agni]

Hi Philip,

Thanks a lot for your reply. I actually figured out the processor face neighbour problem. I just added preservePatches (plate) on the last line of decomposeParDict. As I understood from the incompressible/icoDyMFoam/turboPassageRotating tutorial, this causes the patches on the solid-fluid interface to be forcibly taken by one processor only and thus prevents the neighbour face mismatch (es) as the mesh moves. I initially thought the globalZone(plate) should have taken care of that, but somehow that alone does not do the trick. Switching the solver from the leastSquares to the older one also does not seem to be of much help as the case still has mismatch problems unless we use the preservePatches command. There is however one other solution, if we decompose the domain manually and force the entire moving mesh zone (in the vicitnity of the body) into one single processor, however that is a nightmare in terms of load balancing and not recommended at all for just one body. With multiple moving objects in a domain it might help.

I will be eagerly waiting for the orthotropic solver and your paper. I don't need it immediately as its the second part of my dissertation work so I can wait for now. I ran the 3D case with the twoDPointCorrector commented out as you recommended, the warnings vanished but I still get weird deformations. I have not been able to do rigorous tests as I have a conference presentation this week, I am going to run a few more tests and bring it up if I can't I pinpoint the problem.

Thanks a bunch once again for your tips.


Cheers,

-A

[SamerAli]

Hi phill
thanks for this solver first of all....i was trying to run Tureck case using this solver and the thing is when i stop the simulation and i run it from where it stops...it always diverges afterwords....it works fine when it is run without stopping.....are you able to give me a hint for the problem??
thank you in advance

[davidsblom]

Hi Philip,

Many thanks for all your great work on the different OpenFOAM solvers. I have just compiled the FSI solver for OpenFOAM 2.2.0. However, when I run the tutorial Turek test case, the solver exits with the following message:

/*---------------------------------------------------------------------------*\
| ========= | |
| \\ / F ield | OpenFOAM: The Open Source CFD Toolbox |
| \\ / O peration | Version: 2.2.0 |
| \\ / A nd | Web: www.OpenFOAM.org |
| \\/ M anipulation | |
\*---------------------------------------------------------------------------*/
Build : 2.2.0-9ad583cf07b4
Exec : icoFsiElasticNonLinULSolidFoam
Date : Jun 28 2013
Time : 10:52:34
Host : "tud276993"
PID : 19591
Case : /data/localhome/davidblom/Downloads/solidMechanics_OpenFOAM-2.2.0/solidMechanics/tutorials/icoFsiElasticNonLinULSolidFoam/HronTurekFsi/fluid
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

Selecting dynamicFvMesh dynamicMotionSolverFvMesh
Selecting motion solver: laplaceFaceDecomposition


--> FOAM FATAL ERROR:
solver table is empty

From function motionSolver::New(const polyMesh& mesh)
in file motionSolver/motionSolver/motionSolver.C at line 117.

FOAM exiting

__________________________________________________ _-

I hope you can give a hint what is going wrong. I successfully used the FSI solver with OpenFOAM 1.6 extend, so I'm not sure what is the problem.

[davidsblom]

Hi Philipp,

I have another question, I'm trying to run the FSI solver in paralell. I'm using the OpenFOAM 1.6 extend version of the solver. I can run the tutorial is serial, but when I run the Turek test case in parallel the points file cannot be found. Any idea what's wrong here?
Thanks alot!!

I used the following Allrun script:

#!/bin/sh

currDir=`pwd`
application=`basename $currDir`
case="HronTurekFsi"

tutorialPath=`dirname $0`/..
. $WM_PROJECT_DIR/bin/tools/RunFunctions

(cd $case/fluid; runApplication setSet -case fluid -batch fluid/batch.setSet)
(cd $case/fluid; runApplication setsToZones -case fluid -noFlipMap)
(cd $case/solid; runApplication setSet -case solid -batch solid/batch.setSet)
(cd $case/solid; runApplication setsToZones -case solid -noFlipMap)
(cd $case; ./makeSerialLinks fluid solid)
#(cd $case/fluid; runApplication $application)

cd $case/fluid

decomposePar

#$application

mpirun -np 2 $application -parallel

__________________________________________________

The following error occurs:
/*---------------------------------------------------------------------------*\
| ========= | |
| \\ / F ield | OpenFOAM Extend Project: Open source CFD |
| \\ / O peration | Version: 1.6-ext |
| \\ / A nd | Web: www.extend-project.de |
| \\/ M anipulation | |
\*---------------------------------------------------------------------------*/
Build : 1.6-ext-8994a85c2d6a
Exec : icoFsiElasticNonLinULSolidFoam -parallel
Date : Jun 28 2013
Time : 10:57:58
Host : tud276993
PID : 20175
Case : /data/localhome/davidblom/Downloads/solidMechanics/tutorials/icoFsiElasticNonLinULSolidFoam/HronTurekFsi/fluid
nProcs : 2
Slaves :
1
(
tud276993.20176
)

Pstream initialized with:
floatTransfer : 0
nProcsSimpleSum : 0
commsType : blocking
SigFpe : Enabling floating point exception trapping (FOAM_SIGFPE).

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

Create dynamic mesh for time = 0

Selecting dynamicFvMesh dynamicMotionSolverFvMesh
Selecting motion solver: laplaceFaceDecomposition
Selecting motion diffusivity: quadratic

Reading transportProperties

Reading field p

Reading field U

Reading/calculating face flux field phi

[0]
[0]
[0] --> FOAM FATAL ERROR:
[0] Cannot find file "points" in directory "constant/solid/polyMesh"
[0]
[0] From function Time::findInstance(const fileName&, const word&, const IOobject::readOption)
[0] in file db/Time/findInstance.C at line [1]
[1]
[1] --> FOAM FATAL ERROR:
[1] Cannot find file "points" in directory "constant/solid/polyMesh"
[1]
[1] From function Time::findInstance(const fileName&, const word&, const IOobject::readOption)
[1] in file db/Time/findInstance.C at line 148.
[1]
FOAM parallel run exiting
[1]
148.
[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.
--------------------------------------------------------------------------
--------------------------------------------------------------------------
mpirun has exited due to process rank 1 with PID 20176 on
node tud276993 exiting without calling "finalize". This may
have caused other processes in the application to be
terminated by signals sent by mpirun (as reported here).
--------------------------------------------------------------------------
[tud276993:20174] 1 more process has sent help message help-mpi-api.txt / mpi-abort
[tud276993:20174] Set MCA parameter "orte_base_help_aggregate" to 0 to see all help / error messages

__________________________________________________ _______________________________________--

Edit: I figured out how to run the case in parallel. When the computational domain is split up, the solid mesh should be available in fluid/processor*/. Therefore, the Allrun file needs to be modified accordingly, and the makeLinks script should be used to link the solid mesh.

[bigphil]

Originally Posted by Agni

Hi Philip,

Thanks a lot for your reply. I actually figured out the processor face neighbour problem. I just added preservePatches (plate) on the last line of decomposeParDict. As I understood from the incompressible/icoDyMFoam/turboPassageRotating tutorial, this causes the patches on the solid-fluid interface to be forcibly taken by one processor only and thus prevents the neighbour face mismatch (es) as the mesh moves. I initially thought the globalZone(plate) should have taken care of that, but somehow that alone does not do the trick. Switching the solver from the leastSquares to the older one also does not seem to be of much help as the case still has mismatch problems unless we use the preservePatches command. There is however one other solution, if we decompose the domain manually and force the entire moving mesh zone (in the vicitnity of the body) into one single processor, however that is a nightmare in terms of load balancing and not recommended at all for just one body. With multiple moving objects in a domain it might help.

I will be eagerly waiting for the orthotropic solver and your paper. I don't need it immediately as its the second part of my dissertation work so I can wait for now. I ran the 3D case with the twoDPointCorrector commented out as you recommended, the warnings vanished but I still get weird deformations. I have not been able to do rigorous tests as I have a conference presentation this week, I am going to run a few more tests and bring it up if I can't I pinpoint the problem.

Thanks a bunch once again for your tips.


Cheers,

-A

Hi Agni,

Sorry for the delay in replying; I was on holidays .

As regards the processor face neighbour problem this is strange as the solver was developed to work is parallel with an arbitrary decomposition. The globalFaceZones (specified in decomposeParDict) should take care of all of this stuff, and make sure the fluid/solid interpolations and mesh motions are correct in parallel.
I will have a look again at this case if I get some time.

Regards,
Philip

[bigphil]

Originally Posted by SamerAli

Hi phill
thanks for this solver first of all....i was trying to run Tureck case using this solver and the thing is when i stop the simulation and i run it from where it stops...it always diverges afterwords....it works fine when it is run without stopping.....are you able to give me a hint for the problem??
thank you in advance

Hi Samer,

Hmnn that is strange, it should behave in the same fashion for restarted cases.

It might not solve your problem but increasing tolerances normally helps the FSI convergence.

Regards,
Philip

[davidsblom]

Hi Philip,

I'm working on the FSI solver and I have split it up in two different OpenFOAM solvers. The structure and flow solver are coupled with a FSI coupling tool.

Currently, both the pressure and the traction need to be communicated from the flow solver to the structure solver. I'm not sure how the structure solver is set up, but is it possible to only transfer the pressure?

Thanks alot.

Best regards,

David

[bigphil]

Originally Posted by davidsblom

Hi Philip,

I'm working on the FSI solver and I have split it up in two different OpenFOAM solvers. The structure and flow solver are coupled with a FSI coupling tool.

Currently, both the pressure and the traction need to be communicated from the flow solver to the structure solver. I'm not sure how the structure solver is set up, but is it possible to only transfer the pressure?

Thanks alot.

Best regards,

David

Hi David,

Yes transferring just pressure should be fine, you can keep the stress traction as zero on the solid.

If you have more specific questions, let me know.

Regards,
Philip

[davidsblom]

Hi Philipp,

Thanks for your quick response. I'm further developing the FSI solver, and trying to setup an efficient parallel computation. In my current setup, it is possible that the solid boundary is not available on every core, since the code should work eficiently on a large number of cpu cores.

However, for this case, the flow solver seems to stall and use 100 cpu load at the initialization of the UEqn vector matrix. Any ideas how to fix this problem?
Thanks alot.

Best regards,

David

[SamerAli]

Dear Phill

in the tutorial of icoFsiElasticnonLinUlsolidFoam of HronTureck, in the info text you mentinoned it's Tureck FSI2, however looking at the conditions in the dictionary files i found that for fluid : rho=1 kg/m^3 and for solid rho=10 kg/m^3 and E=1.4X10^4 Pa
But looking at the benchmark setup of Tureck FSI2 in his paper:
E=1.4e06 Pa and rhosolid=10 000 Kg/m^3 and rhoFluid=1000 kg/m^3

Would you please clarify?

[mvoss]

The ratio is the crucial thing, not the absolute values. So it´s basically the same setup regarding the solid and fluid densities.

Besides: anyone around who managed to get "FSI3" running for ratio ~1?

[SamerAli]

thanks for replying
ok for the density ratios but concerning the Young modulus why it's 1.4e04 instead of 1.4e06?

[mvoss]

u r right. That´s a different topic.

[bigphil]

Hi Samer and others,

The settings in the included HronTurek test case are just arbitrarily set and should be changed to replicate the actual Hron and Turek benchmark cases.

As regards convergence, increasing tolerances (and making sure these tolerance are actually met - you may need more iterations) should help achieve convergence.

Hope it helps,
Philip

[danny261083]

Hi Dr. Cardiff,

I was wondering whether the solid solvers support meshes of all shapes particularly tetrahedral. I am dealing with very complex biological features such as the respiratory tract, with the surface mesh typically being exported as an unstructured triangulated surface. I was also unsure whether the total lagrangian solver is for a specific material model like StVk, Mooney Rivlin, Neo-Hookean, etc.

Regards