|
[Sponsors] |
ScalarTransport not transporting scalars anymore after using createPatch |
|
LinkBack | Thread Tools | Search this Thread | Display Modes |
September 8, 2020, 13:45 |
ScalarTransport not transporting scalars anymore after using createPatch
|
#1 |
Member
Tom Lauriks
Join Date: Apr 2020
Posts: 34
Rep Power: 6 |
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 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; } 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; } |
|
October 30, 2020, 13:35 |
Modified simpleFoam is causing the problem
|
#2 |
Member
Tom Lauriks
Join Date: Apr 2020
Posts: 34
Rep Power: 6 |
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 ); Code:
simpleFoamSTno2pm10.C EXE = $(FOAM_USER_APPBIN)/simpleFoamSTno2pm10 |
|
Tags |
boundary condition error, createpatch, scalartransport, toposet |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
scalarTransport | pez | OpenFOAM Post-Processing | 5 | March 29, 2016 11:49 |