RBF(Mesh)MotionSolver in solids4foam
Hi Jon,
Just wondering: did you ever get RBFMeshMotionSolver to work with fsiFoam? I'm trying to use it with solids4foam (foam-extend-4.1, Ubuntu 18.04), and got the same error message you got (Problem with fluid mesh motion solver selection), both for RBFMeshMotionSolver and RBFMotionSolver. I came across a presentation by Željko Tuković, in which he uses RBFMeshMotionSolver with solids4foam, even combined with overset grid, so apparently it's possible to get it working, but it clearly doesn't work straight out of the box. Did you find a solution? Many thanks, Sita Quote:
|
Hi,
See commit bc08236 to the development branch of solids4foam: I added the following code to fluidSolidInterface.C: Code:
// Check for RBF motion solver Code:
dynamicFvMesh dynamicMotionSolverFvMesh; Philip |
Hi Philip,
Perfect, I'll have a look a that, thanks! Sita |
Hi Philip,
Sorry, just a quick question: can I build this development branch version next to the version that I already built from the master branch, or should I replace everything? Or would adding the code you mentioned to my master branch version, and re-building, work as well (i.e. without messing up my git clone)? Many thanks, Sita |
Hi Sita,
There are at least three ways you can do this:
All three of these are fine. Personally, I prefer option 1. Once I have checked all tutorial still run I will merge the change into the master branch anyway. Philip |
Hi Philip,
Thanks a lot for your quick reply, I'll go for the first option so. Sita |
Quote:
|
Hi Philip,
Great, that worked, the error "Problem with fluid mesh motion solver selection" is gone now. Unfortunately a new error popped up: Code:
Time = 0.001, iteration: 1 I'll try to run this beamInCrossFlow/linearGeometryElasticBeam tutorial first, see if I can work out how things work from there. Thanks, Sita EDIT: Woops, the beamInCrossFlow/linearGeometryElasticBeam tutorial gives me the exact same error... EDIT 2: Strange, the line of code that failed (the one with Pstream::myProcNo() ) should only be used in a parallel case (if ( Pstream::nProcs() > 1 ) ). I'm fairly sure I'm running the case in serial mode, as I haven't decomposed anything etc. |
Hi Sita,
Are you running the case in serial or in parallel? As noted in my previous post, parallel is currently not working: there is something wrong in the RBFMeshMotionSolver. Philip EDIT: I have checked the linearGeometryElasticBeam case in parallel on my Ubuntu box and it does work. I have realised there is a problem with openmpi on my mac (unrelated to solids4foam). Can you try clean and re-compile solids4foam (run "wclean lib && wmake libso" in src/solids4FoamModels)? And update to development commit 699223c first, where I included some example RBF settings. You need to enable the RBF motion in linearGeometryElasticBeam tutorial by changing the following lines in the fluid/dynamicMeshDict: Code:
solver velocityLaplacian; Code:
//solver velocityLaplacian; |
Hi Phil,
That's the thing, I actually am running the case in serial (on Ubuntu 18.04, with foam-extend-4.1), so I was really surprised that I got an error related to this "if nProc > 1" block. I already changed the dynamicMeshDict like you suggested in post #483, I'll try the cleaning and re-compiling too, tomorrow. Thanks for your help so far! Sita |
Hi Philip,
I just tried cleaning and re-compiling solids4foam, after updating to commit 699223, but I'm still getting the same error. As you wrote that for you the tutorial case now also works in parallel on Ubuntu, I'm starting to think that something might be wrong with my foam-extend-4.1 install (I had a good deal of trouble installing that, see also here (last page), and I'm still not sure whether everything's working as it should now). For now I'll try installing the pre-built binary of foam-extend-4.1, see if that helps. I read that the pre-built binary has some trouble with parallel cases in combination with the GAMG solver, but in fairness I'd be happy enough with just serial runs by now. Thanks, Sita EDIT: Too bad, with the foam-extend-4.1 pre-built binary it doesn't work either, still the same error... EDIT 2: Ah wait, sorry, the error isn't in this if-block; I missed a closing parenthesis. Still, can't figure out why exactly it failed; it seems the index in this for-loop (lines 653-660) doesn't reach nbGlobalStaticFaceCenters EDIT 3: Hm, commenting out those assert commands "solves" my problems for now. The results of the beamInCrossFlow/linearGeometryElasticBeam tutorial look alright, but this is not a permanent solution of course... |
Hi everyone,
I've two quick questions about solids4foam/RBFMeshMotion (foam-extend-4.1, Ubuntu 18.04.3): 1. Does anyone know how I'm supposed to add gravity to a solids4foam computation with RBFMeshMotion? There's a dictionary g in constant/solid, which works fine with other mesh motion solvers, such as velocityLaplacian, but when I use RBFMeshMotion, gravity seems to be ignored. Looking through the solver log file, I noticed: Code:
g field not found in constant directory: initialising to zero 2. Whenever I'm postprocessing solids4foam results in ParaView, it's complaining about duplicated entries: Code:
ERROR: In /build/paraview-lH8wFv/paraview-5.4.1+dfsg3/VTK/IO/Geometry/vtkOpenFOAMReader.cxx, line 7484 Thanks in advance, Sita |
Quote:
One other point to mention: I checked this case only with foam-extend-4.0; I did not check foam-extend-4.1. Maybe this may be the reason for the different behaviour. I can check with fe41 too. Philip |
Quote:
Feel free to upload a small test case here demonstrating the problem. Quote:
|
4 Attachment(s)
Hi Philip,
Thanks for getting back, sorry for the delay on my side. About the RBFMeshMotionSolver: I took another look at the results, and it looks like gravity is indeed included, but the fluid and the solid seem to be decoupled. I was messing around with the HronTurek tutorial as a testcase, changed the parameters to get the FSI1 case, and later on added gravity. When I use the velocityLaplacian solver, the results look alright (see attached plot, uA.png), but when I change to RBFMeshMotion, the solid seems to be deforming without affecting the flow (see attached image, RBF_seems_decoupled.png, and plot, uA_RBF.png). I'm also attaching my testcase, so if you have time you can take a look. I don't know, it's probably something really silly that I'm missing here, but I haven't found it yet. And about the ParaView warnings/errors: in my case the variables that cause those errors aren't loaded, I only get pointD0 etc. Is there a way to load these variables anyway? Many thanks, Sita |
Hi Sita,
Can you try removing the "frontAndBackPlanes" patch from the dynamicMeshDict/staticPatches dictionary? Best, Mikko |
Hi Mikko,
Sure, I can give that a try. Do you want me to remove it altogether, or to move it to e.g. fixedPatches? Do you happen to know the difference between staticPatches and fixedPatches, by the way? Is there a reason that removing frontAndBackPlanes from staticPatches should fix the fluid-solid coupling? I'll let you know how I get on, Sita EDIT: Cool, that actually seems to work! Thanks for the tip, can you explain it? |
Hi Sita,
To be honest, I do not know what is the difference between a static and a fixed patch. If a patch is either fixed or static then the nodes/cellCenters on that patch are not moving and therefore you were not getting any deformations for the 2D case. If you look at the example dynamicMeshDictionaries by the authors of the mesh deformation library, they seem to be also using both static and fixed patches for the 2D cases: cylinderFlap_FSI3 beamInCrossFlow2D Best, Mikko |
Hi Mikko,
Yeah, I noticed those tutorials, couldn't figure out the difference either though. I still don't quite get how my flexible plate was able to bend straight through the lower wall of my domain, but I'm glad everything is working as it should now. Thanks again, Sita |
Hi everyone,
I seem to be running into the same issue as Mike in post #436: as the deformation in my toy case (HronTurek FSI1 with gravity) is too large to be considered linear, I switched the solidModel in solidProperties from linearGeometryTotalDisplacement to unsNonLinearGeometryTotalLagrangian. This model wouldn't combine with the linearElastic material type in mechanicalProperties (as is indicated in Philip Cardiff's solids4foam training slides, but I tried anyway...), so I switched that to neoHookeanElastic. And so now I'm getting these warnings Code:
--> FOAM Warning : Many thanks, Sita |
All times are GMT -4. The time now is 07:11. |