[immortality]

Hi all
I wondering is there a way to track two parts of flow without need to use two phase solvers or combustion solvers or particle solvers.
its simply " I have a inflow patch and need a lot to know if the inflowing fluid has reached to outflow patch or not.
something like a color! maybe alpha in multi phase solvers(but not that approach preferably by compressible solvers like rhoPimpleFoam)
to give more information if is important to answer the case is a rectangular tube with one inflow and one outflow patch)
can it be done simply?
I don't know what search for if there is this subject somewhere in internet.I can't obtain anything.
----------------
to dear Bruno : if this question is sufficiently high rated then give me a rep power( I know it as reply power )

[wyldckat]

Hi Ehsan,

It took me a while to find this thread: http://www.cfd-online.com/Forums/ope...g-gas-gas.html
I vaguely knew/remembered what I was looking for... ended up finding it with the following string in Google:

site:cfd-online.com openfoam track fluid

In essence, the methodology to be used is similar to this tutorial: http://openfoamwiki.net/index.php/Ho...ure_to_icoFoam - but instead of tracking the distribution of temperature, you want to track where a particular part of fluid went to... although right now I can't figure out what should exactly be done to achieve what you to do.

The following thread I found by searching by "age of air openfoam", because I remember reading about it as well: http://www.cfd-online.com/Forums/ope...n-age-air.html

Best regards,
Bruno

[sail]

as Bruno suggested, adding the scalar transport in the solver and initializing the solution with a certain value of the scalar at the inlet should definitely do what you are looking for.

I would reccomand using the setFields tool to put the scalar where you want it at time 0.

[immortality]

(excuse me for repeating from another thread hoping get help more quickly)
Its the first time I modify a solver to solve for a new equation.
then could you please guide me through.
I've added this in createFields:

volScalarField age
    (
        IOobject
        (
            "age",
            runTime.timeName(),
            mesh,
            IOobject::MUST_READ,
            IOobject::AUTO_WRITE
        ),
        mesh
    );

is this the only change should I do in createFiels.H or some other lines?

in the folder of solver I have to add this:

// --- Scalar Transport
	volScalarField DTEff = DT+turbulence->muEff()/0.7;
	tmp<fvScalarMatrix> AgeEqn
	(
	 fvm::ddt(rho,Age) + fvm::div(phi, Age)   == dimensionedScalar("AgeSource", Age.dimensions()*dimensionSet(1,-3,-1,0,0), 1) //- fvm::laplacian(DTEff, Age)
	);
	
	AgeEqn().relax();
	
	sources.constrain(AgeEqn());
	
	AgeEqn().solve();

I changed all T's(in here:http://www.cfd-online.com/Forums/ope...tml#post372624) to Age.should delete the laplacian term,correct?
and what should be assign for DT?also change nut to mut(since my case is compressible,unsteady) correct?
(does it work if I switch to a turbulent case too?)
thanks.

[immortality]

hello again
I run the case but gas(scalar transport value) is not between 0 and 1 as the snapshot.
how to resolve?
thanks.
my gasEquation.H is:

// --- Scalar Transport
    //volScalarField DTEff = DT+turbulence->muEff()/0.7;
    tmp<fvScalarMatrix> gasEqn
    (
     fvm::ddt(rho,gas) 
             + fvm::div(phi, gas)
                -fvm::Sp(fvc::div(phi), gas)
                      - fvm::laplacian(turbulence->muEff(), gas)
                         //== dimensionedScalar("AgeSource", Age.dimensions()*dimensionSet(1,-3,-1,0,0), 1)
    );
    
    gasEqn().relax();
    
    //sources.constrain(AgeEqn());
    
    gasEqn().solve(mesh.solver("gas"));

[immortality]

scalar variable that i named it "gas" varies since minus values till about 400 and beyond that.while i have set boundary conditions 0 and 1 in inlets.
Why no guidance is there?

[wyldckat]

Ehsan,

Without an example case and instructions to reproduce what you are getting, all I can say is this - Study the scalarTransportFoam tutorial: http://openfoamwiki.net/index.php/ScalarTransportFoam

Best regards,
Bruno

[immortality]

hi.this is the equation I put there.the case is like shock tube.

tmp<fvScalarMatrix> gasEqn
    (
     fvm::ddt(rho,gas) 
             + fvm::div(phi, gas)
                -fvm::Sp(fvc::div(phi), gas)
                      - fvm::laplacian(turbulence->muEff(), gas)
    );
    
    gasEqn().relax();

.
thanks.

[wyldckat]

Seriously?

I guess I should have been clearer : I need a complete example case where I simply need to compile the solver or utility, including a pre-prepared example case.
Then I just have to figure out what could be wrong.

[immortality]

I had tried to send the modified solver but it exceeds from 97.7KB limit.
could you please give me your email to send it?

[wyldckat]

Originally Posted by immortality

I had tried to send the modified solver but it exceeds from 97.7KB limit.

Run wclean in the folder where the solver code is. It will remove the object files that are created during the build process. Said objects are stored inside the "Make/linux*" folder(s).
This way the final tarball/zip will be reduced to 30-60 kB, since it will only contain the source code files.

[immortality]

ok .these are new solver and the sample case.
thank you for helping.

[ngj]

Hi Ehsan,

I had a quick look on your case (without running it, as I do not have groovyBC), and is it correct that you are trying to fill a box? As I see it, you only have one open boundary and you are imposing a velocity, which is in the same direction for all boundary faces on this boundary?

Kind regards,

Niels

[immortality]

Hi dear Niels
where were you?!
are you fine?
yes.its a simple backward step as you has seen.my real case is unsteady and I wanted to test a situation when the inlet width is constant.
early times were important to me to see why velocity values are high in the corner of backward step and also to examine the groovyBC boundary conditions correctness.
could you please have a look into it if I send you a like case without groovyBC to see why velocities should be so high in the corner?
thanks.

[immortality]

Its a totalPressure,totalTemperature case(the same case without groovyBC) if you could look into it.
a shock originates and moves to right when it reaches to right wall it reflects back and therefore no problem occurs if we continue running in time.
and another thing I remembered to say.
does anyone know an experimental or DNS run for a backward step(sharp corner) case with subsonic inlet gas(compressible)?
thanks.

[wyldckat]

Originally Posted by immortality

ok .these are new solver and the sample case.
thank you for helping.

OK, in my limited experience, I can only figure out that there are few problems here:

1. This is a compressible scenario, which means that it's very easy for the scalar to compress into certain regions, therefore increasing the value far above 1.0.
2. There is currently no control for the DT factor. But still, I'm not certain that this would help much. The value would probably need to either be very high or scale accordingly to the "U" value.
3. The "rho" and "U" fields travel far faster than the "gas" field. This suggests that the scalar is diffusing too much and staying behind for too long.
4. Even if we look for very small values of the "gas" field, in the order of 1e-15, it still looks like it didn't reach the outlet fast enough.

Since I don't know the solution, I would suggest restarting from scratch

If it were me, I would do the following steps:

1. Switch to an incompressible solver.
2. Simplify the case, by having a simple 2D tube (with no back-step), so that I would know the analytical solution.
3. Implement the scalar transport until it works as intended.
4. Keep the same simple case and adapt the compressible solver.
5. Perform the same test with the same case and the compressible solver.
6. Then change the case gradually to increase the pressure differences and relative speed ratios. Always keep in mind what the analytical solution should be, since it's a simple 2D tube.
7. Once things are working as intended with the 2D tube, switch to the back-step case you provided. If all goes well, it should travel correctly this time.

Sorry I couldn't be of much more help on this case, but this not very simple to solve, specially with my level of experience in CFD

[immortality]

whats your opinion about deleting convection or diffusion terms?or emit rho from gas equation?

[immortality]

I have changed the formula to be calculated incompressible.

tmp<fvScalarMatrix> gasEqn
    (
     fvm::ddt(gas) 
             + fvm::div(phi/rho, gas)
                -fvm::Sp(fvc::div(phi), gas)
                      - fvm::laplacian(turbulence->muEff(), gas)
                         //== dimensionedScalar("AgeSource", Age.dimensions()*dimensionSet(1,-3,-1,0,0), 1)
    );
    
    gasEqn().relax();
    
    //sources.constrain(AgeEqn());
    
    gasEqn().solve(mesh.solver("gas"));

but this error occus:

         -lfiniteVolume -lfluidThermophysicalModels -lspecie -lrhoCentralFoam -lcompressibleTurbulenceModel -lcompressibleRASModels -lcompressibleLESModels -lmeshTools -lOpenFOAM -ldl   -lm -o /home/ehsan/OpenFOAM/root-2.2.0/platforms/linux64GccDPOpt/bin/rhoCentralFoamModified
+ wmake rhoCentralDyMFoam
make: `/opt/openfoam220/platforms/linux64GccDPOpt/bin/rhoCentralDyMFoam' is up to date.
root@Ehsan-com:~/Desktop/rhoCentralFoamModified# ./Allwmake
+ wmake libso BCs
'/opt/openfoam220/platforms/linux64GccDPOpt/lib/librhoCentralFoam.so' is up to date.
+ wmake
Making dependency list for source file rhoCentralFoamModified.C
SOURCE=rhoCentralFoamModified.C ;  g++ -m64 -Dlinux64 -DWM_DP -Wall -Wextra -Wno-unused-parameter -Wold-style-cast -Wnon-virtual-dtor -O3  -DNoRepository -ftemplate-depth-100 -IBCs/lnInclude -I/opt/openfoam220/src/finiteVolume/lnInclude -I/opt/openfoam220/src/thermophysicalModels/basic/lnInclude -I/opt/openfoam220/src/thermophysicalModels/specie/lnInclude -I/opt/openfoam220/src/turbulenceModels/compressible/turbulenceModel -I/opt/openfoam220/src/dynamicMesh/lnInclude -I/opt/openfoam220/src/meshTools/lnInclude -IlnInclude -I. -I/opt/openfoam220/src/OpenFOAM/lnInclude -I/opt/openfoam220/src/OSspecific/POSIX/lnInclude   -fPIC -c $SOURCE -o Make/linux64GccDPOpt/rhoCentralFoamModified.o
In file included from rhoCentralFoamModified.C:246:0:
gasEqn.H: In function ‘int main(int, char**)’:
gasEqn.H:6:37: error: no matching function for call to ‘div(Foam::tmp<Foam::Field<double> >, Foam::volScalarField&)’
gasEqn.H:6:37: note: candidates are:
/opt/openfoam220/src/finiteVolume/lnInclude/fvmDiv.C:45:1: note: template<class Type> Foam::tmp<Foam::fvMatrix<Type> > Foam::fvm::div(const surfaceScalarField&, const Foam::GeometricField<Type, Foam::fvPatchField, Foam::volMesh>&, const Foam::word&)
/opt/openfoam220/src/finiteVolume/lnInclude/fvmDiv.C:62:1: note: template<class Type> Foam::tmp<Foam::fvMatrix<Type> > Foam::fvm::div(const Foam::tmp<Foam::GeometricField<double, Foam::fvsPatchField, Foam::surfaceMesh> >&, const Foam::GeometricField<Type, Foam::fvPatchField, Foam::volMesh>&, const Foam::word&)
/opt/openfoam220/src/finiteVolume/lnInclude/fvmDiv.C:77:1: note: template<class Type> Foam::tmp<Foam::fvMatrix<Type> > Foam::fvm::div(const surfaceScalarField&, const Foam::GeometricField<Type, Foam::fvPatchField, Foam::volMesh>&)
/opt/openfoam220/src/finiteVolume/lnInclude/fvmDiv.C:88:1: note: template<class Type> Foam::tmp<Foam::fvMatrix<Type> > Foam::fvm::div(const Foam::tmp<Foam::GeometricField<double, Foam::fvsPatchField, Foam::surfaceMesh> >&, const Foam::GeometricField<Type, Foam::fvPatchField, Foam::volMesh>&)
createFields.H:11:23: warning: unused variable ‘T’ [-Wunused-variable]
/opt/openfoam220/src/finiteVolume/lnInclude/readTimeControls.H:32:12: warning: unused variable ‘adjustTimeStep’ [-Wunused-variable]
/opt/openfoam220/src/finiteVolume/lnInclude/readTimeControls.H:35:8: warning: unused variable ‘maxCo’ [-Wunused-variable]
/opt/openfoam220/src/finiteVolume/lnInclude/readTimeControls.H:38:8: warning: unused variable ‘maxDeltaT’ [-Wunused-variable]
make: *** [Make/linux64GccDPOpt/rhoCentralFoamModified.o] Error 1

[wyldckat]

Hi Ehsan,

From what I saw yesterday, the "rho" field seemed to travel too fast. It's possibly due to a shock wave travelling faster than the fluid. Therefore, simply dividing "phi" by "rho" could possibly be catastrophic...

This is why I suggested starting from an incompressible solver and then evolving gradually towards a compressible solver, always taking into account an analytical solution, in order to validate the decisions made in the implementation of said passive scalar.

As for "div" complaining about "phi/rho": I don't know if OpenFOAM allows certain calculations to be done directly inside the "div" operator. And the error you got seems to be related to the result of "phi/rho" not being a standard field.

Best regards,
Bruno

[immortality]

Hi all
I wondering is there a way to track two parts of flow without need to use two phase solvers or combustion solvers or particle solvers.
its simply " I have a inflow patch and need a lot to know if the inflowing fluid has reached to outflow patch or not.
something like a color! maybe alpha in multi phase solvers(but not that approach preferably by compressible solvers like rhoPimpleFoam)
to give more information if is important to answer the case is a rectangular tube with one inflow and one outflow patch)

I tried this code but scalar(I named it gas) isn't between 0 and 1 while internalField of gas is 0 in initial time and inlet boundary condition is fixedValue1.
the case is unsteady and compressible as its clear

     tmp<fvScalarMatrix> gasEqn     (      fvm::ddt(rho,gas)               + fvm::div(phi, gas)                 -fvm::Sp(fvc::div(phi), gas)                       - fvm::laplacian(turbulence->muEff(), gas)     );          gasEqn().relax();