[ngj]

Hi all

I am doing mesh motion using the laplaceFaceDecomposition method available in OF-1.5-dev. It is running without any problems in serial, however, when I decompose the case, the solver stalls on the very first encounter with mesh.update().

I have made the solver myself, so I used icoDyMFoam on the "movingConeMotion" tutorial, and the same behaviour is found for a decomposed case (2 processors).

My question is twofold: (i) Is it possible to use laplaceFaceDecomposition in parallel? (ii) If so, do I need to do something special to get the tet-solver to work?

Thank you very much for any help or suggestions

Niels

[hjasak]

I think you have hit a long-standing bug that I have fixed in 1.6-ext, the fix is coming your way.

Hrv

[ngj]

Hi Hrv

Thank you very much. Your help is most appreciated.

I do believe you already have my email address.

Best regards

Niels

[ngj]

Hi Hrv

Congratulations on the release of 1.6-ext (also to the rest of the ext-team). I have a question regarding the bug for laplaceFaceDecomposition. I am a bit reluctant to change version a couple of month before I turn in my thesis, hence:

Is the bug localised to a corner of OF, so I will be able to lift that part of the code back to version 1.5-dev?

I am looking forward to have time to use all the additions in the new release.

Best regards,

Niels

[hjasak]

Well, this was pretty major and I have been delaying it in 1.5-dev until the new release went out. You should have no problems with the new code and I would advise to upgrade.

Sorry for being imprecise,

Hrv

[abminternet]

Hi guys,

now that you are talking about it, I am trying to set up a case using the laplaceFaceDecomposition motion solver, and I don't really understand what "distancePatches" does. Any ideas you could share? Thanks,

regards,
Fredrich Muller

[ngj]

Hi Fredrich

It is those patches based on which the diffusivity of the mesh movement is computed, as the diffusivity is a function of the distance to a given patch/set of patches. E.g. quadratic diffusivity is

1 / lambda^2

where lambda is the distance to the given set of patches.

Best regards,

Niels

[abminternet]

oooohhh great, thanx for the response. One more question though, I have an old tutorial and it uses the componentMixed boundary condition in the motionU file, with the laplaceTetDecomposition motion solver. I am using OpenFOAM-1.6-ext and that solver is no longer available, so I am using laplaceFaceDecomposition, which sounds quite similar i guess. My question is, is the componentMixed bc still available? and how does it work? there are two more fields when specifying this condition, refValue and valueFraction. Any ideas as to what they are? Thanks a lot.

best regards,
Fredrich

[Daniele Trimarchi]

Hi,
sorry to insist, but I'm still quite in trouble for the mesh point motion, as in the previous post linked below:

Originally Posted by Daniele Trimarchi

FSI in OF

The thing is, I'm actually using OF 1.7.x and I can't access the pointMotion boundaryField, in order to assign directly the point mesh displacements. I'm actually obliged to do a inelegant interpolation on the structural displacement, in order to define average face motions.

Please help..!! : )

Thanks a lot, Daniele

[Peter_600]

I am also interested in the componentMixed boundary condition.
How to set it up in in the motionU file ?

Thx
Peter

[abminternet]

Hi Peter,

I found out how the mixed boundary condition works, it is just a mix between fixed value and fixed gradient. The refValue would be your fixed value, and valueFraction the proportion of fixedValue, and 1-valueFraction the proportion that corresponds to fixedGradient

[andrea.pasquali]

Hi,
I'm thinking to use RBF in OF 1.6-ext as morphing tool for optimization analysis.
I tried the tutorial movingBlockRBF. I can rotate and translate the block but I still haven't found how to morph the block surface with control points (for example increase the length or give a curvature).

Could anyone help me how to set the RBF for morphing or where I can find some examples?

Thanks in advance

Andrea

[jdiorio]

Originally Posted by Daniele Trimarchi

The thing is, I'm actually using OF 1.7.x and I can't access the pointMotion boundaryField, in order to assign directly the point mesh displacements. I'm actually obliged to do a inelegant interpolation on the structural displacement, in order to define average face motions.

I'm having a similar problem to Daniele. Trying to use OF 1.6 to do an oscillating wing. Using dynamicMotionSolverFVMesh, getting mesh motion using oscillating wall or timeVaryingFixedValue no problem. But if you want to access the pointMotionU boundaryField directly (say to make the velocity non-uniform along the moving patch, e.g. to add a rotation or in Daniele's case some custom deformation) - is it possible? For simple things (like oscillation and rotation) is better to use solidBodyMotionFvMesh? Using that I get the ENTIRE mesh to move - but I want just a single patch.

[jdiorio]

To add on - tried changing the pointField read by solidBodyMotionFvMesh to just be the points on the patch I want to move, i.e.

undisplacedPoints_
(
IOobject
(
"movingPatchPoints",
io.time().constant(),
meshSubDir,
*this,
IOobject::MUST_READ,
IOobject::NO_WRITE
)
)

where "movingPatchPoints" are the points only on the patch that I want to move. Motion starts but then chokes:

solidBodyMotionFunctions::SDA::transformation(): Time = 0.01 transformation: ((0 -0.248858 0) (1 (0 0 0)))


Cannot move points: size of given point list smaller than the number of active points#0 Foam::error:rintStack(Foam::Ostream&) in "/home/diorijd1/OpenFOAM/OpenFOAM-1.6/lib/linux64GccDPOpt/libOpenFOAM.so"

coming from primitiveMesh::movePoints due to the size inconsistency between movingPatchPoints and active points (which I'm guessing is all the mesh points). Any ideas on how to make an individual patch move?

[jdiorio]

Aha, I'm an idiot. Found the derived pointPatchField classes in the fvMotionSolvers folder - maybe I should actually try looking more closely in the future. Can use that as a guide. Daniele, you should be able to access the point velocities/displacements directly there to do what you want to do.

[Daniele Trimarchi]

Hi jdiorio, and thanks for your post. I'm looking at the derived class surfaceDisplacementPointPatchVectorField, as you suggested.

I should however admit to be quite confused. Could you please confirm if what I understand is true?

From my understanding, the basic idea is that in constant there is a (deformable) trisurface; the correspondent surface in the fluid mesh (defined via the member fnct: surfaces() ) will follow this.

In the case of the 'NEAREST' option, the connectivity is found searching for the closest point of the the two surfaces.

If a point of the fluidMesh has been found on the trisurface (by the function hit() ), the point displacement to be assigned to the fluid mesh is calculated then as the difference between the initial point location and the current location.

More in detail:

displacement[i] = nearest[i].hitPoint() - points0[meshPoints[i]];

where:

displacement[i] is the displacement to be assigned to the fluid mesh point. It has the size meshPoints.size()

nearest[i] comes from surfaces().findNearest(...) . findNearest(...) is member of the class 'SearchableSurface', and it is applied to the local member function surfaces(), which restitutes the pointer to the trisurface. I suppose the meaning of this is to search for the connectivity of the points between the fluidMesh surface and the trisurface? If this is true, for every fluidMesh point i, nearest[i] stores the index of the correspiondent node of the trisurface and it is member of the class LIST<PointIndexHit>

hitPoint() is a function of the class PointIndexHit and applied to nearest[i] returns the actual coordinates of the trisurface point(?)

points0[meshPoints[i]] returns the mesh initial point coordinates.

If all of that is true, I imagine that your advice is to modify directly this class and assign the displacements externally calculated to displacement[i]?

Thanks,
Daniele

[jdiorio]

Sorry Daniele but I'm not familiar enough with the mesh motion code to address your problem. The fix that worked for me was finding examples of derived boundary conditions (e.g. "oscillatingDisplacement", "angularOscillatingDisplacement", etc.) that can be applied to the "pointMotionU" or "pointDisplacement" files when using the displacementLaplacian or velocityLaplacian solvers. From there it was easy to modify to do say, and oscillation with a rotation. You're problem sounds a little more unique.

For others - is there something special that needs to be done to handle mesh motion near symmetry planes? I have a 3D grid (imported from StarCCM+) of an airfoil with the root mounted on a symmetry plane.
Trying to make the airfoil rotate about its center - not doing any flow solving just moving the mesh. Using displacementLaplacian solver and the angularOscillatingDisplacment condition on the foil. Works fine up until a certain time when the residuals start to get funky and code eventually crashes (see pic) and some ugly error:

#0 Foam::error:rintStack(Foam::Ostream&) in "/home/diorijd1/OpenFOAM/OpenFOAM-1.6/lib/linux64GccDPOpt/libOpenFOAM.so"
#1 Foam::sigFpe::sigFpeHandler(int) in "/home/diorijd1/OpenFOAM/OpenFOAM-1.6/lib/linux64GccDPOpt/libOpenFOAM.so"
#2 __restore_rt in "/lib64/tls/libc.so.6"
#3 void Foam::fvc::surfaceIntegrate<Foam::Vector<double> >(Foam::Field<Foam::Vector<double> >&, Foam::GeometricField<Foam::Vector<double>, Foam::fvsPatchField, Foam::surfaceMesh> const&) in "/home/diorijd1/OpenFOAM/OpenFOAM-1.6/lib/linux64GccDPOpt/libfiniteVolume.so"
#4 Foam::tmp<Foam::GeometricField<Foam::Vector<double >, Foam::fvPatchField, Foam::volMesh> > Foam::fvc::surfaceIntegrate<Foam::Vector<double> >(Foam::GeometricField<Foam::Vector<double>, Foam::fvsPatchField, Foam::surfaceMesh> const&) in "/home/diorijd1/OpenFOAM/OpenFOAM-1.6/lib/linux64GccDPOpt/libfiniteVolume.so"
#5 Foam::tmp<Foam::GeometricField<Foam::Vector<double >, Foam::fvPatchField, Foam::volMesh> > Foam::fvc::div<Foam::Vector<double> >(Foam::GeometricField<Foam::Vector<double>, Foam::fvsPatchField, Foam::surfaceMesh> const&) in "/home/diorijd1/OpenFOAM/OpenFOAM-1.6/lib/linux64GccDPOpt/libfiniteVolume.so"
#6 Foam::tmp<Foam::GeometricField<Foam::Vector<double >, Foam::fvPatchField, Foam::volMesh> > Foam::fvc::div<Foam::Vector<double> >(Foam::tmp<Foam::GeometricField<Foam::Vector<doub le>, Foam::fvsPatchField, Foam::surfaceMesh> > const&) in "/home/diorijd1/OpenFOAM/OpenFOAM-1.6/lib/linux64GccDPOpt/libfiniteVolume.so"
#7 Foam::fv::gaussLaplacianScheme<Foam::Vector<double >, double>::fvmLaplacian(Foam::GeometricField<double, Foam::fvsPatchField, Foam::surfaceMesh> const&, Foam::GeometricField<Foam::Vector<double>, Foam::fvPatchField, Foam::volMesh>&) in "/home/diorijd1/OpenFOAM/OpenFOAM-1.6/lib/linux64GccDPOpt/libfiniteVolume.so"
#8 Foam::tmp<Foam::fvMatrix<Foam::Vector<double> > > Foam::fvm::laplacian<Foam::Vector<double>, double>(Foam::GeometricField<double, Foam::fvsPatchField, Foam::surfaceMesh> const&, Foam::GeometricField<Foam::Vector<double>, Foam::fvPatchField, Foam::volMesh>&, Foam::word const&) in "/home/diorijd1/OpenFOAM/OpenFOAM-1.6/lib/linux64GccDPOpt/libfvMotionSolvers.so"
#9 Foam::tmp<Foam::fvMatrix<Foam::Vector<double> > > Foam::fvm::laplacian<Foam::Vector<double>, double>(Foam::tmp<Foam::GeometricField<double, Foam::fvsPatchField, Foam::surfaceMesh> > const&, Foam::GeometricField<Foam::Vector<double>, Foam::fvPatchField, Foam::volMesh>&, Foam::word const&) in "/home/diorijd1/OpenFOAM/OpenFOAM-1.6/lib/linux64GccDPOpt/libfvMotionSolvers.so"
#10 Foam::displacementLaplacianFvMotionSolver::solve() in "/home/diorijd1/OpenFOAM/OpenFOAM-1.6/lib/linux64GccDPOpt/libfvMotionSolvers.so"
#11 Foam::motionSolver::newPoints() in "/home/diorijd1/OpenFOAM/OpenFOAM-1.6/lib/linux64GccDPOpt/libdynamicMesh.so"
#12 Foam::dynamicMotionSolverFvMesh::update() in "/home/diorijd1/OpenFOAM/OpenFOAM-1.6/lib/linux64GccDPOpt/libdynamicFvMesh.so"
#13 main in "/home/diorijd1/OpenFOAM/diorijd1-1.6/applications/bin/linux64GccDPOpt/pimpleDyMFoamMesh"
#14 __libc_start_main in "/lib64/tls/libc.so.6"
#15 __gxx_personality_v0 in "/home/diorijd1/OpenFOAM/diorijd1-1.6/applications/bin/linux64GccDPOpt/pimpleDyMFoamMesh"
Floating point exception

Looking at the grid on the symmetry (bottom) plane near the leading edge of the foil at t=0 and t=0.12, looks like the mesh starts to "buckle". Happens rather suddenly, and mesh doesn't appear to be having too much trouble up until that point. Is this a boundary condition issue? Is the mesh deformation too great? Any thoughts?

[Daniele Trimarchi]

Hi Foamers,
I managed to sort out the problem of moving mesh points thanks to the precious help of Kassiotis. Here's the solution, I hope this will be useful.

1_Primarily some include are needed:

#include "pointMesh.H" //Perhaps not needed..?
#include "pointFields.H" //Perhaps not needed..?
#include "volPointInterpolation.H"

2_ Find the reference to the location of pointDisplacement field:

pointVectorField & PointDisplacement = const_cast<pointVectorField&>(mesh.objectRegistry: :lookupObject<pointVectorField>("pointDisplacement "));

3_ Find a reference to the moving interface:

word sail = coupling.lookup(Wing) //search in disctionary declared as 'coupling'
label fluidSideI = mesh.boundaryMesh().findPatchId(sail)
vectorField &pDisp=refCast<vectorField>(PointDisplacement.boun daryField()[fluidSideI]);

4_Find the relevant size of the vector and declare a vectorField. This will store the pointDisplacements values (in my case they come from the structural solver)

int Psize= pDisp.size();
vectorField dispVals(Psize);

5_ Once the values have been assigned to dispVals, assign them to cellDisplacement boundaryField

PointDisplacement.boundaryField()[ fluidSideI ] == dispVals;

6_ The mesh is updated via the motionSolver specified in dynamicMeshDict with

mesh.update();

7_ I observed a very triky thing, which gave me some headake in the last few days... I normally have in the time folder (let's say workdir/0) both files for pointDisplacements and cellDisplacements. When assiggning point movements THERE SHOULS BE NO cellDisplacement file. Otherwise the motionsolver does not affect, and the mesh displacement is not spread away (??!).

I normally apply those BC for the pointDisplacements:

> internalField uniform (0 0 0);
> boundaryField{
> Domain boundaries
> {
> type fixedValue;
> value uniform (0 0 0);
> }
> Moving Interface
> {
> type fixedValue;
> value nonuniform List<vector>
> 14 {(0 0 0)};
> }
> defaultFaces
> {
> type empty;
> }
> }

8_ This is not valid for cellDisplacements. In that case both cellDisplacements and pointDisplacements files are needed.

[Daniele111]

Hi all

I would coupling Openfoam with a my matlab code. With openfoam i resolved the flow around a terrain and it calculates tau on bottom surface, with it matlab code find the new bottom shape, Can I use move mesh openfoam capability to move mesh with matlab shape?

[wavemaster]

Hi Jdiorio,
I found the same problem in all OpenFOAM versions I am using....
Since it is a long time ago this question came up, did you find a solution?
Cheers,
Pal