[bigphil]

Originally Posted by night-hawk

Hi everyone,
I was trying to install solids4Foam in Openfoam v2012 . When I executed Allwmake script it ask to replace certain files. I just want to ask that if i replace those will it break original Openfoam functionality.

It should not break any existing functionality, however, I certainly understand your concern and am not a fan of this current "file replacement" solution.

For OpenFOAM-v*, there are currently two files replaced:

$FOAM_SRC/meshTools/AMIInterpolation/AMIInterpolation/AMIInterpolation.H
$FOAM_SRC/meshTools/AMIInterpolation/AMIInterpolation/AMIInterpolation.C

This change is required for FSI to run in parallel in solids4foam in OpenFOAM-v*.
If you don't need FSI in parallel, then you can ignore this change i.e. comment the following lines (add "#" at start if each line) in the main Allwmake script:

# Replace files in the main foam libraries                                                                                                                                                                   
(cd filesToReplaceInOF && ./Allcheck)
if [ $? -ne 0 ]
then
    echo "Please fix the filesToReplaceInOF above!"
    exit 1
fi

[treem22]

I'm attempting to simulate blood flow at the common carotid artery bifurcation and the corresponding artery wall deformation using solids4Foam. This is very similar to the 3dTube tutorial, except for the following differences:

• My sim has 1 inlet and 2 outlets instead of 1 inlet and 1 outlet
• My sim specifies a time-varying velocity inlet and time-varying static pressure outlet boundary conditions. My sim also uses pressureInletOutletVelocity conditions at the 2 outflows. The 3dTube case uses a time-varying pressure inlet condition with a totalPressure outlet condition. The inlets and outlets also use a fluxCorrectedVelocity condition.
• My simulation allows for time step adjustment based on Co = 1. The 3dTube tutorial cases specifies a constant deltaT (1e-4) that results in approximately 0.03 < max(Co) < 0.09.
• My simulation is employing CrankNicolson 0.5 for fluid/ddtSchemes. The 3dTube tutorial employs the backward fluid/ddtScheme.
• My simulation employs other fluid/fvSchemes that differ from the tutorial -- in general, my sim uses modest gradient limiters, slightly less than the corrected surface normal gradient discretization, and the gauss discretization cheme. The tutorial employs no direct gradient limiters, pure corrected surface normal gradient discretization, and least squares discretization (see attached fluid/fvSchemes from my sim). Please note that the solid/fvSchemes are the exact same for the two sims.
• My simulation uses non-newtonian fluid viscosities (BirdCarreau model)
• My simulation has slightly higher fluid density than the 3dTube case (1056 km/m3 vs 1000 kg/m3), but the solid material properties are the exact same.
• My simulation allows for 100 outer FSI loop correctors within each time step. The tutorial only allows for 30.

When I run my simulation, I generally wait for several time steps to begin coupling until the fluid solver has time to settle in on a consistent solution. I watch the min and max pressure and velocity values in the fluid domain as well as the total force on the fluid and solid interface values. When these converge to consistent values I assume it's okay to start the coupling process. I attached some plots comparing different interface convergence acceleration methods.

The interface forces plot is the magnitude of the fluid and solid interface force over the course of several coupling time steps. The FSI residuals plot is
a comparison of the FSI res1 and FSI res2 values from each iteration of several coupled time steps. The fixedRelaxation method seems to pretty clearly not achieve convergence in the number of outer loops I set (100). The IQNILS method in my simulation appears to behave similarly to how it behaved in the 3dTube tutorial. Some early time steps do not converge within the 100 coupling iterations, but the analysis appears to settle down after 10 or so time steps. The Aitken method, though, appears rather oscillatory and pretty unreliable. While generally trending toward a mean value, the oscillatory nature of the forces at the interface are so unpredictable that even if convergence is reached within the 100 FSI iterations the force value may not be reliably trusted. It's as if every 5 FSI iterations the Aitken method includes a routine that drastically changes its under-relaxation factor for fear that it's stuck in a local minimum (instead of finding the true global minimum). If on any given time step the coupling doesn't reach convergence, there is a decent likelihood that the time step ends on an iteration with one of these drastic under-relaxation values. On several occasions this had led to drastic deformations in my analysis that led to a crash.

Is there some Aitken under-relaxation parameter adjustment frequency parameter available that I can modify to reduce/eliminate this phenomenon?

I've tried the following:

• Adjusting solid grid size, fluid grid size, and the ratio of fluid grid size to solid grid size. It's always the grid, right?! Well, in this case, changing the grid seemed to have no effect
• Adjusting the Courant number. In reality, I have a very long physical time to analyze, so I only increased the max Courant number. I could get the sim to run further in physical time this way, but ultimately they all seem to crash if Aitken was employed
• Adjusting the max number of FSI iterations. This had some effect, but it appears only because it changed the iteration number at which the coupling convergence ended. Extending the max number of iterations as far out as 1000 never got rid of the oscillatory forces seen when using Aitken acceleration. No matter what, I eventually ended a time step on a drastic value and the sim crashed.
• Adding under-relaxation to the solid deformation field. I tried this once and it didn't effect much at all. It made the solid solver converge a bit slower, but it was pretty negligible. Still eventually found a crash if using Aitken.
• Adding solidTraction under-relaxation (relaxFac). This also appeared to have no impact on the solver's ability to avoid a crash. I didn't look too hard at how it affected the magnitude of the forces. This doesn't seem a common practice (it never appears in any FSI tutorial), so I promptly set it back to it's default value of 1

Has anyone else noticed this behavior with the Aitken method?

[EternalSeekerX]

Hello everyone,

Wanted to share a new finding. So I use linux on both my phone and small board computers sometimes (arm64/aarch64 archetecture) and I have run OpenFOAM 7, 8, 1912, 2012, 2106. I tried getting foam extend to compile for arm64 but foam-extend4.0 doesnt have any rules for aarch64, however foam-extend-4.1 does. So I compiled it and then compiled solids4foam with it. It works for this archetecture. Running elasticbeam tutorial as we speak. Only problem I ran into is that both libccimo and mesquite don't build because they don't have make rules for aarch64/arm64, so as long as you aren't using tools needing those third party package, you should be fine.

[night-hawk]

Originally Posted by bigphil

It should not break any existing functionality, however, I certainly understand your concern and am not a fan of this current "file replacement" solution.

For OpenFOAM-v*, there are currently two files replaced:

$FOAM_SRC/meshTools/AMIInterpolation/AMIInterpolation/AMIInterpolation.H
$FOAM_SRC/meshTools/AMIInterpolation/AMIInterpolation/AMIInterpolation.C

This change is required for FSI to run in parallel in solids4foam in OpenFOAM-v*.
If you don't need FSI in parallel, then you can ignore this change i.e. comment the following lines (add "#" at start if each line) in the main Allwmake script:

# Replace files in the main foam libraries                                                                                                                                                                   
(cd filesToReplaceInOF && ./Allcheck)
if [ $? -ne 0 ]
then
    echo "Please fix the filesToReplaceInOF above!"
    exit 1
fi

Sorry to ping you but it seems without replacing files solids4foam will not compile on openfoam v2012. I am attaching log files for your reference.

[bigphil]

Originally Posted by EternalSeekerX

Hello everyone,

Wanted to share a new finding. So I use linux on both my phone and small board computers sometimes (arm64/aarch64 archetecture) and I have run OpenFOAM 7, 8, 1912, 2012, 2106. I tried getting foam extend to compile for arm64 but foam-extend4.0 doesnt have any rules for aarch64, however foam-extend-4.1 does. So I compiled it and then compiled solids4foam with it. It works for this archetecture. Running elasticbeam tutorial as we speak. Only problem I ran into is that both libccimo and mesquite don't build because they don't have make rules for aarch64/arm64, so as long as you aren't using tools needing those third party package, you should be fine.

Nice, thanks for sharing.

Which compiler did you use?

I got a Mac with M1 arm chip earlier in the year and managed to get FE40 compiled using the default clang compiler (I also copied the wmake rules from somewhere).

Some related discussions here: https://www.linkedin.com/feed/update...44769193508864

[EternalSeekerX]

Originally Posted by bigphil

Nice, thanks for sharing.

Which compiler did you use?

I got a Mac with M1 arm chip earlier in the year and managed to get FE40 compiled using the default clang compiler (I also copied the wmake rules from somewhere).

Some related discussions here: https://www.linkedin.com/feed/update...44769193508864

Hey Phil, I just used Ubuntu gcc-7 to compile FE41 and solids4Foam. I can't seem to access the linked in post, says cannot be displayed. Have you ran into issues with libccmio and mesquite not building for FE40? I checked their respective github and they do not have arm64 builds at all. If you successfully build them, would love if you share how you did so. Are you saying clang built those fine?

[bigphil]

Originally Posted by EternalSeekerX

Hey Phil, I just used Ubuntu gcc-7 to compile FE41 and solids4Foam. I can't seem to access the linked in post, says cannot be displayed. Have you ran into issues with libccmio and mesquite not building for FE40? I checked their respective github and they do not have arm64 builds at all. If you successfully build them, would love if you share how you did so. Are you saying clang built those fine?

For the link, apologies, it seems that it can only be accessed be LinkedIn users who are members of the public OpenFOAM group; if you have a LinkedIn account, it is easy to join: https://www.linkedin.com/groups/1920608/.
However, if not, it is basically a short thread about experience compiling different versions of OpenFOAM on arm.

For mesquite and libccmio, no, I did not compile/install them in my m1 clang installation. Anything I didn't need, I just ignored :O

[treem22]

Originally Posted by treem22

Is there some Aitken under-relaxation parameter adjustment frequency parameter available that I can modify to reduce/eliminate this phenomenon?

I went ahead and implemented a relaxationFactorMax parameter defined in constant/fsiProperties that will redefine the Aitken under-relaxation parameter to relaxationFactorMax if the Aitken algorithm suggests that it should exceed relaxationFactorMax. The default relaxationFactorMax value is 1.0, so if it is left unassigned no behavior changes.

[bigphil]

Originally Posted by treem22

I went ahead and implemented a relaxationFactorMax parameter defined in constant/fsiProperties that will redefine the Aitken under-relaxation parameter to relaxationFactorMax if the Aitken algorithm suggests that it should exceed relaxationFactorMax. The default relaxationFactorMax value is 1.0, so if it is left unassigned no behavior changes.

Interesting.

Did you find that it helps in some cases?

if so, I am happy to merge it.

Philip

[treem22]

Originally Posted by bigphil

Interesting.

Did you find that it helps in some cases?

if so, I am happy to merge it.

Philip

See response here: https://bitbucket.org/philip_cardiff...axation-factor

[Hgholami]

Hi
I look at coupledUnsLinGeomLinearElasticSolid of solids4Foam recently. This solid model is seen work only in serial. For parallel running using mpirun, it have "FOAM FATAL ERROR" in HashTableI.H
with banana test, the problem show appear in

// We manually add the boundary conditions equations
// More thinking is required to get it to fit cleanly with the rest of
// the block coupled machinery
extendedMesh_.insertBoundaryConditions
(
blockM, blockB, muf_, lambdaf_, D()
);

did any foamer this same problem?
Thanks

Hojatollah

[bigphil]

Originally Posted by Hgholami

Hi
I look at coupledUnsLinGeomLinearElasticSolid of solids4Foam recently. This solid model is seen work only in serial. For parallel running using mpirun, it have "FOAM FATAL ERROR" in HashTableI.H
with banana test, the problem show appear in

did any foamer this same problem?
Thanks

Hojatollah

foam-extend-4.0 or foam-extend-4.1?

It runs in parallel for me with foam-extend-4.0, although the linear solver convergence is currently poor, so there might not currently be any benefit to running this in parallel... although these block coupled approaches are an active area of research for me so I expect to push improvements in the coming year(s).

[Hgholami]

Dear Philip
I use foam-extend 4.0, with master branch of solids4Foam. I check the tutorial coupledPlateHole that work parallel, but for coupledCantilever2D is have problem with parallel

SpareLU direct linear solver may not be run in parallel

that due to fvsolution direct solver "EigenSparseLU", that work correctly with iterative solver BICGStab.
So, the problem of HashTable.H comes from my case, and I should check my geometry.
thanks

[bigphil]

Originally Posted by Hgholami

Dear Philip
I use foam-extend 4.0, with master branch of solids4Foam. I check the tutorial coupledPlateHole that work parallel, but for coupledCantilever2D is have problem with parallel

that due to fvsolution direct solver "EigenSparseLU", that work correctly with iterative solver BICGStab.
So, the problem of HashTable.H comes from my case, and I should check my geometry.
thanks

OK, so the HashTable.H error only appears on your test case?
I suggest checking checkMesh for any errors in your mesh definition. Then also check if the case runs fine with some of the other solids4foam solid models (e.g. linGeomTotalDisplSolid).
Then you could "diff" the cases to try find the difference. And failing that you try locate the source of this error with a debugger e.g. gdb.

[Hgholami]

Dear foamer
For foam-extend4.1, overset with pimpleOversetFluid of fluid model, I use tutorial beamInCrossFlow/overset. For serial running, the solve is OK, but for parallel with default setting of decomposeDict, the running failed. the problem occurs after checking dynamic mesh. did anyone engage with this problem and how solved it?
Thanks

[bigphil]

Originally Posted by Hgholami

Dear foamer
For foam-extend4.1, overset with pimpleOversetFluid of fluid model, I use tutorial beamInCrossFlow/overset. For serial running, the solve is OK, but for parallel with default setting of decomposeDict, the running failed. the problem occurs after checking dynamic mesh. did anyone engage with this problem and how solved it?
Thanks

For reference, the problem is reported here https://bitbucket.org/philip_cardiff...do-not-work-in. No solution yet.

[Neb]

Originally Posted by ilhado

Hello!

I have successfully compiled solids4foam before with foam-extend-4.1. However, I tried again in a new machine yesterday and it did not completely compile due to the following error:



The weird part is that this error appears a lot in the log, but as a warning only (I attached the log file). Did this also happen with anyone?

I tried in Ubuntu 16.04 and Ubuntu 18.04, with foam-extend-4.1.

Thanks a lot,
Iago

Hi,
have you solved this problem? I'm desperate.
thank you

[bigphil]

Originally Posted by Neb

Hi,
have you solved this problem? I'm desperate.
thank you

What compilation error do you get?
You can attach the log from the the Allwmake command:

$> ./Allwmake &> log.Allwmake &

[Neb]

Hi,
I am installing the FSI foam extend 4.1 toolkit on Ubuntu 18.04. I have already fixed many bugs and used the gcc-5 compiler. Now I have last errors.
I would be very grateful for your help!

[Neb]

Sorry, no idea for this error?





I/home/simona/foam/foam-extend-4.1/src/foam/lnInclude -I/home/simona/foam/foam-extend-4.1/src/OSspecific/POSIX/lnInclude -fPIC -c $SOURCE -o Make/linux64GccDPInt32Opt/timeVaryingCoulomb.o
In file included from /home/simona/foam/foam-extend-4.1/src/foam/lnInclude/interpolationTable.H:184:0,
from solidSolvers/solidModels/fvPatchFields/solidContact/contactModels/frictionContactModels/frictionLaws/timeVaryingCoulomb/timeVaryingCoulomb.H:45,
from solidSolvers/solidModels/fvPatchFields/solidContact/contactModels/frictionContactModels/frictionLaws/timeVaryingCoulomb/timeVaryingCoulomb.C:26:
/home/simona/foam/foam-extend-4.1/src/foam/lnInclude/interpolationTable.C: In member function ‘Type Foam::interpolationTable<Type>::rateOfChange(Foam: :scalar) const’:
/home/simona/foam/foam-extend-4.1/src/foam/lnInclude/interpolationTable.C:276:17: error: attributes at the beginning of statement are ignored [-Werror=attributes]
[[fallthrough]];
^
/home/simona/foam/foam-extend-4.1/src/foam/lnInclude/interpolationTable.C:310:17: error: attributes at the beginning of statement are ignored [-Werror=attributes]
[[fallthrough]];
^
/home/simona/foam/foam-extend-4.1/src/foam/lnInclude/interpolationTable.C: In member function ‘const Foam::Tuple2<double, Type>& Foam::interpolationTable<Type>:perator[](Foam::label) const’:
/home/simona/foam/foam-extend-4.1/src/foam/lnInclude/interpolationTable.C:420:17: error: attributes at the beginning of statement are ignored [-Werror=attributes]
[[fallthrough]];
^
/home/simona/foam/foam-extend-4.1/src/foam/lnInclude/interpolationTable.C:455:17: error: attributes at the beginning of statement are ignored [-Werror=attributes]
[[fallthrough]];
^
/home/simona/foam/foam-extend-4.1/src/foam/lnInclude/interpolationTable.C: In member function ‘Type Foam::interpolationTable<Type>:perator()(Foam::s calar) const’:
/home/simona/foam/foam-extend-4.1/src/foam/lnInclude/interpolationTable.C:509:17: error: attributes at the beginning of statement are ignored [-Werror=attributes]
[[fallthrough]];
^
/home/simona/foam/foam-extend-4.1/src/foam/lnInclude/interpolationTable.C:543:17: error: attributes at the beginning of statement are ignored [-Werror=attributes]
[[fallthrough]];
^
cc1plus: all warnings being treated as errors
solidSolvers/solidModels/fvPatchFields/solidContact/contactModels/frictionContactModels/frictionLaws/timeVaryingCoulomb/timeVaryingCoulomb.dep:544: recipe for target 'Make/linux64GccDPInt32Opt/timeVaryingCoulomb.o' failed
make: *** [Make/linux64GccDPInt32Opt/timeVaryingCoulomb.o] Error 1
+ wmake solvers/fsiFoam
Making dependency list for source file fsiFoam.C
SOURCE=fsiFoam.C ; g++ -std=c++11 -m64 -Dlinux64 -DWM_ARCH_OPTION=64 -DWM_DP -DWM_LABEL_SIZE=32 -Wno-deprecated -Wall -Wextra -Wno-unused-parameter -Wnon-virtual-dtor -Wunused-local-typedefs -Werror -Wredundant-decls -Wcast-align -Wmissing-declarations -Wswitch-enum -Winvalid-pch -Wredundant-decls -Wformat=2 -Wmissing-format-attribute -Wformat-nonliteral -O3 -DNoRepository -ftemplate-depth-200 -std=c++11 -I../../fluidSolidInteraction/lnInclude -I../../ThirdParty/eigen3 -I/home/simona/foam/foam-extend-4.1/src/finiteVolume/lnInclude -I/home/simona/foam/foam-extend-4.1/src/dynamicMesh/dynamicFvMesh/lnInclude -I/home/simona/foam/foam-extend-4.1/src/meshTools/lnInclude -I/home/simona/foam/foam-extend-4.1/src/tetFiniteElement/lnInclude -IlnInclude -I. -I/home/simona/foam/foam-extend-4.1/src/foam/lnInclude -I/home/simona/foam/foam-extend-4.1/src/OSspecific/POSIX/lnInclude -fPIC -c $SOURCE -o Make/linux64GccDPInt32Opt/fsiFoam.o
g++ -std=c++11 -m64 -Dlinux64 -DWM_ARCH_OPTION=64 -DWM_DP -DWM_LABEL_SIZE=32 -Wno-deprecated -Wall -Wextra -Wno-unused-parameter -Wnon-virtual-dtor -Wunused-local-typedefs -Werror -Wredundant-decls -Wcast-align -Wmissing-declarations -Wswitch-enum -Winvalid-pch -Wredundant-decls -Wformat=2 -Wmissing-format-attribute -Wformat-nonliteral -O3 -DNoRepository -ftemplate-depth-200 -std=c++11 -I../../fluidSolidInteraction/lnInclude -I../../ThirdParty/eigen3 -I/home/simona/foam/foam-extend-4.1/src/finiteVolume/lnInclude -I/home/simona/foam/foam-extend-4.1/src/dynamicMesh/dynamicFvMesh/lnInclude -I/home/simona/foam/foam-extend-4.1/src/meshTools/lnInclude -I/home/simona/foam/foam-extend-4.1/src/tetFiniteElement/lnInclude -IlnInclude -I. -I/home/simona/foam/foam-extend-4.1/src/foam/lnInclude -I/home/simona/foam/foam-extend-4.1/src/OSspecific/POSIX/lnInclude -fPIC -Xlinker --add-needed -Xlinker --no-as-needed Make/linux64GccDPInt32Opt/fsiFoam.o -L/home/simona/foam/foam-extend-4.1/lib/linux64GccDPInt32Opt \
-lfiniteVolume -lincompressibleTurbulenceModel -lincompressibleRASModels -lincompressibleLESModels -lincompressibleTransportModels -ldynamicFvMesh -ldynamicMesh -lmeshTools -L/home/simona/foam/simona-4.1/lib/linux64GccDPInt32Opt -lfluidSolidInteraction -lfoam -ldl -lrt -lm -o /home/simona/foam/simona-4.1/applications/bin/linux64GccDPInt32Opt/fsiFoam
/usr/bin/ld: impossibile trovare -lfluidSolidInteraction
collect2: error: ld returned 1 exit status
/home/simona/foam/foam-extend-4.1/wmake/Makefile:159: recipe for target '/home/simona/foam/simona-4.1/applications/bin/linux64GccDPInt32Opt/fsiFoam' failed
make: *** [/home/simona/foam/simona-4.1/applications/bin/linux64GccDPInt32Opt/fsiFoam] Error 1