CFD Online Logo CFD Online URL
www.cfd-online.com
[Sponsors]
Home > Forums > Software User Forums > OpenFOAM > OpenFOAM Running, Solving & CFD

ScalarTransport not transporting scalars anymore after using createPatch

Register Blogs Community New Posts Updated Threads Search

Reply
 
LinkBack Thread Tools Search this Thread Display Modes
Old   September 8, 2020, 13:45
Default ScalarTransport not transporting scalars anymore after using createPatch
  #1
Member
 
Tom Lauriks
Join Date: Apr 2020
Posts: 34
Rep Power: 6
Tom Lauriks is on a distinguished road
Hi foamers,


I’m using simpleFoam for the flow field and scalarTransport for the transport of pm10 (and some other scalars). I modified simpleFoam, to include my scalars in the recognized fields. The model is simulating wind flow around buildings and dispersion of pollutants, which are emitted from ventilation shafts from some of the buildings and also flowing into the domain at the inflow.


This setup was working just fine, until I changed my model a bit. I added patches with createPatch. (I divided to bottom surface in a couple of parts. These are all walls, but the different parts have different roughnesses). CreatePatch creates the patches from faceSets created with topoSet. After adding these additional patches, the flow field is still calculated correctly, but the the scalars not anymore.


The following is observed in paraview when checking pm10: At the boundaries where the wind is flowing into the domain, I imposed a concentration of pm10, 23 µg/ m3. If the emissions from the building were to be ignored, at steady state the concentration in the entire domain should hence be 23 µg/m3. However, there is no dispersion from the boundary into the domain. Except at the boundary, the concentration in the entire domain is zero. Another thing that isn’t right, is the following: The concentration at the inflowing boundary is correct, when I select the interpolated values for pm10. But when I select the non-interpolated values, the concentration at the inflowing boundary is also zero.


I rechecked my boundary conditions and everything seems fine. I use decomposePar and run in parallel. Something a bit illogical is happening after decomposing, but this doesn’t seem to be causing my problem. In 0 in the case dir, my boundary conditions seem OK. In 0 in the processor directories, sometimes the concentration at the inflowing boundary is set to zero and sometimes not. I checked and this is also the case in the previous working version of the model. I therefore assume, that in processor maps that do not contain faces of the inflow, the concentration at the inflow is set to zero. I find this a bit inconsistent, but I do not think that this is causing my problem.


Anyone any ideas on what is causing this? I’ll add some relevant code below.


The commands given to OF:
Code:
foamCleanTutorials
 blockMesh  
 checkMesh > log.meshBM
 cp system/decomposeParDict.ptscotch system/decomposeParDict
 decomposePar
 cp system/snappyHexMeshDict.castAndSnap system/snappyHexMeshDict
 mpirun -np 6 snappyHexMesh -parallel -overwrite
 mpirun -np 6 checkMesh -parallel -latestTime > log.meshCastSnap
 reconstructParMesh -constant
 topoSet -dict system/topoSetDictRoughness #dict containing code to create faceSets for patches
 createPatch -overwrite
 decomposePar -force
 #compiling the solver
 cd ~/OpenFOAM/toml-6/applications/solvers/simpleFoamScalarTransport
 wmake
 #go back to case dir
 cd /home/toml/openfoam/work_of6/steendok/hpc_files/SD_all_pollutants_windSW_37.5degrees_biggerGeometry_SS_addRoughness_2
 
 
 mpirun -np 6 simpleFoamScalarTransport -parallel > log
Part of pm10 dict in 0 in the case dir:
Code:
/*--------------------------------*- C++ -*----------------------------------*\
 | =========                 |                                                 |
 | \\      /  F ield         | OpenFOAM: The Open Source CFD Toolbox           |
 |  \\    /   O peration     | Version:  6                                     |
 |   \\  /    A nd           | Web:      www.OpenFOAM.com                      |
 |    \\/     M anipulation  |                                                 |
 \*---------------------------------------------------------------------------*/
 FoamFile
 {
     version     2.0;
     format      ascii;
     class       volScalarField;
     object      pm10;
 }
 // * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //
 
 
 dimensions      [1 -3 0 0 0 0 0];//[M(kg) L(m) T(s) Theta(K) n(mol) l(A) (cd)]
 
 
 internalField   uniform 0;
 
 
 boundaryField
 {
     side_right//inlet
     {
         type            fixedValue;
 	value		uniform 23e-9;
     }
    
     side_front//inlet
     {
         type            fixedValue;
 	value		uniform 23e-9;
     }
Part of pm10 dict in 0 in the processor0 dict:
Code:
/*--------------------------------*- C++ -*----------------------------------*\
   =========                 |
   \\      /  F ield         | OpenFOAM: The Open Source CFD Toolbox
    \\    /   O peration     | Website:  https://openfoam.org
     \\  /    A nd           | Version:  6
      \\/     M anipulation  |
 \*---------------------------------------------------------------------------*/
 FoamFile
 {
     version     2.0;
     format      binary;
     class       volScalarField;
     location    "0";
     object      pm10;
 }
 // * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //
 
 
 dimensions      [1 -3 0 0 0 0 0];
 
 
 internalField   uniform 0;
 
 
 boundaryField
 {
     side_front
     {
         type            fixedValue;
         value           nonuniform  
 0
 ;
     }
     side_right
     {
         type            fixedValue;
         value           uniform 2.3e-08;
     }
p { margin-bottom: 0.1in; line-height: 115% } a:link { so-language: zxx }
Tom Lauriks is offline   Reply With Quote

Old   October 30, 2020, 13:35
Default Modified simpleFoam is causing the problem
  #2
Member
 
Tom Lauriks
Join Date: Apr 2020
Posts: 34
Rep Power: 6
Tom Lauriks is on a distinguished road
In fact, it turned out that the modification of simpleFoam causes the scalars not to be transported anymore.



When I use the modified simpleFoam version (simpleFoamSTno2pm10), the scalars are not transported. When I use the original simpleFoam solver, the scalars are transported.

However, I would like to use the modified version. Anyone any ideas on what I'm doing wrong in modifying the solver? These are the modifications:

1) The modified solver is stored in the map simpleFoamSTno2pm10.

2) simpleFoam.C was renamed to simpleFoamSTno2pm10.C
3) In createFields.H, the fields were added, e.g.:
Code:
Info<< "Reading field pm10\n" << endl;
volScalarField pm10
(
    IOobject
    (
        "pm10",
        runTime.timeName(),
        mesh,
        IOobject::MUST_READ,
        IOobject::AUTO_WRITE
    ),
    mesh
);
4) Make/files was modified as follows:

Code:
simpleFoamSTno2pm10.C
EXE = $(FOAM_USER_APPBIN)/simpleFoamSTno2pm10
5) Before using the solver, in the solver dir simpleFoamSTno2pm10, wmake was executed. Then in the model dir, the solver is started as follows: simpleFoamSTno2pm10 > log
Tom Lauriks is offline   Reply With Quote

Reply

Tags
boundary condition error, createpatch, scalartransport, toposet


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


Similar Threads
Thread Thread Starter Forum Replies Last Post
scalarTransport pez OpenFOAM Post-Processing 5 March 29, 2016 11:49


All times are GMT -4. The time now is 14:13.