[ngj]

Hi Albert,

I have never seen NaN in OpenFoam before, so I have no clue on how to proceed.
Can you solve simple, incompressible, steady state flows in your domain? I heavily suspect the mesh to be corrupted in one way or the other. You are actually the second guy in this thread within a week having problems with meshes imported from Gambit.

Kind regards

Niels

[kilroy]

Niels,

I am working on to modify the standard "wigley hull" tutorial that comes with OpenFOAM in such a way that the hull will be under the effect of waves. I have successfully managed to do that when the speed of the water and the wave directions are the same and I am getting very good results.

But now I want to define the speed of the water in x-direction and the wave direction making 45 degrees with the x-axis. I am trying to simulate the condition when the ship is traveling with a constant speed (speed of the water) and cutting the waves with 45 degrees.

Can I accomplish that by using "waves2Foam" toolbox?
And what would be the best modeling strategy (changing the shape of the computational domain and adding new patches, etc.)?

Can you please give me some suggestions?

Thanks,

[mr-albert]

Hi Niles
thank you so mush i try it with other meshing software

mr-albert

[ngj]

Hi Kilroy,

I have never thought about such a setup, and I do not know how you should go about it.

It is nice that you get good results with co-directional waves, so please share your experiences here with the more complex setup.

Kind regards

Niels

Edit 2013.05.17, 12:15: Of course you have to carefully choose the correct current, which gives you a steady ship in the computational domain. The waves will then have to be super-imposed on these waves. Neglecting the sideways drift of the ship due to the current, this current field should be fairly easy to "derive".

[kilroy]

Niels,

I thought that maybe I can simulate the movement of the hull by moving its mesh. So, I decided to look into the movingCone tutorial.

I have just gone through it and I can see that, as the object moves to the right side, mesh on the right side is contracting and the mesh on the left side of the object is expanding. Please see the pictures attached (movingCone_initial.png and movingCone_last.png)

movingCone_initial.jpg

movingCone_last.jpg


After that, I tried to apply the same principles to a hull traveling through calm water making a 45 degree angle with the waves. I want to make the hull move 4 times of its length, but my run crashes a little bit after the start. I think that is because the distortion of the mesh. Please see the pictures attached (ship_initial and ship_last)

ship_initial.jpg

ship_last.jpg


Do you know if there is a way to overcome that distortion problem? (Like updating and recreating the mesh in each step).

Or should I try a completely different method?


Thank you very much for your help in advance,

Kilroy

[ngj]

Hi Kilroy,

I do not think that you will be successful in actually moving the mesh, unless you apply some sliding of the mesh lines on/off the hull as it progress through the computational domain. This calls for topological changes (which are supported in waves2Foam, by the way). This will probably be some work from your side, as I do not think that the existing methods will be directly applicable.

A completely different approach would be mesh overlay, where you have a ship mesh moving in a static background mesh, however, to my knowledge this is still closed source for OF. The only version that I have seen was shown in a presentation at the Gothenburg conference.

Another thing is the additional amount of computational cells, since your domain will then have to be somewhat larger than 4 times the ship length, which will be a considerable extension compared to your present 1 ship plus relaxation zones.

Kind regards

Niels

[sophie_l]

Hi Niels,

I am simulating a steady current case in an open channel. Currently, I am using waveVelocity to generate a uniform velocity inlet, however, the logarithmic profile in the domain is under-developed. I am just wondering can wave2foam generate a logarithmic velocity profile at the inlet?

Many thanks in advance.

Sophie

[ngj]

Hi Sophie,

Yes, it should be possible to make a logarithmic velocity profile, but it requires that you implement it yourself.

Have a look in the source code at

waves2Foam/src/waveTheories/current/potentialCurrent

and you will see that it is exceptionally easy to extend the code with such a velocity profile.

Kind regards

Niels

[luigi21]

I want to know if there's another utility to plot surface elevation for 3D meshes, or another way to extract the variables (x,y,z,eta) in all the points of the 3D mesh for plotting.

[winden]

Hi Niels.

Sorry for bothering you, I know this has been up for discussion before. I'm using quite an old version of waves2Foam and it doesn't do well with point motions within the relaxation zones (solver just freezes on relaxing.correct) I believe you said this was fixed in newer versions but I'm reluctant to upgrade since I have modified stuff and I don't like to fix things that are working in every other aspect. Do you remember what part of the code is troubled by point/cell motions in the relaxation zones?

Alternatively, I think it would be ideal to actually keep point motion at zero in the relaxation zones to improve accuracy. I have experimented a bit with custom motionDiffusivity classes to achieve this with moderate success. I can greatly reduce the point motion inside the relaxation zones but some motion always "leaks" in for some reason. Is this something you have experimented with as well?

//Björn

[ngj]

Hi Björn,

What I fixed was related to topological changes, i.e. a change in the number of computational cells originating from e.g. mesh refinement. I do not believe that I have changed anything related to point motion in the relaxation zones; actually I always try to eliminate that, though since I specify motions at the bed and only have vertical movement, it is fairly easy for me.

I am interested in knowing the reason for the freeze of the relaxation.correct(). Do your cells become severely distorted/non-convex during the mesh motion?

What are your changes? Are they of common interest? Once the SVN is running again we could discuss, if you should contribute in order to bring you (latest version) and all the rest of us (new functionality) a step ahead.

I do not believe you can avoid mesh motion in the relaxation zone through the mesh diffusivity, I would rather suggest that you simply remove those points/cells from the mesh motion matrix.

Kind regards

Niels

[winden]

Hi.

That is probably why I couldn't find anything when I searched the forum, I must have remembered wrongly.

I have unsuccessfully tried to narrow down the reason for freezing. The cells are not distorting much. The distortion is hardly visible in the relaxation zones since they are far away from the moving object. Nevertheless as soon as some distortion reaches the region, the solver freezes (no FPe or anything, it just stops responding.) If I comment out relaxing.correct, it all works fine and equally, if I turn off the mesh motion. I might try to pick out the points in the relaxation region from the motion matrix as you suggest. It should work but I'm not sure how to do it practically.

As for my changes: not really of common interest I think, they are quite old. Just things that I have stuck with since the first release of waves2Foam. For example, one of them is implementing the "air velocity" which you already released ages ago. I should probably just update and it would out-date most of them. I just don't like messing with things that work

The only ones that are unique for me are relating to linking the waves2Foam libraries with a custom self propulsion library and solver. Whenever that is working properly I will definitely release it but that is not in the near future I fear.

//Björn

[ngj]

Hi Björn,

It makes sense to stick with things, which are actually working

With respect to the mesh motion solver, could you elaborate on which type of class you are using. Cell based or tetFem based?

Kind regards

Niels

P.S. When the propulsion library become mature enough and if it fits inside waves2Foam, I will gladly include it.

[winden]

Hi Niels.

I am using cell based displacementLaplacian.

//Björn

[ngj]

Hi Björn,

Then it is "quite" easy, even though there will be some tweaking of the source code, both OF and waves2Foam.

What you will need to do is to make a new class, which to begin with is merely a copy of your mesh motion method. Then, in some way or the other find all cells in all relaxation zones from inside the mesh motion method [1].

Somewhere in the mesh motion technique, there will be a point, where you construct the matrix system. After this step and before solving for the mesh motion, you prescribe a fixed displacement of (0 0 0) in all the cells in all relaxation zones. You do this by invoking the command:

<vectorEqnName>.setValues( cellList, vectorField );

This will then enforce the motion to be zero inside the relaxation zones and the inner limit to the relaxation zones will begin to work as pseudo boundaries.

Kind regards

Niels

[1]: This is not straight forward, since relaxationZone is not registered in the database, but inspired by your question I will see, if I can find the time to make in happen.

[winden]

Hi Niels.

Thanks for the tips. The wave dictionary should be accessible through the mesh object registry and the points in the relaxation zones could be picked out from there.

IOdictionary waveDict
    (
        IOobject
        (
            "waveProperties",
            mesh.thisDb().parent().time().constant(),
            mesh.thisDb().parent().db(),
            IOobject::MUST_READ,
            IOobject::NO_WRITE,
            false
        )
    );

That is how I accessed it in my custom motion diffusion model. Of course it would be easier if they were just saved as point/cell/face zones or something. Speaking of that, I found this bit in the displacementLaplacian motion solver

if (frozenPointsZone_ != -1)
        {
            const pointZone& pz = fvMesh_.pointZones()[frozenPointsZone_];

            forAll(pz, i)
            {
                pointLocation_()[pz[i]] = points0()[pz[i]];
            }
        }

I will have a go and see if actually just giving the points in the relaxation zones as pointZones to this will solve it. Otherwise I will try something a bit more advanced, I'll let you know how it goes.

//Björn

[ngj]

Hi Björn,

I have only tested whether it compiles, but the following strategy might be interesting for you. In the file src/relaxationZone/relaxationZone.H I have made the following modifications:

#ifndef relaxationZone_H                                           #ifndef relaxationZone_H
#define relaxationZone_H                                           #define relaxationZone_H

#include "relaxationScheme.H"                                      #include "relaxationScheme.H"
#include "IOdictionary.H"                                          #include "IOdictionary.H"
#include "regIOobject.H"                                        <

// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *     // * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 

namespace Foam                                                     namespace Foam
{                                                                  {
/*-------------------------------------------------------------    /*-------------------------------------------------------------
                           Class relaxationZone Declaration                                   Class relaxationZone Declaration
\*-------------------------------------------------------------    \*-------------------------------------------------------------

class relaxationZone                                               class relaxationZone
:                                                               <
    public regIOobject                                          <
{                                                                  {
private:                                                           private:

    const fvMesh & mesh_;                                              const fvMesh & mesh_;
    volVectorField & U_;                                               volVectorField & U_;
    volScalarField & alpha_;                                           volScalarField & alpha_;
                                                                       
    wordList relaxNames_;                                              wordList relaxNames_;

    List<autoPtr<relaxationSchemes::relaxationScheme> > relaxSc        List<autoPtr<relaxationSchemes::relaxationScheme> > relaxSc

public:                                                            public:
     //- Runtime type information                                       //- Runtime type information
    TypeName("relaxationZone");                                        TypeName("relaxationZone");

    // Constructors                                                    // Constructors

        //- Construct from components                                      //- Construct from components
        relaxationZone                                                     relaxationZone
        (                                                                  (
            const IOobject &,                                   <
            const fvMesh &,                                                    const fvMesh &,
            volVectorField &,                                                  volVectorField &,
            volScalarField &                                                   volScalarField &
        );                                                                 );

    // Destructor                                                      // Destructor

        virtual ~relaxationZone()                                          virtual ~relaxationZone()
        {}                                                                 {}

    // Member Functions                                                // Member Functions

       virtual void correct();                                            virtual void correct();

       tmp<volScalarField> numericalBeach();                              tmp<volScalarField> numericalBeach();
};                                                                 };


} // End namespace Foam                                            } // End namespace Foam

#endif                                                             #endif

and the following in src/relaxationZone/relaxationZone.C

// * * * * * * * * * * * * * * * Constructor * * * * * * * * *     // * * * * * * * * * * * * * * * Constructor * * * * * * * * * 

relaxationZone::relaxationZone                                     relaxationZone::relaxationZone
(                                                                  (
    const IOobject & io,                                        <
    const fvMesh & mesh,                                               const fvMesh & mesh,
    volVectorField & U,                                                volVectorField & U,
    volScalarField & alpha                                             volScalarField & alpha
)                                                                  )
:                                                                  : 
    regIOobject( io ),                                          <
    mesh_(mesh),                                                       mesh_(mesh),
    U_(U),                                                             U_(U),
    alpha_(alpha),                                                     alpha_(alpha),

    relaxNames_((mesh_.thisDb().lookupObject<IOdictionary>("wav        relaxNames_((mesh_.thisDb().lookupObject<IOdictionary>("wav
                                                                          
    relaxSchemePtr_(relaxNames_.size())                                relaxSchemePtr_(relaxNames_.size())
{                                                                  { 
    forAll (relaxNames_, relaxi)                                       forAll (relaxNames_, relaxi)
    {                                                                  {
        relaxSchemePtr_[relaxi] = relaxationSchemes::relaxation            relaxSchemePtr_[relaxi] = relaxationSchemes::relaxation
    }                                                                  }
}                                                                  }

This should allow you to access the relaxationZone object from within the mesh motion library with a code of line along these lines:

const relaxationZone & rz = mesh_.lookupObject<infoContainer>("relaxationZone");

or

relaxationZone & rz = const_cast<relaxationZone &>( mesh_.lookupObject<infoContainer>("relaxationZone") );

All you will then need is to put a small method in the relaxation zone, which gathers (unique) cell/point indices from all of the relaxation zones. This should be fairly easy and you could benefit from using the

labelHashSet

class. Please post if it works and I will put the above changes into the release.

Kind regards

Niels

[winden]

Ok, so here is an easy fix for anyone using dynamic meshing and want the mesh to be frozen in the relaxation regions:

1. Create a pointSet with all the points in the relaxation regions.
2. Convert to a pointZone using setsToZones
3. Add the following line in the dynamicMeshDict

frozenPointsZone  <name of your pointZone>;

This is implemented in the displacementLaplacian and componentLaplacian motion solvers (as of 1.7.1) but It is pretty easy to put in a similar "hands on approach" as the one I showed above in any solver.

Take heed though, this basically just ignores any point displacement added to these points by the motion solver and sets it to zero. If you have a lot of motion close to the relaxation regions this might create very skewed cells on the border to these. If your motion "source" is relatively far away it should be fine. A better fix would probably be to follow Niels' suggestion above to remove these points from the motion matrix which should ensure that the motion gets diffused properly.

//Björn

PS. If you look at the point displacement in Paraview, it will be non zero in the area you specified. This is because the motion gets set to zero manually so the calculated pointDisplacement gets ignored but still printed as a field. The points will be stationary though if you look at them.

[kilroy]

Hi Niels,

I have a question for you. I am having problems with my simulation because of pressure instabilities.

I am trying to model a ship traveling in the ocean through the waves with constant speed.

At first, everything seems to be alright in the simulation. But after some point, the oscillations of the ship in the direction of gravity seems like getting higher and higher (the vehicle sinks more and jumps more on the water as the simulation progress further). You can find a video of my simulation below:

http://www.filedropper.com/vehiclewaves


I checked everything (mass of the vehicle, density of the fluid-air-vehicle, wave parameters, etc.) but nothing seems wrong.

I tried to run the simulation without any water movement or waves. But, again the oscillations of the ship gets higher and higher because of the unstable pressure variations under the ship until the analysis gets blown up.

Some other user reported the same problem in this thread below:

http://www.cfd-online.com/Forums/ope...ject-case.html


He told above that, the problem can be taken care of by solving for total pressure not for p_rgh and also by introducing a relaxation stage for the p field during the piso loop.

Do you think making those modifications can be done to "waveDyMFoam" easily?

If I want to do those modifications, where do you suggest me to start?

Thank you for your answer in advance.


Kilroy,

[ngj]

Hi Kilroy,

The only thing I know is that the system was solved for total pressure in 1.7, though in the following version this strategy was abandoned, because of issues with obtaining correct forces.

I have never tried to work with floating objects, so I am virtually clueless. However, are you sure that the 6DOF solver, which must be based on some ODE-system, is free of instabilities. It could remind me of some explicit Euler time integration?

Kind regards

Niels