CFD Online Logo CFD Online URL
www.cfd-online.com
[Sponsors]
Home > Forums > Software User Forums > OpenFOAM > OpenFOAM Community Contributions > OpenFOAM CC Toolkits for Fluid-Structure Interaction

[solidMechanics] Support thread for "Solid Mechanics Solvers added to OpenFOAM Extend"

Register Blogs Members List Search Today's Posts Mark Forums Read

Like Tree134Likes

Closed Thread
 
LinkBack Thread Tools Search this Thread Display Modes
Old   April 21, 2013, 17:05
Default
  #61
Super Moderator
 
bigphil's Avatar
 
Philip Cardiff
Join Date: Mar 2009
Location: Dublin, Ireland
Posts: 1,041
Rep Power: 32
bigphil will become famous soon enoughbigphil will become famous soon enough
Quote:
Originally Posted by brant View Post
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
bigphil is offline  

Old   April 25, 2013, 17:55
Default Anisotropic Solid Mechanics
  #62
New Member
 
Alex Bond
Join Date: Apr 2013
Posts: 1
Rep Power: 0
rockgatherer97 is on a distinguished road
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
rockgatherer97 is offline  

Old   April 25, 2013, 19:21
Default
  #63
Super Moderator
 
bigphil's Avatar
 
Philip Cardiff
Join Date: Mar 2009
Location: Dublin, Ireland
Posts: 1,041
Rep Power: 32
bigphil will become famous soon enoughbigphil will become famous soon enough
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
bigphil is offline  

Old   June 2, 2013, 22:05
Default icoFsiElasticNonLinULSolidFoam blowing up in parallel
  #64
New Member
 
Agnimitro Chakrabarti
Join Date: Mar 2012
Location: Louisiana, USA
Posts: 6
Rep Power: 12
Agni is on a distinguished road
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,
Agni is offline  

Old   June 7, 2013, 11:25
Default
  #65
Super Moderator
 
bigphil's Avatar
 
Philip Cardiff
Join Date: Mar 2009
Location: Dublin, Ireland
Posts: 1,041
Rep Power: 32
bigphil will become famous soon enoughbigphil will become famous soon enough
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
kaifu likes this.
bigphil is offline  

Old   June 11, 2013, 03:17
Default
  #66
New Member
 
Agnimitro Chakrabarti
Join Date: Mar 2012
Location: Louisiana, USA
Posts: 6
Rep Power: 12
Agni is on a distinguished road
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
Agni is offline  

Old   June 12, 2013, 05:34
Default IcoFsinonLinUlsolidFoam problem
  #67
Member
 
Samer
Join Date: Jan 2013
Posts: 31
Rep Power: 12
SamerAli is on a distinguished road
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
SamerAli is offline  

Old   June 28, 2013, 05:58
Default
  #68
New Member
 
Join Date: Mar 2013
Posts: 17
Rep Power: 11
davidsblom is on a distinguished road
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 is offline  

Old   June 28, 2013, 06:00
Default
  #69
New Member
 
Join Date: Mar 2013
Posts: 17
Rep Power: 11
davidsblom is on a distinguished road
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.
davidsblom is offline  

Old   July 5, 2013, 06:31
Default
  #70
Super Moderator
 
bigphil's Avatar
 
Philip Cardiff
Join Date: Mar 2009
Location: Dublin, Ireland
Posts: 1,041
Rep Power: 32
bigphil will become famous soon enoughbigphil will become famous soon enough
Quote:
Originally Posted by Agni View Post
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 is offline  

Old   July 5, 2013, 06:34
Default
  #71
Super Moderator
 
bigphil's Avatar
 
Philip Cardiff
Join Date: Mar 2009
Location: Dublin, Ireland
Posts: 1,041
Rep Power: 32
bigphil will become famous soon enoughbigphil will become famous soon enough
Quote:
Originally Posted by SamerAli View Post
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
bigphil is offline  

Old   July 5, 2013, 08:35
Default
  #72
New Member
 
Join Date: Mar 2013
Posts: 17
Rep Power: 11
davidsblom is on a distinguished road
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
davidsblom is offline  

Old   July 5, 2013, 10:20
Default
  #73
Super Moderator
 
bigphil's Avatar
 
Philip Cardiff
Join Date: Mar 2009
Location: Dublin, Ireland
Posts: 1,041
Rep Power: 32
bigphil will become famous soon enoughbigphil will become famous soon enough
Quote:
Originally Posted by davidsblom View Post
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
bigphil is offline  

Old   July 8, 2013, 12:49
Default
  #74
New Member
 
Join Date: Mar 2013
Posts: 17
Rep Power: 11
davidsblom is on a distinguished road
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
davidsblom is offline  

Old   July 17, 2013, 09:14
Default TureckFSI2 case
  #75
Member
 
Samer
Join Date: Jan 2013
Posts: 31
Rep Power: 12
SamerAli is on a distinguished road
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?
SamerAli is offline  

Old   July 17, 2013, 09:24
Default
  #76
Senior Member
 
Matthias Voß
Join Date: Mar 2009
Location: Berlin, Germany
Posts: 449
Rep Power: 18
mvoss is on a distinguished road
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?

Last edited by mvoss; July 17, 2013 at 09:56. Reason: edititing
mvoss is offline  

Old   July 17, 2013, 09:33
Default
  #77
Member
 
Samer
Join Date: Jan 2013
Posts: 31
Rep Power: 12
SamerAli is on a distinguished road
thanks for replying
ok for the density ratios but concerning the Young modulus why it's 1.4e04 instead of 1.4e06?
SamerAli is offline  

Old   July 22, 2013, 04:55
Default
  #78
Senior Member
 
Matthias Voß
Join Date: Mar 2009
Location: Berlin, Germany
Posts: 449
Rep Power: 18
mvoss is on a distinguished road
u r right. That´s a different topic.
mvoss is offline  

Old   July 22, 2013, 05:39
Default
  #79
Super Moderator
 
bigphil's Avatar
 
Philip Cardiff
Join Date: Mar 2009
Location: Dublin, Ireland
Posts: 1,041
Rep Power: 32
bigphil will become famous soon enoughbigphil will become famous soon enough
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
bigphil is offline  

Old   July 31, 2013, 17:50
Default
  #80
New Member
 
Join Date: Oct 2011
Posts: 28
Rep Power: 13
danny261083 is on a distinguished road
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
danny261083 is offline  

Closed Thread

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are Off
Pingbacks are On
Refbacks are On


Similar Threads
Thread Thread Starter Forum Replies Last Post
GPU Linear Solvers for OpenFOAM gocarts OpenFOAM Announcements from Other Sources 37 August 17, 2022 15:22
[Virtualization] OpenFOAM oriented tutorial on using VMware Player - support thread wyldckat OpenFOAM Installation 2 July 11, 2012 17:01
New OpenFOAM Forum Structure jola OpenFOAM 2 October 19, 2011 07:55
Cross-compiling OpenFOAM 1.7.0 on Linux for Windows 32 and 64bits with Mingw-w64 wyldckat OpenFOAM Announcements from Other Sources 3 September 8, 2010 07:25
OpenFOAM Debian packaging current status problems and TODOs oseen OpenFOAM Installation 9 August 26, 2007 14:50


All times are GMT -4. The time now is 02:22.