That's good to hear.

Hopefully the solvers will do what you want!

empty page in source-forge for the new solidMechanics solver
 

hi, dear Philip,

thanks a lot for sharing these new solvers. Since i found your old post saying that the codes can be manually download from the link, however when i click into it, an error shows: "no such project". I was wondering is this because the solvers have neem moved? may I ask you about where i can found and look at the codes now? Your kind response would greatly appreciated!

Tian

Hi Tian,

I think something might be wrong with the git on sourceforge.

The OpenFOAm-Extend project is found here:
http://sourceforge.net/projects/openfoam-extend/develop

And normally it is possible to browse the git code by clicking on the git browse code but it does not seem to be working at the moment.

Hmmn...

Philip

Hi, dear Philip

thanks for the quick response. yes, you are right, there seems a problem with the git repository of openfoam-extend. I just saw the news from OpenFOAM wiki that:

Currently links to the SVN and GIT repositories of openfoam-extend on Sourceforge are not working because these were taken offline. The reason for that is that ANSYS claims three classes (none of them really essential) of the 1.6-ext are under their copyright. The matter is being worked on. All other services at openfoam-extend are still functional.

hopefully, the problem will be fixed soon so I can look at your solidMechanics solver :)

regards,
Tian

Hi,
I was wondering (and found no answer to this yet) if one could use these solid solvers on an anisotropic materials like composites.
I guess the tricky part is importing the materials properties in the good reference frame but I'm not sure of this. The goal is the simulation of the aging (thermal / time equivalent) of a composite like bended pipe.
Any help would be greatly appreciated !
Regards,

Florian

Hi Florian,

Actually, I started working on simulation of orthotropic composite materials last year and I have developed a large strain orthotropic finite volume solver (elasticOrthoNonLinULSolidFoam) where the principal fibre directions are general. It requires 9 material properties (3 Young's moduli, 3 Poisson's ratio and 3 shear moduli) and the fibre direction field must be defined.

I have a written a paper on the development of the solver and it is currently under-review.
Once the paper is (hopefully) accepted, then I will add it to the solidMechanics branch.

If you are in a rush for the solver, then you can pm me and maybe we could collaborate.

Best regards,
Philip

Thank you for the answer. The thing is, I can't use an anisotropic material (5° angle between "fibers" orientation) but I can start with an isotropic material.

Also, I was wondering, is it complex to modify the elasticThermalSolidFoam into a large deformation solver with also a plastic behaviour ? This may sounds a bit messy but I'm trying to mimic the aging of human tissues (very simple at first) using thermics. The material proprieties would change with temperature in the same way the time does, on long term.
Regards,
Florian

Hi Florian,

In principle, it should not be that difficult to develop a large strain thermal-elasto-plastic solver, essentially all the work is done, you just have to merge the solvers elasticThermalSolidFoam, elasticPlasticSolidFoam and elasticNonLinTLSolidFoam.
The momentum equation will have small strain terms, large strain terms, a thermal stress term and a plastic stress term. Also make sure the traction boundary condition has all these terms.
That's the idea, let me know if you have any specific questions about it.

Best regards,
Philip

Thank you very much for your help ! I'll try to do that soon.

Best regards,

Florian

Hi Philip,

I have a small question with respect to your contribution, now that the git is offline.

I have found a formulation to a boundary condition, which requires a fixedCurvature type condition on the pressure, i.e. the second spatial derivative of the pressure normal to the boundary. Such a boundary condition is to my knowledge not available in OF, however, you will need that type of BC, when your are modelling solids, correct?

My question is: Will I be able to find an implementation, which I can modify, in the Solid Mechanics toolbox?

All the best

Niels

Hi Niels,

Hmmnn all the solidMechanics solvers are displacement based and therefore (hydrostatic) pressure is not needed - it can be calculated post processing if required.
But mixed displacement-pressure solvers should not need the second spatial derivative of pressure, actually you don't even need the first derivative as gradU/pressure is uniform for a cell.

Maybe I am not quite understanding the question, but all the solid BCs essentially just need gradU at the boundary and none use grad(gradU).

Best regards,
Philip

Hi Philip,

I probably was not that clear. The boundary condition in question is related to a flow solver and not related to solids.

The reason, I ask this question to you, is that I remember from my classes in civil engineering many years ago that a zero moment at a boundary is related to the second derivative of the displacement. Therefore I thought you might have implemented an abstract base class for this type of boundary condition, which I could "steal" for my purpose.

Nonetheless, I can understand that you do not need those in your formulation, thus I will try to see, if I can find the time to do the work myself.

Thanks,

Niels

Hi Niels,

OK I see, unfortunately I can't help.

Good luck!
Philip

Thanks anyway :)

hey phil,

i am currently testing the icoFsiElasticNonLinULSolidFoam - looks amazing!

just a minor suggestion: i think it's a bit misleading that the maximum number of Aitken iterations (nOuterCorr) is set in fvSolution under "PISO"...
wouldn't it make more sense if that parameter was set in couplingProperties, just like outerCorrTolerance etc.?

Hi Phil
i am using IcoFSINonLinUlSolidFoam for simulating fluid structure interaction and it's working very well for large deformations and the updated lagrangian used is perfect.
However i have a question and i am new to OpenFoam, how can i add the temperature equation and the temperature coupling at the interface with this solver??

Hi Samer,

That's good the solver is working for you.

To add temperature to icoFsiNonLinULSolidFoam, you need to add the energy equation for the solid and for the fluid. I think this stuff is already done for the conjugate heat transfer solvers (chtMultiRegionFoam, chtMultiRegionSimpleFoam).
So essentially you have to merge icoFsiNonLinULSolidFoam and chtMultiRegionFoam/chtMultiRegionSimpleFoam.
You can see how the interface temperature coupling is taken care of in the CHT solvers using a derived wall flux boundary condition.

Best regards,
Philip

EDIT: The wiki has a nice account of how to add temperature to the fluid here.
And you can see how temperature is added to the solid by comparing elasticSolidFoam and elasticThermalSolidFoam.
Then the last thing you need is the temperature coupling.

One more question: if i added the temperature equation and the coupling, do i have to make changes concerning running the solver in parallel??

1# maybe move to new thread
2# o.f. routines will handle the parallelization
3# http://openfoamwiki.net/index.php/Ho...ure_to_icoFoam

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

Anisotropic Solid Mechanics
 

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

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

icoFsiElasticNonLinULSolidFoam blowing up in parallel
 

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,

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

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

IcoFsinonLinUlsolidFoam problem
 

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 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.

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.

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

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

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

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

TureckFSI2 case
 

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?

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?

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

u r right. That´s a different topic.

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

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