CFD Online Discussion Forums - [solidMechanics] Support thread for "Solid Mechanics Solvers added to OpenFOAM Extend"

Page 28 of 35

Show 40 post(s) from this thread on one page

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

- OpenFOAM CC Toolkits for Fluid-Structure Interaction (https://www.cfd-online.com/Forums/openfoam-cc-toolkits-fluid-structure-interaction/)

- - [solidMechanics] Support thread for "Solid Mechanics Solvers added to OpenFOAM Extend" (https://www.cfd-online.com/Forums/openfoam-cc-toolkits-fluid-structure-interaction/126706-support-thread-solid-mechanics-solvers-added-openfoam-extend.html)

sita	July 15, 2020 10:56

Clamp boundary condition

Hi Philip,

Thanks for getting back! What I would like to do is to impose a fixed displacement on a symmetry plane of a beam-like geometry (symmetry plane perpendicular to the beam axis). As we're dealing with a symmetry plane, the beam axis should remain perpendicular to the symmetry plane.

In a classic beam bending case, it would be sufficient to also fix the rotation of the beam, but an elastic solid isn't restricted to only bending deformation, so when I apply a fixedDisplacement BC (therefore letting go of the symmetry BC), there will also be shear deformation, causing a sort of dent in the geometry if you'd mirror it in its symmetry plane.

I hope my explanation is clear, but if you need illustrations please let me know.

Thanks,
Sita

P.S. My workaround for now is to hold on to the symmetry BC, and use an additional, small object to press down on my geometry (similar to the pipeCrush tutorial), but that feels like a bit of an overkill

bigphil

July 15, 2020 11:09

Hi Sita,

I am not sure I understand what you mean by symmetry plane: a symmetry plane full defines the condition so it is not possible to apply an additional condition. For example, you can have symmetryPlane or fixedDisplacement but not both.

Also, by definition, a symmetry has zero shear force/stress.

Yep an illustration would help me understand better.

Philip

sita	July 16, 2020 01:48

Clamp boundary condition

4 Attachment(s)

Hi Philip,

Sorry, I probably should have added some pictures straight off. I've attached screenshots of the initial and final geometries (full and quarter, with two symmetry planes). The symmetry plane I was talking about earlier is the one on the top left of Initial_Quarter.png.

Thank you for your patience!
Sita

bigphil

July 17, 2020 07:26

Thanks,

What are the loading conditions?

Philip

sita	July 17, 2020 07:43

Clamp boundary condition

Hi Philip,

Those images were made by assigning a symmetry BC to the bottom right horizontal symmetry plane, and imposing a fixedDisplacement to the top left vertical patch (which should have been a symmetry plane too). So it's really just an annular cross section being squeezed in the middle.

For the inner and outer walls I used solidTraction, and the front and back are empty (i.e. 2D geometry). The deformation is purely elastic, no plastic deformation.

Thanks,
Sita

bigphil

July 17, 2020 07:47

Hi Sita,

For the full case (no symmetries), what are (or would be) the boundary conditions?

Philip

sita	July 17, 2020 07:58

Clamp boundary condition

Ah right, that's what you mean. That would be a fixed displacement inward for the top and bottom point, the rest of the geometry is free to follow.

bigphil

July 17, 2020 09:22

OK, thanks, now I understand.

In finite element (or vertex-based finite volume) method, you could apply a displacement directly to the top vertex, however, as we are using the cell-centre finite volume method here, our options are to apply a displacement to a boundary face-centre or to an internal cell-centre.

I suggest the following:

Use conventional symmetry planes at the top-left and bottom-right;
Create a small patch with one face on the pipe outer boundary, adjacent to the top symmetry plane, and apply a fixed displacement to this. You can use the "addTinyPatch" utility in solids4foam to create this small patch.

This will mimic a displacement being applied to the point and will give the same result as the mesh is refined.

Philip

sita	July 17, 2020 09:30

Clamp boundary condition

Hi Philip,

Yes, I'm aware of those differences in implementation, just couldn't think of a concise way of describing my full-geometry BCs in finite volume language, but glad you get it now anyway.

Great, addTinyPatch looks perfect, I'll try that!

Thanks a million for helping out,
Sita

sita	July 20, 2020 10:14

Clamp boundary condition

Brilliant, addTinyPatch works like a charm, thanks again!

serfriz

July 22, 2020 17:27

Quote:

Originally Posted by serfriz (Post 776548)

Hello Dr. Cardiff and everyone,

I am working on a simulation that involves FSI and crack propagation using the solids4foam library with foam-extend 4.0. I am having some issues when the cells break at the solid-fluid interface and I suspect it's because the fluid dynamicFvMesh is not suitable for fractures, or the fields mapping at the interface can't handle it.

So far my simulation is kind of a mix between the tutorials HronTurekFsi3 and crackingBeams (with my own structured grids). To be able to run the simulation I am geometrically forcing the crack to happen inside the solid mesh, and I let it propagate only restricting the fracture of the cells at the fluid-solid interface. If I let it break the solid's surface (actually forcing it to ensure it's the face I want) I am getting the following error:

Code:

There are 1 potential internal crack faces

There are 0 potential coupled boundary crack faces

Writing cohesiveZone field



Max traction fraction: 1.03503

    faceToBreakIndex: 1525

    faceToBreakLocation: (0.17108 0.249236 0.0075)

    faceToBreakEffTracFrac: 1.03503

Breaking internal face : (0.17108 0.249236 0.0075)

Updating field values on newly broken faces

Solving the momentum equation for D

    Corr, res, relRes, matRes, iters

    100, 5.54236e-06, 0.000386495, 0, 11

    200, 8.08764e-07, 6.82882e-05, 0, 11

    300, 1.78722e-07, 1.49448e-05, 0, 11

    The solver residual has converged

    339, 9.90346e-08, 8.27192e-06, 0, 11





There are 0 potential internal crack faces

There are 0 potential coupled boundary crack faces

Writing cohesiveZone field



Max traction fraction: 0

Interpolating point values using GGI





--> FOAM FATAL ERROR: 

fromField is the wrong size!

fromField size: 244, fromZone size: 242



    From function void Foam::interfaceToInterfaceMapping::checkFieldSizes

(

    const label fromFieldSize, const label toFieldSize

) const



    in file fluidSolidInterfaces/fluidSolidInterface/interfaceToInterfaceMapping/interfaceToInterfaceMapping/interfaceToInterfaceMapping.C at line 117.



  FOAM aborting

I attached some pictures of my working simulation (forcing no fracture in the surface layer of cells), and there are a couple more images in this link: https://imgur.com/a/o82gw8a. As a remark, after the last picture the simulation also fails (leaving one of the cells hanging from one side).

Are there any limitations of the fracture/SFI implementation I am running into? Or are these issues derived from my simulation setup?

Thank you!
Sergio

Regarding my previous post, I found an interesting presentation about fracture modeling from Dr. Cardiff. The fracture dynamics were modeled using the library FROGG, but it looks fairly similar to the fracture implementation in solids4foam (for the solid part at least). In this presentation the full solid-fluid interaction is modeled and it is able to resolve the cracked cells at the interface (unlike my simulation with solids4foam).

So my question is, is this FSI-Frature modelling posible within solids4foam; and if so, what are the limitations? (i.e. only unstructured grids, only mapping the pressure...)

Thank you!

tschenkel

September 23, 2020 04:22

solids4Foam on OF7 - GGI Mapping not implemented error

1 Attachment(s)

Hi,

I have successfully used solids4Foam on foam-extend 4.0, but now have converted all my own code to OpenFOAM 7 (mostly because it makes things easier for my undergraduates who find foam-extend a bit difficult).

Have compiled solids4Foam (master branch) successfully on OF7, and changed the tutorials (using the feature-tutorialsWorkWithOpenfoam branch and the convert script).

I have tested the 3dTube and the HronTurek examples.

Unfortunately the code stops with the error (full log attached).

Code:

Time = 0.001



Setting traction on solid interfaces





--> FOAM FATAL ERROR: 

Not implemented



    From function Not implemented for this version of OpenFOAM/FOAM

    in file fluidSolidInterfaces/fluidSolidInterface/interfaceToInterfaceMapping/ggiInterfaceToInterfaceMapping/ggiInterfaceToInterfaceMapping.C at line 212.



FOAM aborting

Not sure how I can solve this.

What is the status of the OF compatibility? Which branch to use for that?

Attachment 80311

bigphil

September 23, 2020 04:53

Hi Torsten,

You can use AMI or directMap instead of GGI; GGI is only in foam-extend and OpenFOAM has AMI.

Also, have a look at the following tutorial:

Code:

solids4foam-release/tutorials/fluidSolidInteraction/beamInCrossFlow/linearGeometryElasticBeam.openfoam

As regards the status of compatibility with OpenFOAM, the code compiles with many/most features and the next step is to update all tutorial i.e. complete the feature-tutorialsWorkWithOpenfoam branch work and merge into the development/master. As you know well, the change to online/blended-learning for Covid is making research more difficult!

Philip

tschenkel

September 23, 2020 05:57

Thanks a lot. Yes, I still hope to keep some research going, but teaching overheads are through the roof. At least I have a few undergrads doing stuff related to my research in the final year project, so I have an excuse ....

Detailed solution:

I was looking for the option to change from GGI, but couldn't find it (since the lines were not in the tutorials I looked at.

Adding the lines:

Code:

// Method for transferring information between the interfaces  



//interfaceTransferMethod directMap; 

 interfaceTransferMethod AMI; 

//interfaceTransferMethod RBF; 

//interfaceTransferMethod GGI;

to fsiProperties allows to select the transfer method on the interfaces.

(Taken from the tutorial that BigPhil referenced)

tschenkel

October 12, 2020 13:54

solids4Foam error in OF v1912 (AMI?)

Hi, I have tested the development branch on OF v1912, with the recent fix for the changes in meshObject::gravity.

The compilation works and my test case that runs on OF7 starts fine.

There are two issues:

1. the gravity file must be there, even though the code outputs that it initialises with zero since it's missing:

Code:

g field not found in constant directory: initialising to zero





--> FOAM FATAL ERROR: 

cannot find file "/home/acests3/OpenFOAM/acests3-7/run/3dTube/constant/g"



    From function virtual Foam::autoPtr<Foam::ISstream> Foam::fileOperations::uncollatedFileOperation::readStream(Foam::regIOobject&, const Foam::fileName&, const Foam::word&, bool) const

    in file global/fileOperations/uncollatedFileOperation/uncollatedFileOperation.C at line 548.



FOAM exiting

copying the g file from constant/solid to constant/ fixes this. But should the code not work even if the g file is not there? I didn't dare delving into the forest of if-statements in fluidModel.C, I have to admit ;-)

2. The AMI grid interpolations does not seem to work. On the OF7 compile the AMIInterpolation code is not replaces IIRC, for OF v1812 and v1912 it is. I need to test 1812, but in 1912, there seems to be a problem with a pointer in there:

Code:

Interpolating point values using AMI

zoneA point orientation (< 0), max: -0.999196, min: -1, nIncorrectPoints: 0/1701





--> FOAM FATAL ERROR: 

Cannot dereference nullptr at index 0 in range [0,1701)





    From function T& Foam::UPtrList<T>::operator[](Foam::label) [with T = Foam::Field<double>; Foam::label = int]

    in file /usr/lib/openfoam/openfoam1912/src/OpenFOAM/lnInclude/UPtrListI.H at line 221.



FOAM aborting



#0  Foam::error::printStack(Foam::Ostream&) at ./src/OSspecific/POSIX/printStack/printStack.C:239

#1  Foam::error::abort() at ??:?

#2  Foam::interfaceToInterfaceMappings::amiInterfaceToInterfaceMapping::calcZoneAPointWeights() const at ??:?

#3  Foam::interfaceToInterfaceMappings::amiInterfaceToInterfaceMapping::zoneAPointWeights() const at ??:?

#4  void Foam::interfaceToInterfaceMappings::amiInterfaceToInterfaceMapping::transferPointsZoneToZone<Foam::Vector<double> >(Foam::PrimitivePatch<Foam::face, Foam::List, Foam::Field<Foam::Vector<double> >, Foam::Vector<double> > const&, Foam::PrimitivePatch<Foam::face, Foam::List, Foam::Field<Foam::Vector<double> >, Foam::Vector<double> > const&, Foam::Field<Foam::Vector<double> > const&, Foam::Field<Foam::Vector<double> >&) const at ??:?

#5  Foam::fluidSolidInterface::updateResidual() at ??:?

#6  Foam::fluidSolidInterfaces::IQNILSCouplingInterface::evolve() at ??:?

#7  ? in ~/OpenFOAM/acests3-v1912/platforms/linux64GccDPInt32Opt/bin/solids4Foam

#8  __libc_start_main in /lib/x86_64-linux-gnu/libc.so.6

#9  ? in ~/OpenFOAM/acests3-v1912/platforms/linux64GccDPInt32Opt/bin/solids4Foam

Aborted (core dumped)

The case run fine so far with

Code:

interfaceTransferMethod RBF;

in constant/fsiProperties.

bigphil

October 12, 2020 17:14

Hi Torsten,

Thanks for these comments.

Regarding gravity, in v1912 they decided that gravity should always be looked up from the main case even if there are regions; I guess the argument is that gravity will be the same for all regions. It is actually the solid that is looking up the gravity field in this case. Copying (or soft linking) to solid/g is the easiest fix.

Regarding the problem with AMI, please create an issue on the bitbucket. Hopefully it is a simple fix.

Thanks,
Philip

tschenkel

October 12, 2020 19:04

Quote:

Originally Posted by bigphil (Post 785095)

Will create an issue on bitbucket. I know you have not yet ported to v2006, but there is another problem with AMI (AMI changed in 2006). I'll put that on bitbucket as well.

tschenkel

October 20, 2020 05:35

Relaxation methods not set?

Hello,

I am not sure since when this is the case, but on my systems, the relaxation method is being reported as "fixes" even if I select IQNILS or Aitken.

HTML Code:

Creating solidTraction boundary condition limiter coefficient: 1 under-relaxation method: fixed

fsiProperties has:

HTML Code:

fluidSolidInterface    IQNILS;  IQNILSCoeffs { // Solid interface patch and faceZone solidPatch         inner-wall; solidZone                   inner-wall-zone; // Fluid interface patch and faceZone fluidPatch         wall; fluidZone                   wall-zone; // Under-relaxation factor for passing the solid interface // displacement/velocity to the fluid interface // For fixedRelaxation, this value is used for all iterations // For Aitken, this value is used for the first iteration each time-step, // then it adaptively changes // For IQNILS, this value is used for the first two iterations each // time-step, then the IQNILS procedure is used relaxationFactor   0.005;

</div>

Not sure what's going on there.

Happens on fe40, fe41 and OF1912. It has happened for quite a while apparently, just checked some old cases. But I seem to remember that it used to report IQNILS changing the under-relaxation, but will need to dig through the archives.

This could explain why I'm struggling to vaildate the code against a 3-d flexible tube case.

bigphil

October 20, 2020 05:42

Hi Torsten,

The solidTraction boundary condition also has an optional under-relaxation factor. This is unrelated to the FSI under-relaxation method.

Philip

tschenkel

October 20, 2020 07:04

Quote:

Originally Posted by bigphil (Post 785596)

Hi Torsten,

The solidTraction boundary condition also has an optional under-relaxation factor. This is unrelated to the FSI under-relaxation method.

Philip

Thanks, I wondered if that was the case.

Am I imagining things when I believe to remember that the code used to report the FSI under-relaxation? I may be mistaken.

The drawback is that I now don't have an explanation why the deformation in my benchmark is only around 60% of the published values.

All times are GMT -4. The time now is 00:51.

Page 28 of 35

« First

Last »

Show 40 post(s) from this thread on one page