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 Tree122Likes

Reply
 
LinkBack Thread Tools Search this Thread Display Modes
Old   August 24, 2021, 07:51
Default
  #621
Super Moderator
 
bigphil's Avatar
 
Philip Cardiff
Join Date: Mar 2009
Location: Dublin, Ireland
Posts: 973
Rep Power: 30
bigphil will become famous soon enoughbigphil will become famous soon enough
Quote:
Originally Posted by night-hawk View Post
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:
Code:
$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:
Code:
# Replace files in the main foam libraries                                                                                                                                                                   
(cd filesToReplaceInOF && ./Allcheck)
if [ $? -ne 0 ]
then
    echo "Please fix the filesToReplaceInOF above!"
    exit 1
fi
night-hawk likes this.
bigphil is offline   Reply With Quote

Old   September 3, 2021, 18:41
Default FSI in Carotid Bifurcation - What's up with Aitken acceleration?
  #622
Member
 
Mike Tree
Join Date: Feb 2016
Location: Charlotte, NC
Posts: 34
Rep Power: 7
treem22 is on a distinguished road
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?
Attached Images
File Type: jpg InterfaceForces.jpg (100.8 KB, 11 views)
File Type: jpg FSIresiduals.jpg (126.1 KB, 4 views)
treem22 is offline   Reply With Quote

Old   September 11, 2021, 03:19
Default So I was able to build Solids4Foam and Foam-Extend-4.1 on aarch64 (arm64)
  #623
Senior Member
 
Sultan Islam
Join Date: Dec 2015
Location: Canada
Posts: 115
Rep Power: 8
EternalSeekerX is on a distinguished road
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.
bigphil likes this.
EternalSeekerX is offline   Reply With Quote

Old   September 11, 2021, 04:39
Default
  #624
Member
 
Ashutosh
Join Date: Jul 2021
Location: India
Posts: 36
Rep Power: 2
night-hawk is on a distinguished road
Quote:
Originally Posted by bigphil View Post
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:
Code:
$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:
Code:
# 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.
Attached Files
File Type: zip error.zip (13.3 KB, 0 views)
night-hawk is offline   Reply With Quote

Old   September 13, 2021, 07:23
Default
  #625
Super Moderator
 
bigphil's Avatar
 
Philip Cardiff
Join Date: Mar 2009
Location: Dublin, Ireland
Posts: 973
Rep Power: 30
bigphil will become famous soon enoughbigphil will become famous soon enough
Quote:
Originally Posted by EternalSeekerX View Post
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
bigphil is offline   Reply With Quote

Old   September 13, 2021, 14:58
Default Nice
  #626
Senior Member
 
Sultan Islam
Join Date: Dec 2015
Location: Canada
Posts: 115
Rep Power: 8
EternalSeekerX is on a distinguished road
Quote:
Originally Posted by bigphil View Post
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?
EternalSeekerX is offline   Reply With Quote

Old   September 13, 2021, 16:17
Default
  #627
Super Moderator
 
bigphil's Avatar
 
Philip Cardiff
Join Date: Mar 2009
Location: Dublin, Ireland
Posts: 973
Rep Power: 30
bigphil will become famous soon enoughbigphil will become famous soon enough
Quote:
Originally Posted by EternalSeekerX View Post
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
bigphil is offline   Reply With Quote

Old   September 30, 2021, 15:31
Default
  #628
Member
 
Mike Tree
Join Date: Feb 2016
Location: Charlotte, NC
Posts: 34
Rep Power: 7
treem22 is on a distinguished road
Quote:
Originally Posted by treem22 View Post
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.
Attached Files
File Type: h AitkenCouplingInterface.H (3.4 KB, 0 views)
File Type: c AitkenCouplingInterface.C (7.7 KB, 0 views)
treem22 is offline   Reply With Quote

Old   October 1, 2021, 11:11
Default
  #629
Super Moderator
 
bigphil's Avatar
 
Philip Cardiff
Join Date: Mar 2009
Location: Dublin, Ireland
Posts: 973
Rep Power: 30
bigphil will become famous soon enoughbigphil will become famous soon enough
Quote:
Originally Posted by treem22 View Post
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
bigphil is offline   Reply With Quote

Old   October 1, 2021, 20:02
Default
  #630
Member
 
Mike Tree
Join Date: Feb 2016
Location: Charlotte, NC
Posts: 34
Rep Power: 7
treem22 is on a distinguished road
Quote:
Originally Posted by bigphil View Post
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
bigphil likes this.
treem22 is offline   Reply With Quote

Old   November 26, 2021, 01:58
Default problem in coupled solid solver in parallel
  #631
Senior Member
 
Hojatollah Gholami
Join Date: Jan 2019
Posts: 157
Rep Power: 5
Hgholami is on a distinguished road
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
Quote:
// 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
Hgholami is offline   Reply With Quote

Old   November 26, 2021, 13:27
Default
  #632
Super Moderator
 
bigphil's Avatar
 
Philip Cardiff
Join Date: Mar 2009
Location: Dublin, Ireland
Posts: 973
Rep Power: 30
bigphil will become famous soon enoughbigphil will become famous soon enough
Quote:
Originally Posted by Hgholami View Post
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).
bigphil is offline   Reply With Quote

Old   November 27, 2021, 03:45
Default
  #633
Senior Member
 
Hojatollah Gholami
Join Date: Jan 2019
Posts: 157
Rep Power: 5
Hgholami is on a distinguished road
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
Quote:
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
Hgholami is offline   Reply With Quote

Old   November 29, 2021, 17:00
Default
  #634
Super Moderator
 
bigphil's Avatar
 
Philip Cardiff
Join Date: Mar 2009
Location: Dublin, Ireland
Posts: 973
Rep Power: 30
bigphil will become famous soon enoughbigphil will become famous soon enough
Quote:
Originally Posted by Hgholami View Post
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.
bigphil is offline   Reply With Quote

Old   December 30, 2021, 05:35
Default overset parallel running problem
  #635
Senior Member
 
Hojatollah Gholami
Join Date: Jan 2019
Posts: 157
Rep Power: 5
Hgholami is on a distinguished road
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
Hgholami is offline   Reply With Quote

Old   January 11, 2022, 12:50
Default
  #636
Super Moderator
 
bigphil's Avatar
 
Philip Cardiff
Join Date: Mar 2009
Location: Dublin, Ireland
Posts: 973
Rep Power: 30
bigphil will become famous soon enoughbigphil will become famous soon enough
Quote:
Originally Posted by Hgholami View Post
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.
Hgholami likes this.
bigphil is offline   Reply With Quote

Old   January 20, 2022, 11:11
Default
  #637
Neb
Member
 
Join Date: Mar 2020
Posts: 39
Rep Power: 3
Neb is on a distinguished road
Quote:
Originally Posted by ilhado View Post
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
Neb is offline   Reply With Quote

Old   January 20, 2022, 11:23
Default
  #638
Super Moderator
 
bigphil's Avatar
 
Philip Cardiff
Join Date: Mar 2009
Location: Dublin, Ireland
Posts: 973
Rep Power: 30
bigphil will become famous soon enoughbigphil will become famous soon enough
Quote:
Originally Posted by Neb View Post
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:
Code:
$> ./Allwmake &> log.Allwmake &
bigphil is offline   Reply With Quote

Old   January 21, 2022, 05:46
Default
  #639
Neb
Member
 
Join Date: Mar 2020
Posts: 39
Rep Power: 3
Neb is on a distinguished road
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!
Attached Files
File Type: txt log_Allwmake.txt (21.7 KB, 2 views)
Neb is offline   Reply With Quote

Old   January 24, 2022, 11:11
Default
  #640
Neb
Member
 
Join Date: Mar 2020
Posts: 39
Rep Power: 3
Neb is on a distinguished road
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
Neb is offline   Reply With Quote

Reply

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 36 March 29, 2017 09:05
[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 13:34.