[the_ichthyologist]

Hi Foamers,
I have three inlets/outlets internal to my mesh, I would like to create internal patches which should periodically shift between type empty (open) and type wall (closed). I thought this was an easy task but apparently it's not.

To start I tried just creating some baffles and apply type wall. I used patchPairs and not patchField, specifying the boundary conditions in the various files in the 0 folder (I don't think it makes some difference, does it?).

I'm using a modified interFoam (in openfoam6) and the solver runs for a while, the new internal walls don't seem to work, the timestep goes to zero in order to keep limited the phi and the interface Courant number (which are probably getting higher and higher). Looking in paraview it seems that the walls make some difference but a not clear one, the executed time is too short to tell, but they are not proper walls for sure.

My guess is that there is something wrong with the numerical schemes and I have no idea how to fix this. Maybe I shouldn't treat the patches as regular boundaries in the 0 folder files?

Then I would like to change the wall type and implementing the periodical boundary condition: is there any way I can change the type of the boundary periodically? If not, how do I tell the solver to ignore the wall and basically implement the empty boundary condition (maybe with cyclic? but then how to implement the wall part for other times?)?

I really hope to get some reply, it would be much appreciated.

This how my createBaffles look like:

internalFacesOnly true;

baffles
{
    inlet1faceZone  // and same for 2 and 3
    {
        type        faceZone;
        zoneName    inlet1faceZone;
        
        patchPairs
        {
               type            wall;
         }
      }
}

I applied boundary condition for the group and for the _master and _slave patch (I tried both and I had no difference): noSlip for U, zeroGradient for concentration, alpha.water, diffusivity and p_rgh (wall functions for k and nut but I set a laminar simulation to start).

I know this is a quite specific question but even general suggestions could bring me a little bit closer to the solution.

Giovanni

[the_ichthyologist]

So... I tried different solutions, but I'll keep it simple: if I use groovyBC for opening and closing inlets over time I get the inlets always closed. This could be linked to this warning when I run createBaffles -overwrite:

--> FOAM Warning : 
    From function int main(int, char**)
    in file createBaffles.C at line 854
    Setting field on boundary faces to zero.
You might have to edit these fields.

How do I edit them? Is this the actual cause?


Could you check my createBaffesDict? I'm not sure if I need to specify boundary condition also there but you can see them in the file. Also see attached a screen of what happens to U when I set it at 0.1 instead of interpolating U, you can see like a wall behaviour from one side (I see no effect on concentration). I think there is some issues on how the two sides are handled. Also the interface Courant number is pretty high.


I tried also changing the inlet type to empty: still a wall behaviour. Using checkMesh I found this message:

The mesh has multiple regions which are not connected by any face.

[the_ichthyologist]

So.. I realized that it's necessary to differentiate between the paired patches and to implement some kind of cyclic condition to connect the mesh parts at the inlets; what I would ideally want is to turn on and off over time between a cyclic and a wall condition. Unfotunately this is not possible with groovyBC. This is probably the most useful thread on this topic:
groovyBC for coupling of patches


It should be possible to map fields inside groovyBC (defining variables from other patches ) when patches have the same structure, but this does not work for some reason (it just averages and then everything crashes because of discontinuity). I could try again, maybe.


I also tried combining type mapped and type groovyBC but again it doesn't work, I should turn on and off the mapped as well, but this is not possible.


Then I tried just with a cyclic and at least this works, even if this is not what I want, so the way I create baflles is correct, I still get the high interface Courant number (and the later crash), and this could be more mesh-dependent (I'm using a "toy" mesh).


Now I'll try going back to codedFixedValue and implement this cyclic/wall over time condition for the various fields.

[Marpole]

Without knowing your model details, I can only guess.

First, I don't believe one can change patch type during a run. So changing from open to close should not involve a patch type change (e.g. not possible from cyclic to wall). Using cyclic boundary, something like activeBaffleVelocity, might be a way to go though I haven't seen a patch that have feature of turning on / off a valve. So, you might need to program. There are quite a few patches for selection in folder /opt/openfoam7/src/finiteVolume/fields/fvPatchFields/derived/.

About the multi-region message, when you use wall type patch, the fluid domain is split into two by the wall. That's why there sent a warning message on multiple-region because solver is designed to address one region fluid flow for most cases.

[the_ichthyologist]

Hi Charles! Thank you a lot for your reply and for your suggestion!


Unfortunately, no boundary condition seems to fit my requirements, and I'm really struggling to make it work...


I tried again with groovyBC but even if the fields have the same structured, even setting the patch as mapped, as said in the swak4foam guide:

The only exception currently implemented is if the current patch is a mapped patch and the external expression is evaluated on the “partner patch”. In this case the non-uniform result will be mapped to the local patch.

does not work.


I tried implementing this cyclic/wall condition with codedFixedValue, this is the velocity bc for an inlet side patch:

inlet1faceZone_lagoon
    {

                   type            codedFixedValue;
                   value           uniform (0 0 0);     

                   redirectType    combo1_lagoon;

                   codeOptions
                   #{
                     -I$(FOAM_CASE)/incl                 \
                     -I$(LIB_SRC)/finiteVolume/lnInclude \
                     -I$(LIB_SRC)/meshTools/lnInclude
                   #};

                   codeLibs
                   #{
                     -lmeshTools \
                     -lfiniteVolume
                   #};

                   codeInclude
                   #{
                      #include "fvCFD.H"
                      #include <cmath>
                      #include <iostream>
                      #include <stdio.h>
                      #include <stdlib.h>
                   #};

                   code
                   #{
                     //const fvMesh& mymesh=mesh();
                     const fvPatch& boundaryPatch = patch();
                     // get patch ID on opposite side
                     word oPatchName = "inlet1faceZone_sea";
                     label oPatchID = this->patch().boundaryMesh().findPatchID(oPatchName);
                   

                     const  vectorField& Cf = boundaryPatch.Cf();
                     vectorField& fieldU = *this;
                     volVectorField U = this->db().lookupObject<volVectorField>("U");
                     const Foam::fvPatchField<Foam::Vector<double> > Usea = U.boundaryField()[oPatchID];
                     
                     const scalar omega = 0.0418879; // T=150 s (0 in 37.5 out 112.5 ...)
   
                     scalar t = db().time().value();

                     if(cos(omega*t)/mag(cos(omega*t))>=0) // when open
                      {
                       
                       forAll(Cf, faceI)
                        {
                          label cellI = boundaryPatch.faceCells()[faceI];
                          if (Usea[faceI].component(0)>0) // inflow coming in > copy from sea patch
                          {
                          fieldU[faceI] = Usea[faceI];
                          //fieldU[cellI] =  0.5*(fieldU[cellI]+Usea[faceI]); //not sure about this
                          }
                          if (Usea[faceI].component(0)<0) // outflow > take from internal field
                          {
                          fieldU[faceI] = fieldU[cellI];
                          }
                        } 
                      }
                      else  // when closed
                      {

                       forAll(Cf, faceI)
                        {
                          fieldU[faceI] = vector(0,0,0); // wall behaviour
                        } 
                      }
             
                   #};
               
               
     }

For clarification my mesh is composed by a 'sea' basin and a 'lagoon' basin connected through three inlets and I want to open and close theinlets at different times in combination. See screenshot attached. Solver is interFoam.


I really don't know why it does not work (it's compiled correctly but soon it blows up). And I'm really not sure if I'm doing this correctly for the other fields, alpha.water (indicator function) and the pressure, as this condition maybe should be applied differently.

[the_ichthyologist]

Quick update: I went back to groovyBC, according to this thread:
groovyBC and access to alpha field of other patch
it should be possible to map fields between coupled patches. However, if I try to do it OpenFOAM complains during the run that it can't find the region of the patch in the object registry. This happens because createBaffles splits the mesh in two regions, groovyBC is aware of this but can't find them since these regions are not defined originally in the mesh, and it's not possible to define internal faces.

I'm very demotivated at this point but I guess that a way to go is to define the mesh, split it without createBaffles and somehow manage to define the patches separately, then apply groovyBC and maybe it could work...

[Marpole]

Thanks for the updating. You may need to create a new patch type (i.e. coding) based on patch type activeBaffleVelocity. The description is quite similar to what you want.

Description:
This velocity boundary condition simulates the opening of a baffle due to local flow conditions, by merging the behaviours of wall and cyclic conditions. The baffle joins two mesh regions, where the open fraction determines the interpolation weights applied to each cyclic- and neighbour-patch contribution.

[the_ichthyologist]

Thank you a lot for your simple yet important suggestion! Source code can be daunting but creating a new boundary condition resulted as the most simple and effective solution.


You can find a simple guide here:
http://openfoamwiki.net/index.php/Ho...dary_condition


The main issue was in activeBaffleVelocity itself, I reproduced the same error as in here:
activeBaffleVelocity boundary condition ?


I applied your workaround method and got sensible results.


However, I have issues decomposing the mesh and making the whole thing work in parallel. I haven't still gone in full detail about this and I'll post some updates tomorrowish.

[Marpole]

Hi Giovanni

Have you resolved the problem? If not, can you share you model so I can take a deep look into it and fix the problem?

[the_ichthyologist]

Hi Charles, I'm happy to tell you that everything works, to do the trick in parallel one needs to do the same for every processor* folder, basically:

• First remove compression writing in controlDict, then blockMesh topoSet decomposePar
• Change boundary file in each processor*/constant/polyMesh with Charles' method (add wall in same location as one of cyclic baffle), also change boundaryProcAddressing with the same order of items as in boundary
• Change files in processor*/0 adding the boundary conditions on the newly added walls
• only now do setFields in each processor*/
• fix boundary file and set the fields for the $FOAM_CASE/0 folder (serial run) with the wall baffles, this can be done after decomposePar

In this way the run and decomposePar work. I did some bash scripting for the whole process and I attach relevant files (also the bc).


As for the initial error about the interface phi Courant number the error was in the meshing, I needed to have a smoother and gradual meshing towards and away from baffles.


Thank you again Charles for your suggestion and encouragement, it's good to receive an answer when you are starting to feel hopeless