[Thangam]

I have a strange issue when I use scalarTransportFoam when used with cases that have undergone mesh deformation. I have a case with a wall moving in 'y' and a cold inlet impinging onto the plate solved with pimpleDyMFoam. I have written out time directories at different wall positions. Now, I want to solve the temperature as a scalar on the wall which has uniform heat flux of 1500W/m^2 for all these different positions. At y=0, when the wall is stationary, the resulting temperature field is correct. When I invoke scalarTransportFoam for the next time step at a different location say, 'y+delta y', the temperature field is monotonously decreasing which is non-physical (less than the inlet temperature!). I used fixedGradient bc on the wall. I also have the U, phi, meshPhi and all the remaining fields in the respective time folders. I have attached the T file and the system directory. I have the polyMesh folder in the time directory which has the points file(since there is movement of points). Not sure where I am going wrong. I presume its a very basic solver and should solve the scalar for the given flow field.

[Thangam]

as an update to the issue, I guess the issue is with the 'phi' file. I just copied the 'phi' from the y=0 time directory and used it for the time directories that have undergone instead of their respective 'phi' and when I run scalarTransportFoam, the results are more meaningful. My understanding is that 'phi' on the wall should be zero anyway hence I used the same 'phi' across. But not sure if this is the right way to go about this. Why would the deformed 'phi' files produce non-physical temperatures? I am still missing something here!

[Thangam]

update:

The method in the post above is wrong since the conservation is on phi and not U. so I basically copied the flow field of my initial case onto the remaining directories! Now, the idea is to make phi relative to the mesh movement.
I tried to modify the scalarTransportFoam solver so that the scalar transport through a cell (meshPhi) is also taken into consideration. I tried to implement this following the mesh update method of pimpleDyMFoam. However, the problem still remains the same.
1) readControls.H looks up for correctPhi and checkMeshCourantNo by calling pimple.dict() which I dont require?
2) I am not sure if this actually completes the action of making phi relative to the mesh.
3) I have commented out correctPhi and its corresponding header file. since I am not sure if I need to do this. If I have to use it, I need to enable the readControls.H as well again going back to pimple dict.

So again to reiterate what I am trying to do:

I want to use scalarTransportFoam on a case which has undergone mesh movement with pimpleDyMFoam. I am trying to make scalarTransportFoam take into account the phi relative to the mesh since the flux through the cell due to mesh moving is non-zero in a completely stationary flow field. Any ideas where I am going wrong?

/*---------------------------------------------------------------------------*\
  =========                 |
  \\      /  F ield         | OpenFOAM: The Open Source CFD Toolbox
   \\    /   O peration     |
    \\  /    A nd           | Copyright (C) 2011 OpenFOAM Foundation
     \\/     M anipulation  |
-------------------------------------------------------------------------------
License
    This file is part of OpenFOAM.

    OpenFOAM is free software: you can redistribute it and/or modify it
    under the terms of the GNU General Public License as published by
    the Free Software Foundation, either version 3 of the License, or
    (at your option) any later version.

    OpenFOAM is distributed in the hope that it will be useful, but WITHOUT
    ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
    FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
    for more details.

    You should have received a copy of the GNU General Public License
    along with OpenFOAM.  If not, see <http://www.gnu.org/licenses/>.

Application
    dynamicscalarTransportFoam

Description
    Solves a transport equation for a passive scalar for meshes that have undergone deformation 

\*---------------------------------------------------------------------------*/

#include "fvCFD.H"
#include "simpleControl.H"
#include "dynamicFvMesh.H" // added due to the geometry/topology changing
#include "IObasicSourceList.H"

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

int main(int argc, char *argv[])
{
    #include "setRootCase.H" //sets the basic structure of the case folders
    #include "createTime.H" // for the runtime
//  #include "createMesh.H" // replaced by createDynamicFvMesh.H
    #include "createDynamicFvMesh.H" //added since this handles solid mesh displacements?
    #include "createFields.H"
    #include "initContinuityErrs.H"
    #include "readTimeControls.H"
  
    simpleControl simple(mesh);

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

    Info<< "\nCalculating scalar transport for dynamic meshes\n" << endl;
    
 while (runTime.run())
    {
//       #include "readControls.H" // problematic header file thats calling pimple dicts
         #include "CourantNo.H"
      
       // since the mesh moves, the flow moves relatively to the mesh. This statement makes the flux absolute for the following part of the code. Is used because at the end of the loop the flux is made relative

        fvc::makeAbsolute(phi, U);
    
       #include "setDeltaT.H"
    
       runTime++;
    
      mesh.update();
      
//        if (mesh.changing() && correctPhi) //i commented this out since mesh is not moving
//         {
//             #include "correctPhi.H"
//         }
//         
         fvc::makeRelative(phi, U);       //Fluxes are made relative.

//       if (mesh.changing() && checkMeshCourantNo) //same as above
//       {
//      #include "meshCourantNo.H"
//       }    
      
    while (simple.loop())
    {
        Info<< "Time = " << runTime.timeName() << nl << endl;

        while (simple.correctNonOrthogonal())
        {
            solve
            (
                fvm::ddt(T)
              + fvm::div(phi, T)
              - fvm::laplacian(DT, T)
            );
        }

        runTime.write();
    }
    
    }
    Info<< "End\n" << endl;

    return 0;
}


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

[wyldckat]

Greetings Thangam,

There is one particular detail that I can't understand from your description:

1. Are you trying to use only the last time step from the simulation that was executed with pimpleDyMFoam?
2. Or are you trying to use scalarTransportFoam to simulate on top of all existing time steps that have been provided by pimpleDyMFoam?
   • In other words, as if you were using scalarTransportFoam as a post-processing application for all time steps?

Best regards,
Bruno

[Thangam]

Originally Posted by wyldckat

Greetings Thangam,

There is one particular detail that I can't understand from your description:

1. Are you trying to use only the last time step from the simulation that was executed with pimpleDyMFoam?
2. Or are you trying to use scalarTransportFoam to simulate on top of all existing time steps that have been provided by pimpleDyMFoam?
   • In other words, as if you were using scalarTransportFoam as a post-processing application for all time steps?

Best regards,
Bruno

Hi Bruno,

1) I am trying to do point no.1 as mentioned in the above post. I have ran the case with pimpleDyMFoam and time averaged it. So I have one final case for which I need to use scalarTransportFoam to solve Temperature as a scalar for this flow field.

2) However, when I think about it now, scalarTransportFoam uses 'phi' for the conservation and it is immaterial whether I use time averaging or not it still uses phi from createPhi (unless of course modified ) which still reads in the instantaneous velocity through this line:

linearInterpolate(U) & mesh.Sf()

3) About the point 2 mentioned in the previous post, just curious, but shouldnt the same code work in both the cases? I will have to use the same deltaT as my original time step size of the computations isnt it?

4) Well, the other work around was to take pimpleDyMFoam and add the temperature equation which I did based on the example https://openfoamwiki.net/index.php/H...ure_to_icoFoam which solves the scalar transport just before the runTime.write(). I am running tests for this solver as I write this. (The obvious drawback being to re-run the entire simulation!!)


regards
Thangam.

[wyldckat]

Hi Thangam,

Only today did I finally manage to come around to look into this, but since it's been 2 months since the last post, I have to ask you first: Did you solve this issue?

I ask this because it would take me some considerable time to test and diagnose this myself... so I don't want to invest time into this if you've already solved this issue.

Best regards,
Bruno