[sita]

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]

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]

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]

Thanks,

What are the loading conditions?

Philip

[sita]

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]

Hi Sita,

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

Philip

[sita]

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]

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:

1. Use conventional symmetry planes at the top-left and bottom-right;
2. 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]

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]

Brilliant, addTinyPatch works like a charm, thanks again!

[serfriz]

Originally Posted by serfriz

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:

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]

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

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?



solids4Foam.log.txt

[bigphil]

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:

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]

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:

// 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]

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:

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:

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

interfaceTransferMethod RBF;

in constant/fsiProperties.

[bigphil]

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]

Originally Posted by bigphil

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

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]

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.

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

fsiProperties has:

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]

Hi Torsten,

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

Philip

[tschenkel]

Originally Posted by bigphil

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.