CFD Online Logo CFD Online URL
www.cfd-online.com
[Sponsors]
Home > Forums > OpenFOAM Pre-Processing

Valve Closing of a pipe/moving mesh (for investigating the water hammer effect)

Register Blogs Members List Search Today's Posts Mark Forums Read

Reply
 
LinkBack Thread Tools Display Modes
Old   August 11, 2017, 13:50
Default Valve Closing of a pipe/moving mesh (for investigating the water hammer effect)
  #1
New Member
 
Oliver K
Join Date: May 2017
Posts: 12
Rep Power: 2
silencebreak is on a distinguished road
Hey foamers,

I'm quite unsure how to proceed in this case so here a quick question:

The Case:
The upper reservoir is filled with water which is flooding down the pipe. After some time (30 seconds) the valve is closing and there is a propagating shockwave in the water due to the closing.

What I got so far:
I actually get hung on the fact how I'm going to define the patch for the closing of the pipe.
My first thought was to just define a Wall at the area of the outlet with AMI which should be moved downwards after a specified time.

I'm currently in the state of snapping the geometry, in which I actually don't know what the best way it is to start with for an AMI case.
So my first try is as followed:
Before the outlet I put a moving wall which I've created with Salome (shown in the picture), so I got a surface closed system. The problem at this method is, that i don't get a sharp line of a gate valve as my snapped valve is brought down to a round figure when the "wall" is inside the pipe at the snapping stage. The gate valve isn't getting snapped when it's completely open in the snapping stage (like in the photo I uploaded)

Another thought was to do it at the outlet with groovyBCs, but unfortunately I always got some problems at inlets and outlets with oscillations.

My sHM-File looks like:
Code:
/*--------------------------------*- C++ -*----------------------------------*\
| =========                 |                                                 |
| \\      /  F ield         | OpenFOAM: The Open Source CFD Toolbox           |
|  \\    /   O peration     | Version:  2.4.0                                 |
|   \\  /    A nd           | Web:      www.OpenFOAM.org                      |
|    \\/     M anipulation  |                                                 |
\*---------------------------------------------------------------------------*/
FoamFile
{
    version     2.0;
    format      ascii;
    class       dictionary;
    object      snappyHexMeshDict;
}
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //

// Which of the steps to run
castellatedMesh true;
snap                 true;
addLayers         false;


// Geometry. Definition of all surfaces. All surfaces are of class
// searchableSurface.
// Surfaces are used
// - to specify refinement for any mesh cell intersecting it
// - to specify refinement for any mesh cell inside/outside/near
// - to 'snap' the mesh boundary to the surface
geometry
{
       regionSTL.stl
       {
            type triSurfaceMesh;
            regions
            {
                outlet      { name outlet; }
                pipeWall    { name pipeWall; }
                pipeWallEnd { name pipeWall; }
                kaverneWall { name kaverneWall; }
                atmosphere  { name atmosphere; }
            }
       }
       AMI.stl
       {
            type triSurfaceMesh;
            name AMI;
       }
};



// Settings for the castellatedMesh generation.
castellatedMeshControls
{

    // Refinement parameters
    // ~~~~~~~~~~~~~~~~~~~~~

    // If local number of cells is >= maxLocalCells on any processor
    // switches from from refinement followed by balancing
    // (current method) to (weighted) balancing before refinement.
    maxLocalCells 900000; //100000

    // Overall cell limit (approximately). Refinement will stop immediately
    // upon reaching this number so a refinement level might not complete.
    // Note that this is the number of cells before removing the part which
    // is not 'visible' from the keepPoint. The final number of cells might
    // actually be a lot less.
    maxGlobalCells 8000000; //2000000

    // The surface refinement loop might spend lots of iterations refining just a
    // few cells. This setting will cause refinement to stop if <= minimumRefine
    // are selected for refinement. Note: it will at least do one iteration
    // (unless the number of cells to refine is 0)
    minRefinementCells 10;//was 10

    // Allow a certain level of imbalance during refining
    // (since balancing is quite expensive)
    // Expressed as fraction of perfect balance (= overall number of cells /
    // nProcs). 0=balance always.
    maxLoadUnbalance 0.10; //was 0.10

    // Number of buffer layers between different levels.
    // 1 means normal 2:1 refinement restriction, larger means slower
    // refinement.
    nCellsBetweenLevels 3; //was 3



    // Explicit feature edge refinement
    // ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

    // Specifies a level for any cell intersected by its edges.
    // This is a featureEdgeMesh, read from constant/triSurface for now.
    features
    (
        {
            file "kaverneWall.obj";
            levels ((0 2));//was (0 3)
        }
        {
            file "Diffusor.obj";
            levels ((0 3));
        }
        {
            file "outlet.obj";
            levels ((0 4));//was (0 4)
        }
    );
    // Surface based refinement
    // ~~~~~~~~~~~~~~~~~~~~~~~~

    // Specifies two levels for every surface. The first is the minimum level,
    // every cell intersecting a surface gets refined up to the minimum level.
    // The second level is the maximum level. Cells that 'see' multiple
    // intersections where the intersections make an
    // angle > resolveFeatureAngle get refined up to the maximum level.

    refinementSurfaces
    {
        regionSTL.stl
        {
            level (0 0);

            regions
            {
                outlet          { level (4 4); patchInfo { type patch; }}//was level (4 4)
                atmosphere      { level (2 2); patchInfo { type patch; }}//was level (4 4)
                kaverneWall     { level (1 1); patchInfo { type wall; }}
                pipeWall        { level (3 3); patchInfo { type wall; }}//was level (4 4)
            }
        }

        AMI
        {

            level (2 2);

            faceType boundary;
            cellZone innerAMI;
            faceZone innerAMI;
            cellZoneInside inside;
        }

    }
[...]

I've never done a moving mesh before, so could anybody tell my if I could proceed with the way I thought or is it complete bullshit?

Thank you a lot!

Cheers
Oli
Attached Images
File Type: png Overview.png (11.8 KB, 14 views)
File Type: png outlet_area.png (16.5 KB, 14 views)
silencebreak is offline   Reply With Quote

Reply

Thread Tools
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 On
Pingbacks are On
Refbacks are On


Similar Threads
Thread Thread Starter Forum Replies Last Post
Gambit problems Althea FLUENT 22 January 4, 2017 04:19
Moving mesh Niklas Wikstrom (Wikstrom) OpenFOAM Running, Solving & CFD 122 June 15, 2014 06:20
fluent add additional zones for the mesh file SSL FLUENT 2 January 26, 2008 12:55
Icemcfd 11: Loss of mesh from surface mesh option? Joe CFX 2 March 26, 2007 18:10
How to control Minximum mesh space? hung FLUENT 7 April 18, 2005 09:38


All times are GMT -4. The time now is 22:36.