[wyldckat]

Hi Kumudu,

If you study this guide: http://linuxcommand.org/learning_the_shell.php - you should be able to figure it out on your own

But the answer is simple:

1. "refineMeshByCellSet()" is a shell function.
2. "refineMeshByCellSet 1 2 3" means that "1 2 3" are the arguments sent to the function.
3. "$1" refers to the first argument that the function receives.
4. "shift" means that the list of arguments is shifted to the left, therefore changing "1 2 3" to "2 3" and later to "3" and then to "". How? Thanks to the "while", which is a loop.
5. Basically this means that there are 3 files:
   

   system/topoSetDict.1
   system/topoSetDict.2
   system/topoSetDict.3

   that are copied to "system/topoSetDict" (one at a time) and then refineMesh is executed with this dictionary file (one at a time).

Best regards,
Bruno

[Kumudu]

Originally Posted by wyldckat

Hi Kumudu,

If you study this guide: http://linuxcommand.org/learning_the_shell.php - you should be able to figure it out on your own

But the answer is simple:

1. "refineMeshByCellSet()" is a shell function.
2. "refineMeshByCellSet 1 2 3" means that "1 2 3" are the arguments sent to the function.
3. "$1" refers to the first argument that the function receives.
4. "shift" means that the list of arguments is shifted to the left, therefore changing "1 2 3" to "2 3" and later to "3" and then to "". How? Thanks to the "while", which is a loop.
5. Basically this means that there are 3 files:
   

   system/topoSetDict.1
   system/topoSetDict.2
   system/topoSetDict.3

   that are copied to "system/topoSetDict" (one at a time) and then refineMesh is executed with this dictionary file (one at a time).

Best regards,
Bruno

Dear Bruno,

Thank you very much.

Best regards,
Kumudu

[Kumudu]

Originally Posted by wyldckat

Hi Kumudu,

First problem - this line:

topoSet -dict system/topoSetDict1

Should be:

topoSet -dict system/topoSetDict01

Reason: topoSet was complaining that it could not open the file "system/topoSetDict1", because it didn't exist, since the correct name was "system/topoSetDict01" .
Same goes for "system/topoSetDict2" -> "system/topoSetDict02".


As to explain what I meant before - you currently have got this:

runApplication blockMesh
runApplication topoSet -dict system/topoSetDict01
runApplication createPatch -overwrite
runApplication topoSet -dict system/topoSetDict02
runApplication splitMeshRegions -cellZones -overwrite

According to my step list from post #32, it should look something like this (lines that start with # are comments):

runApplication blockMesh

#define the cell set "cellSetForRefinement" for the refinement and then refine
runApplication topoSet -dict system/topoSetDict00
runApplication refineHexMesh -overwrite cellSetForRefinement

#define the zones for the regions and split the mesh into regions
runApplication topoSet -dict system/topoSetDict02
runApplication splitMeshRegions -cellZones -overwrite

#define the faceSets for the inlet and outlet patches and create the patches
runApplication topoSet -dict system/topoSetDict01 -region water
runApplication createPatch -overwrite  -region water

Best regards,
Bruno

Dear Bruno,

I am back again after long time finishing all the exams.

I have followed the steps you mentioned in the above. I still have maxZ face at the inlet and outlet faces. I use the "topoSet -dict system/topoSetDict01 -region water" and "createPatch -overwrite -region water" as you said.

I am attaching the files and figures of the top view of the water region that shows maxZ at the inlet and outlet.

Could you please tell me, what would be the reason that I still have these faces?

Thanks in advance.
Best regards,
Kumudu

[Kumudu]

Dear Bruno,

These are the steps I followed,if in case you need to check them,

P { margin-bottom: 0.08in; } runApplication blockMesh


#define the cell set "refineCells" for the refinement and then refine
runApplication topoSet -dict system/topoSetDictRefine
runApplication refineMesh -overwrite -dict




#define the zones for the regions and split the mesh into regions
runApplication topoSet -dict system/topoSetDictRegions
runApplication splitMeshRegions -cellZones -overwrite


#define the faceSets for the inlet and outlet patches and create the patches
runApplication topoSet -dict system/topoSetDictFaceSet -region water
runApplication createPatch -overwrite -region water



Please find the attached files. I couldn't attach them as a one Zip file. So, I am attaching them as 0,constant and system.

Thanks in advance.
Best regards,
Kumudu

[wyldckat]

Hi Kumudu,

You have the boxes defined too tightly. Basically, if a box has a lower Z of 40 and a higher Z of 40, nothing can fit inside, because it's a plane and not a box
Keep in mind that it's a "boxToFace", not a "planeToFace" (I don't think this one exists)

Edit the file "system/water/topoSetDictFaceSet" and notice the changes I've made:

zmaxP1    40;
zmaxP2    40;
zmaxP3    1.03;

zmaxP1a  39.999;
zmaxP1b  40.001;
zmaxP2a  39.999;
zmaxP2b  40.001;


actions
(
    {
        name    f_inlet;
        type    faceSet;
        action  new;
        source  boxToFace;
        sourceInfo
        {
            box ($xminP1 $yminP1 $zmaxP1a)($xmaxP1 $ymaxP1 $zmaxP1b);
        }
    }
    {
        name    f_outlet;
        type    faceSet;
        action  new;
        source  boxToFace;
        sourceInfo
        {
            box ($xminP2 $yminP2 $zmaxP2a)($xmaxP2 $ymaxP2 $zmaxP2b);
        }
    }
);

The idea is for "zmaxP1a" and "zmaxP1b" to be close enough to the faces you want to catch, but without exceeding the numerical limits. For example, these values are bad:

zmaxP1a  39.999999999999999999999999999999999999999;
zmaxP1b  40.00000000000000000000000000000000001;

zmaxP2a  38;
zmaxP2b  42;

The first pair is wrong because it's beyond the computational number resolution; the second pair is wrong because it passes beyond the centre of the cell associated to the patches.

Best regards,
Bruno

[Kumudu]

Originally Posted by wyldckat

Hi Kumudu,

You have the boxes defined too tightly. Basically, if a box has a lower Z of 40 and a higher Z of 40, nothing can fit inside, because it's a plane and not a box
Keep in mind that it's a "boxToFace", not a "planeToFace" (I don't think this one exists)

Edit the file "system/water/topoSetDictFaceSet" and notice the changes I've made:

zmaxP1    40;
zmaxP2    40;
zmaxP3    1.03;

zmaxP1a  39.999;
zmaxP1b  40.001;
zmaxP2a  39.999;
zmaxP2b  40.001;


actions
(
    {
        name    f_inlet;
        type    faceSet;
        action  new;
        source  boxToFace;
        sourceInfo
        {
            box ($xminP1 $yminP1 $zmaxP1a)($xmaxP1 $ymaxP1 $zmaxP1b);
        }
    }
    {
        name    f_outlet;
        type    faceSet;
        action  new;
        source  boxToFace;
        sourceInfo
        {
            box ($xminP2 $yminP2 $zmaxP2a)($xmaxP2 $ymaxP2 $zmaxP2b);
        }
    }
);

The idea is for "zmaxP1a" and "zmaxP1b" to be close enough to the faces you want to catch, but without exceeding the numerical limits. For example, these values are bad:

zmaxP1a  39.999999999999999999999999999999999999999;
zmaxP1b  40.00000000000000000000000000000000001;

zmaxP2a  38;
zmaxP2b  42;

The first pair is wrong because it's beyond the computational number resolution; the second pair is wrong because it passes beyond the centre of the cell associated to the patches.

Best regards,
Bruno

Dear Bruno,

Thank you very much. Now I understand what was wrong. I will make the corrections and let you know.


Best regards,
Kumudu

[Kumudu]

Originally Posted by Kumudu

Dear Bruno,

Thank you very much. Now I understand what was wrong. I will make the corrections and let you know.


Best regards,
Kumudu

Dear Bruno,

It worked. Thank you very much.

Best regards,
Kumudu

[Kumudu]

Dear Bruno,

I have created a case which have four different materials (water,pipe,filling material, soil). I use blockMesh to create the domain and then use the topoSet to define the regions. This time I defined the inlet and outlet for the fluid region using the blockMeshDict.

I have used several blocks with different grading in the mesh to catch the different length scales in my problem. I have attached the .jpg file of the regions. But when I run the file for 10s, it just run for 5s and gave the error massage:
--> FOAM FATAL ERROR:
[1] Maximum number of iterations exceeded


I have then changed the line
"const int Foam::specieThermo<Thermo>::maxIter_ = 100;"

in the
opt/openfoam211/src/thermophysicalModels/specie/lnInclude$ gedit specieThermo.C

into

"const int Foam::specieThermo<Thermo>::maxIter_ = 5000;"

But, it still gives me the same error. I have attached the case file. Could you please tell me how to fix this problem. Is this problem cause due to my mesh?

Thanks in advance.

Best regards,
Kumudu

[Kumudu]

Dear Bruno,

here is part of the full error message:

Solving for fluid region water
diagonal:  Solving for rho, Initial residual = 0, Final residual = 0, No Iterations 0
DILUPBiCG:  Solving for Ux, Initial residual = 0.98619399, Final residual = 2.5437182e-08, No Iterations 84
DILUPBiCG:  Solving for Uy, Initial residual = 0.98967568, Final residual = 9.3487139e-08, No Iterations 84
DILUPBiCG:  Solving for Uz, Initial residual = 0.98334287, Final residual = 7.8463215e-08, No Iterations 84


--> FOAM FATAL ERROR: 
Maximum number of iterations exceeded

 From function specieThermo<Thermo>::T(scalar f, scalar T0, scalar (specieThermo<Thermo>::*F)(const scalar) const, scalar (specieThermo<Thermo>::*dFdT)(const scalar) const) const
in file /home/opencfd/OpenFOAM/OpenFOAM-2.1.0/src/thermophysicalModels/specie/lnInclude/specieThermoI.H at line 69.
  
FOAM parallel run aborting


--> FOAM FATAL ERROR: 
Maximum number of iterations exceeded

  From function specieThermo<Thermo>::T(scalar f, scalar T0, scalar (specieThermo<Thermo>::*F)(const scalar) const, scalar (specieThermo<Thermo>::*dFdT)(const scalar) const) const

in file /home/opencfd/OpenFOAM/OpenFOAM-2.1.0/src/thermophysicalModels/specie/lnInclude/specieThermoI.H at line 69.

FOAM parallel run aborting


DILUPBiCG:  Solving for h, Initial residual = 0.99994363, Final residual = 9.0410388e-08, No Iterations 87

--> FOAM FATAL ERROR: 
Maximum number of iterations exceeded

From function specieThermo<Thermo>::T(scalar f, scalar T0, scalar (specieThermo<Thermo>::*F)(const scalar) const, scalar (specieThermo<Thermo>::*dFdT)(const scalar) const) const

in file /home/opencfd/OpenFOAM/OpenFOAM-2.1.0/src/thermophysicalModels/specie/lnInclude/specieThermoI.H at line 69.

FOAM parallel run aborting



--> FOAM FATAL ERROR: 
Maximum number of iterations exceeded

  From function specieThermo<Thermo>::T(scalar f, scalar T0, scalar (specieThermo<Thermo>::*F)(const scalar) const, scalar (specieThermo<Thermo>::*dFdT)(const scalar) const) const
in file /home/opencfd/OpenFOAM/OpenFOAM-2.1.0/src/thermophysicalModels/specie/lnInclude/specieThermoI.H at line 69.

best regards,
Kumudu

[wyldckat]

Hi Kumudu,

So, this is basically several problems in a single case.

Firstly, you're using chtMultiRegionFoam, which is a transient solver and which requires for the Courant number to stick to low values, usually around 0.5 at most. Since you turned off automatic deltaT adjustments:

adjustTimeStep  no;

the solver's only choice was to blow up the simulation, because it was impossible to solve the problem
More specifically, this is what I'm talking about, which is the time iteration prior to the one that crashes:

Time = 5


Solving for fluid region water
diagonal:  Solving for rho, Initial residual = 0, Final residual = 0, No Iterations 0
DILUPBiCG:  Solving for Ux, Initial residual = 0.96712474, Final residual = 5.8988354e-08, No Iterations 72
DILUPBiCG:  Solving for Uy, Initial residual = 0.96904191, Final residual = 7.4006406e-08, No Iterations 72
DILUPBiCG:  Solving for Uz, Initial residual = 0.96440759, Final residual = 5.3647585e-08, No Iterations 72
DILUPBiCG:  Solving for h, Initial residual = 0.99601552, Final residual = 1.9933183e-08, No Iterations 74
 Min/max T:-89820.961 1348.6201
GAMG:  Solving for p_rgh, Initial residual = 0.99943473, Final residual = 0.0075440402, No Iterations 4
diagonal:  Solving for rho, Initial residual = 0, Final residual = 0, No Iterations 0
time step continuity errors (water): sum local = -96.789128, global = 1.0330402, cumulative = 0.38554559
GAMG:  Solving for p_rgh, Initial residual = 0.53592312, Final residual = 0.00012831322, No Iterations 1000
diagonal:  Solving for rho, Initial residual = 0, Final residual = 0, No Iterations 0
time step continuity errors (water): sum local = -14.468018, global = 1.1572485, cumulative = 1.5427941

Solving for solid region soil
DICPCG:  Solving for T, Initial residual = 0.10794196, Final residual = 3.6911129e-08, No Iterations 3
DICPCG:  Solving for T, Initial residual = 4.0107831e-08, Final residual = 4.0107831e-08, No Iterations 0
Min/max T:min(T) [0 0 0 1 0 0 0] 277 max(T) [0 0 0 1 0 0 0] 295

Solving for solid region pipe
DICPCG:  Solving for T, Initial residual = 0.97059185, Final residual = 3.0475829e-07, No Iterations 4
DICPCG:  Solving for T, Initial residual = 7.2913056e-09, Final residual = 7.2913056e-09, No Iterations 0
Min/max T:min(T) [0 0 0 1 0 0 0] -50735.672 max(T) [0 0 0 1 0 0 0] 566.6835

Solving for solid region Borehole
DICPCG:  Solving for T, Initial residual = 0.63383353, Final residual = 1.8912943e-07, No Iterations 6
DICPCG:  Solving for T, Initial residual = 1.4856261e-09, Final residual = 1.4856261e-09, No Iterations 0
Min/max T:min(T) [0 0 0 1 0 0 0] -580.36232 max(T) [0 0 0 1 0 0 0] 302.58436
ExecutionTime = 5.93 s  ClockTime = 6 s

Region: water Courant Number mean: 330368.2 max: 2.799531e+08
Region: soil Diffusion Number mean: 4.3894482e-05 max: 0.00056112935
Region: pipe Diffusion Number mean: 0.00012317156 max: 0.00054975752
Region: Borehole Diffusion Number mean: 0.00021248831 max: 0.0017169268

Shown in bold are several critical issues, where the last one is the Courant Number values for the water region. I would say that "2.799531e+08" is waaaaaaaaaaaaaaaaaay bigger than 0.5


The actual reason for this? Run this command, after the mesh is completely done:

checkMesh -region water

Among the lengthy output, this is shown:

Min volume = 5.3733903e-09. Max volume = 0.00014412465.  Total volume = 0.021915648.  Cell volumes OK.

The smallest volume is "5.3733903e-09" m³! That is a reaaaaally small volume
Remember the very first tutorial in the OpenFOAM User Guide: http://www.openfoam.org/docs/user/cavity.php
It explains there how the Courant Number is calculated... which is directly related to the volume of a cell (unless you're simulating in 2D).


And what cells is this in reference to? Here's the problem:
U section of water pipe.jpg
Click on the image and you'll see a very thin line of cells in the U part of the pipe. Those are the cells that are causing the problem.


Unfortunately, this is probably not the only problem. You're using really long cells along the pipe, which can lead to problems in the near future. Why? Because meshes are extremely important for quality simulations+results.
Here's a compilation of the interesting cases I've had the pleasure of analysing here on the forum: OpenFOAM: Interesting cases of bad meshes and bad initial conditions - innocent looking meshes resulted in solver crashes or at least lead to non-physical results. There you should be able to see for yourself what bad cell proportions can lead to.


Best regards,
Bruno

[Kumudu]

Originally Posted by wyldckat

Hi Kumudu,

So, this is basically several problems in a single case.

Firstly, you're using chtMultiRegionFoam, which is a transient solver and which requires for the Courant number to stick to low values, usually around 0.5 at most. Since you turned off automatic deltaT adjustments:

adjustTimeStep  no;

the solver's only choice was to blow up the simulation, because it was impossible to solve the problem
More specifically, this is what I'm talking about, which is the time iteration prior to the one that crashes:

Time = 5


Solving for fluid region water
diagonal:  Solving for rho, Initial residual = 0, Final residual = 0, No Iterations 0
DILUPBiCG:  Solving for Ux, Initial residual = 0.96712474, Final residual = 5.8988354e-08, No Iterations 72
DILUPBiCG:  Solving for Uy, Initial residual = 0.96904191, Final residual = 7.4006406e-08, No Iterations 72
DILUPBiCG:  Solving for Uz, Initial residual = 0.96440759, Final residual = 5.3647585e-08, No Iterations 72
DILUPBiCG:  Solving for h, Initial residual = 0.99601552, Final residual = 1.9933183e-08, No Iterations 74
 Min/max T:-89820.961 1348.6201
GAMG:  Solving for p_rgh, Initial residual = 0.99943473, Final residual = 0.0075440402, No Iterations 4
diagonal:  Solving for rho, Initial residual = 0, Final residual = 0, No Iterations 0
time step continuity errors (water): sum local = -96.789128, global = 1.0330402, cumulative = 0.38554559
GAMG:  Solving for p_rgh, Initial residual = 0.53592312, Final residual = 0.00012831322, No Iterations 1000
diagonal:  Solving for rho, Initial residual = 0, Final residual = 0, No Iterations 0
time step continuity errors (water): sum local = -14.468018, global = 1.1572485, cumulative = 1.5427941

Solving for solid region soil
DICPCG:  Solving for T, Initial residual = 0.10794196, Final residual = 3.6911129e-08, No Iterations 3
DICPCG:  Solving for T, Initial residual = 4.0107831e-08, Final residual = 4.0107831e-08, No Iterations 0
Min/max T:min(T) [0 0 0 1 0 0 0] 277 max(T) [0 0 0 1 0 0 0] 295

Solving for solid region pipe
DICPCG:  Solving for T, Initial residual = 0.97059185, Final residual = 3.0475829e-07, No Iterations 4
DICPCG:  Solving for T, Initial residual = 7.2913056e-09, Final residual = 7.2913056e-09, No Iterations 0
Min/max T:min(T) [0 0 0 1 0 0 0] -50735.672 max(T) [0 0 0 1 0 0 0] 566.6835

Solving for solid region Borehole
DICPCG:  Solving for T, Initial residual = 0.63383353, Final residual = 1.8912943e-07, No Iterations 6
DICPCG:  Solving for T, Initial residual = 1.4856261e-09, Final residual = 1.4856261e-09, No Iterations 0
Min/max T:min(T) [0 0 0 1 0 0 0] -580.36232 max(T) [0 0 0 1 0 0 0] 302.58436
ExecutionTime = 5.93 s  ClockTime = 6 s

Region: water Courant Number mean: 330368.2 max: 2.799531e+08
Region: soil Diffusion Number mean: 4.3894482e-05 max: 0.00056112935
Region: pipe Diffusion Number mean: 0.00012317156 max: 0.00054975752
Region: Borehole Diffusion Number mean: 0.00021248831 max: 0.0017169268

Shown in bold are several critical issues, where the last one is the Courant Number values for the water region. I would say that "2.799531e+08" is waaaaaaaaaaaaaaaaaay bigger than 0.5


The actual reason for this? Run this command, after the mesh is completely done:

checkMesh -region water

Among the lengthy output, this is shown:

Min volume = 5.3733903e-09. Max volume = 0.00014412465.  Total volume = 0.021915648.  Cell volumes OK.

The smallest volume is "5.3733903e-09" m³! That is a reaaaaally small volume
Remember the very first tutorial in the OpenFOAM User Guide: http://www.openfoam.org/docs/user/cavity.php
It explains there how the Courant Number is calculated... which is directly related to the volume of a cell (unless you're simulating in 2D).


And what cells is this in reference to? Here's the problem:
Attachment 29035
Click on the image and you'll see a very thin line of cells in the U part of the pipe. Those are the cells that are causing the problem.


Unfortunately, this is probably not the only problem. You're using really long cells along the pipe, which can lead to problems in the near future. Why? Because meshes are extremely important for quality simulations+results.
Here's a compilation of the interesting cases I've had the pleasure of analysing here on the forum: OpenFOAM: Interesting cases of bad meshes and bad initial conditions - innocent looking meshes resulted in solver crashes or at least lead to non-physical results. There you should be able to see for yourself what bad cell proportions can lead to.


Best regards,
Bruno

Dear Bruno,

Thank you very much. When I set the time step to 0.01 and remove the grading in the Z-direction by catching the U-part of the pipe with another block with dz=0.012, the error didn't appeared. Because,Courant Number was 0.3 at that part.

Thanks again,

Best regards,
Kumudu

[Kumudu]

Dear Bruno,

I want to run the chtMultiRegionFoam with different inlet temperature and velocity magnitudes at different times. For example, lets say I want to change the inlet temperature of the fluid region hourly so that heat load to the system will change hourly. Also, after 12 hours of circulating the water in the pipe, I want to stop the circulation by setting the velocity equal to zero and recirculate it again after another 12 hours . Is there any way that I could set these conditions easily ?


Also, I have another question regarding run the chtMultiRegionFoam in parallel.

My server has 6 processors and I want to decompose the 4 regions (soil,water,...) into these 6 processors and run it.

I changed the decomposeParDict as follows,

numberOfSubdomains  6;

//- Keep owner and neighbour on same processor for faces in zones:
// preserveFaceZones (heater solid1 solid3);

method          scotch;
// method          hierarchical;
// method          simple;
// method          manual;

simpleCoeffs
{
    n           (2 2 2);
    delta       0.001;
}

hierarchicalCoeffs
{
    n           (1 1 1);
    delta       0.001;
    order       xyz;
}

scotchCoeffs
{
    processorWeights
    (
       1
       1
       1
       1
       1
       1
    );
    //writeGraph  true;
    //strategy "b";
}

manualCoeffs
{
    dataFile    "decompositionData";
}


//// Is the case distributed
//distributed     yes;
//// Per slave (so nProcs-1 entries) the directory above the case.
//roots
//(
//    "/tmp"
//    "/tmp"
//);

And run it as follows,

# Decompose
for i in water soil pipe Borehole
do
   decomposePar -region $i > log.decomposePar.$i 2>&1
done

# Run
runParallel `getApplication` 6

# Reconstruct
for i in water soil pipe Borehole
do
   reconstructPar -region $i > log.reconstructPar.$i 2>&1
done

But I got an error. Could you please tell me how to run it correctly.
Thanks in advance.

Best regards,
Kumudu

[lramutti]

Hey guys,

Your discussion is very interesting. In fact, I just ran into a similar problem that I do not know how to solve. I am trying to model a 2D geometry as attached. As you can see I have one dome resting on top of a rectangle surrounded by walls. I am also trying to simulate a conjugate heat transfer problem but my problem is while using the topoSetDict. This is my topoSetDict file so far:

/*--------------------------------*- C++ -*----------------------------------*\
| =========                 |                                                 |
| \\      /  F ield         | OpenFOAM: The Open Source CFD Toolbox           |
|  \\    /   O peration     | Version:  2.1.x                                 |
|   \\  /    A nd           | Web:      www.OpenFOAM.org                      |
|    \\/     M anipulation  |                                                 |
\*---------------------------------------------------------------------------*/
FoamFile
{
    version     2.0;
    format      ascii;
    class       dictionary;
    object      topoSetDict;
}

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

// Useful website to help determine which geometry to use for the topoSetDict file
// https://github.com/OpenFOAM/OpenFOAM...et/topoSetDict

// OBS.: topoSetDict is in meters.

actions
(
    // bottomWall
    {
        name    bottomWall;
        type    cellSet;
        action  new;
        source  boxToCell;
        sourceInfo
        {
            box (0 -0.02 0 )(0.075 0 0.01);
            box (0.075 0 0.01)(0.125 -2 0);
            box (0.125 -2 0)(0.20 0 0.01); 
        }
    }
    {
        name    bottomWall;
        type    cellZoneSet;
        action  new;
        source  setToCellZone;
        sourceInfo
        {
            set bottomWall;
        }
    }

    // leftWall
    {
        name    leftWall;
        type    cellSet;
        action  new;
        source  boxToCell;
        sourceInfo
        {
            box (-0.02 0 0 )(0 0.10 0.01);  
        }
    }
    {
        name    leftWall;
        type    cellZoneSet;
        action  new;
        source  setToCellZone;
        sourceInfo
        {
            set leftWall;
        }
    }

    // rightWall
    {
        name    rightWall;
        type    cellSet;
        action  new;
        source  boxToCell;
        sourceInfo
        {
            box (0.2 0 0 )(0.22 0.1 0.01); 
        }
    }
    {
        name    rightWall;
        type    cellZoneSet;
        action  new;
        source  setToCellZone;
        sourceInfo
        {
            set rightWall;
        }
    }

     // air
     {
        name    air;
        type    cellSet;
        action  new;
        source  boxToCell;
        sourceInfo
        {
        // base
            box (0 0 0)(0.075 0.10 0.01);
        box (0.075 0.10 0.01)(0.125 0 0);
            box (0.125 0 0)(0.20 0.10 0.01);
    }
     }

     {
        name    air;
        type    cellZoneSet;
        action  new;
        source  setToCellZone;
        sourceInfo
        {
            set air;
        }
    }

    {
        name    airdome;
        type    cellSet;
        action  new;
        source  cylinderToCell;
        sourceInfo
        {
           p1 (0.10 0.10 0);
           p2 (0.10 0.10 0.01);
       radius 0.10;        
        }
     }
    
     {
        name    airdome;
        type    cellZoneSet;
        action  new;
        source  cylinderToCell;
        sourceInfo
        {
            set airdome;
        }
     }
  
);

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

As you can see, I am using the cylinderToCell to tackle the 2D dome and the boxToCell to cover the rectangle below. The problem is that for some strange reason this is not working. When I run topoSet on the command line this is what it prints:

Time = 0
    mesh not changed.
Created cellSet bottomWall
    Applying source boxToCell
    Adding cells with center within boxes 1((0.125 -2 0) (0.2 0 0.01))
    cellSet bottomWall now size 200
Created cellZoneSet bottomWall
    Applying source setToCellZone
    Adding all cells from cellSet bottomWall ...
    cellZoneSet bottomWall now size 200
Created cellSet leftWall
    Applying source boxToCell
    Adding cells with center within boxes 1((-0.02 0 0) (0 0.1 0.01))
    cellSet leftWall now size 200
Created cellZoneSet leftWall
    Applying source setToCellZone
    Adding all cells from cellSet leftWall ...
    cellZoneSet leftWall now size 200
Created cellSet rightWall
    Applying source boxToCell
    Adding cells with center within boxes 1((0.2 0 0) (0.22 0.1 0.01))
    cellSet rightWall now size 200
Created cellZoneSet rightWall
    Applying source setToCellZone
    Adding all cells from cellSet rightWall ...
    cellZoneSet rightWall now size 200
Created cellSet air
    Applying source boxToCell
    Adding cells with center within boxes 1((0.125 0 0) (0.2 0.1 0.01))
    cellSet air now size 200
Created cellZoneSet air
    Applying source setToCellZone
    Adding all cells from cellSet air ...
    cellZoneSet air now size 200
Created cellSet airdome
    Applying source cylinderToCell
    Adding cells with centre within cylinder, with p1 = (0.1 0.1 0), p2 = (0.1 0.1 0.01) and radius = 0.1
    cellSet airdome now size 2088
Created cellZoneSet airdome
    Applying source cylinderToCell


--> FOAM FATAL IO ERROR: 
keyword p1 is undefined in dictionary "/home/meisu/OpenFOAM/meisu-2.2.1/run/Research/ConjugateHeatTransfer/RayleighBenard/caseTwoDomeThreeWalls/system/topoSetDict.actions.sourceInfo"

file: /home/meisu/OpenFOAM/meisu-2.2.1/run/Research/ConjugateHeatTransfer/RayleighBenard/caseTwoDomeThreeWalls/system/topoSetDict.actions.sourceInfo from line 139 to line 139.

    From function dictionary::lookupEntry(const word&, bool, bool) const
    in file db/dictionary/dictionary.C at line 402.

FOAM exiting

I did some research on this problem - http://www.cfd-online.com/Forums/ope...nal-field.html - and I noticed that my units are correct. Would it be possible for you guys to take a look at this case? Please let me know if you would like me to send the blockMesh file.

I greatly appreciate your attention,

Lucas

[Kumudu]

Hi Lucas,

I am no expert in this area. But, I think the problem is with defining the topoSet region using cylinderToCell.

"keyword p1 is undefined in dictionary "/home/meisu/OpenFOAM/meisu-2.2.1/run/Research/ConjugateHeatTransfer/RayleighBenard/caseTwoDomeThreeWalls/system/topoSetDict.actions.sourceInfo"

The above error indicates that the problem is with p1. I haven't use the cylinderToCell before. But, have a look at it again.

Best regards,
Kumudu

[lramutti]

Hey Kumudu,

Thanks for your response. I believe cylinderToCell might not be the best command so I am currently trying the zoneToCell approach. It turns out that I may execute the topoSetDict but unfortunately new domains are created (i.e. domain4, domain5, etc). I don't quite understand why. It is not a matter of unit for sure. Since I am dealing with half a circle it seems to me that the zoneToCell command is not properly covering all the regions. Also, I cannot identify the location of these domains so it is hard to to say where exactly the problem is. Would you be able to help me out with that?

Thanks a lot,

Lucas

[Kumudu]

Originally Posted by lramutti

Hey Kumudu,

Thanks for your response. I believe cylinderToCell might not be the best command so I am currently trying the zoneToCell approach. It turns out that I may execute the topoSetDict but unfortunately new domains are created (i.e. domain4, domain5, etc). I don't quite understand why. It is not a matter of unit for sure. Since I am dealing with half a circle it seems to me that the zoneToCell command is not properly covering all the regions. Also, I cannot identify the location of these domains so it is hard to to say where exactly the problem is. Would you be able to help me out with that?

Thanks a lot,

Lucas

Hi Lucas,

When I first create my regions, I got the same kind of problem. Like making excess domains. It is not due to type of the topoSet dictionary. You can view the excess domain by using paraview. Give the command, paraFoam - touch All. I am not sure. But you can find it in the Allrun file. Then view each domain by loading one by one. Then check your blockMesh dictionary. And change the cell size and run again the topoSet regions. You will find the error eventually.

Best,
Kumudu

[lramutti]

Hey Kumudu,

Thanks for the input. Actually what I am trying to do is to break down my dome into a simpler geometry and trying to execute it. it seems that now I no longer have problems with the domains but instead this annoying message pops when I run the code. I have done some research but it is not clear what the problem is. What is the mystery behind this no finite volume options present?

Cheers

*** Reading solid mesh thermophysical properties for region rightWall

    Adding to thermos

Selecting thermodynamics package 
{
    type            heSolidThermo;
    mixture         pureMixture;
    transport       constIso;
    thermo          hConst;
    equationOfState rhoConst;
    specie          specie;
    energy          sensibleEnthalpy;
}

    Adding to radiations

Selecting radiationModel opaqueSolid
Selecting absorptionEmissionModel constantAbsorptionEmission
Selecting scatterModel none
    Adding fvOptions

No finite volume options present

Region: leftAir Courant Number mean: 0 max: 0
Region: rightAir Courant Number mean: 0 max: 0
Region: midAir Courant Number mean: 0 max: 0
Region: boxairDome Courant Number mean: 0 max: 0
Region: leftairDome Courant Number mean: 0 max: 0
Region: leftbottomWall Diffusion Number mean: 9.29329e-07 max: 1.22222e-06
Region: midbottomWall Diffusion Number mean: 1.0967e-06 max: 1.22222e-06
Region: rightbottomWall Diffusion Number mean: 9.29329e-07 max: 1.22222e-06
Region: leftWall Diffusion Number mean: 1.37417e-06 max: 2.44444e-06
Region: rightWall Diffusion Number mean: 1.37417e-06 max: 2.44444e-06
deltaT = 45000
End

[wyldckat]

Greetings to all!

@Kumudu: Sorry for taking so long to answer you, but I haven't had the time to look into your questions sooner.

Let's see...

Originally Posted by Kumudu

I want to run the chtMultiRegionFoam with different inlet temperature and velocity magnitudes at different times. For example, lets say I want to change the inlet temperature of the fluid region hourly so that heat load to the system will change hourly. Also, after 12 hours of circulating the water in the pipe, I want to stop the circulation by setting the velocity equal to zero and recirculate it again after another 12 hours . Is there any way that I could set these conditions easily ?

Let me think a bit... one way is to run the case for 1h and then change the BC manually or using changeDictionary, then changing "controlDict" for the new time.
But I think the easiest way would be to use a table based boundary condition. There was a couple of discussions on this topic sometime ago here: http://www.cfd-online.com/Forums/ope...lefile-bc.html - and here: http://www.cfd-online.com/Forums/ope...ixedvalue.html

Note: Be careful, because this feature of using data from a table means that it will interpolate between 2 time items on the list: http://www.openfoam.org/version2.1.0...conditions.php
Example:

uniformValue     table       
(       
    (  0   0.0)       
    (100  10.0)       
);

means that it will linearly interpolate all values from 0 to 10.0, for each respective time instance within the 0 to 100 iterations or seconds! So you'll need something like:

    inlet
    {
        type            uniformFixedValue;
        uniformValue     table       
        (       
            (  0   10.0)       
            (3599.999  10.0)       
            (3600  15.0)       
            (7199.999  15.0)       
        );       
    }

Of course this is possibly an excessive change, so you might want to be careful with abrupt changes between 2 contiguous time snapshots!

Originally Posted by Kumudu

Also, I have another question regarding run the chtMultiRegionFoam in parallel.

[...]

# Decompose
for i in water soil pipe Borehole
do
   decomposePar -region $i > log.decomposePar.$i 2>&1
done

# Run
runParallel `getApplication` 6

# Reconstruct
for i in water soil pipe Borehole
do
   reconstructPar -region $i > log.reconstructPar.$i 2>&1
done

But I got an error.

Knowing what error message you've gotten would make it a lot easier to diagnose! My guess is that your script is missing the first few lines that are usually present in the Allrun scripts, namely:

#!/bin/sh
cd ${0%/*} || exit 1    # run from this directory

# Source tutorial run functions
. $WM_PROJECT_DIR/bin/tools/RunFunctions

------------------

@Lucas:

Originally Posted by lramutti

What is the mystery behind this no finite volume options present?
[...]

    Adding fvOptions

No finite volume options present

[...]

It's an information only message, which indicates that there are "No finite volume options present" in the file "system/fvOptions"

When in doubt: run a similar tutorial case from OpenFOAM, to ascertain what's normal and what's not normal

Best regards,
Bruno

[Kumudu]

Originally Posted by wyldckat

Greetings to all!

@Kumudu: Sorry for taking so long to answer you, but I haven't had the time to look into your questions sooner.

Let's see...

Let me think a bit... one way is to run the case for 1h and then change the BC manually or using changeDictionary, then changing "controlDict" for the new time.
But I think the easiest way would be to use a table based boundary condition. There was a couple of discussions on this topic sometime ago here: http://www.cfd-online.com/Forums/ope...lefile-bc.html - and here: http://www.cfd-online.com/Forums/ope...ixedvalue.html

Note: Be careful, because this feature of using data from a table means that it will interpolate between 2 time items on the list: http://www.openfoam.org/version2.1.0...conditions.php
Example:

uniformValue     table       
(       
    (  0   0.0)       
    (100  10.0)       
);

means that it will linearly interpolate all values from 0 to 10.0, for each respective time instance within the 0 to 100 iterations or seconds! So you'll need something like:

    inlet
    {
        type            uniformFixedValue;
        uniformValue     table       
        (       
            (  0   10.0)       
            (3599.999  10.0)       
            (3600  15.0)       
            (7199.999  15.0)       
        );       
    }

Of course this is possibly an excessive change, so you might want to be careful with abrupt changes between 2 contiguous time snapshots!



Knowing what error message you've gotten would make it a lot easier to diagnose! My guess is that your script is missing the first few lines that are usually present in the Allrun scripts, namely:

#!/bin/sh
cd ${0%/*} || exit 1    # run from this directory

# Source tutorial run functions
. $WM_PROJECT_DIR/bin/tools/RunFunctions

------------------

@Lucas:

It's an information only message, which indicates that there are "No finite volume options present" in the file "system/fvOptions"

When in doubt: run a similar tutorial case from OpenFOAM, to ascertain what's normal and what's not normal

Best regards,
Bruno

Dear Bruno,

Many thanks for replying me. I will look into it carefully.

Best regards,
Kumudu

[jaydeep]

Hello everyone,

I have been trying to port the classic PlaneWall 2D case for the latest OF release. I am attaching the zip for all files. The case runs well, but in the end it throws a ton of errors on ParaView and results are in my opinion unrealistic.

Can somebody take a look at it and please let me know what all could be the probable causes ?


Thanks!

P.S. I use OF+ on windows, use native ParaView. Once the simulation is finished, you can open foam.foam file in PV for postprocessing.