Could you define "not that good"? Residual plots depend on the script you have used for plotting, on a simulation, on the final aim of your simulations.

Pictures you have posted: 1e-2 for pressure, usually it is not enough.

Foam::error::printStack(Foam::Ostream&) with interDyMFoam -parallel
 

Dear All,

I am using interDyMFoam solver for raceway pond hydrodynamic simulation with water at the bottom and air above. As you may know raceway pond, it is circulating flow channel with a rotating paddle-wheel as source of momentum. The solver runs in parallel(HPC) perfectly for my mesh in its native form. I then added scalar transport by setting spherical numerical tracer material in the water phase using setFields. Based on the information I got on the site https://www.openfoam.com/documentati...Transport.html, I have added a function on the controlDict that integrates scalar transport of material with the main solver. I have also added some lines of codes on fvSolution and fvScheme to introduce the transported material. The simulation goes on up to a certain time (8.6 seconds) and crash with the following error. I appreciate if you could help me to solve this problem. For your reference I have attached the files of my case.

Foam::error::printStack(Foam::Ostream&) with interDyMFoam -parallel
 

Dear All,

If the attachments in my previous post are not so convenient, I put them again in the code below adding setFieldsDict and dynamicMeshDict and . As you can see the error startd at writing the scalar transport output.

Best regards,

error message,

controlDict

fvSchemes

fvSolution

boundary

setFieldsDict

dynamicMeshDict

Hi,

You can try starting with a change. This

into this

You have copied certain settings from alpha solver, which are not quite applicable to A.

Foam::error::printStack(Foam::Ostream&) with interDyMFoam -parallel
 

Dear Alexeym,

I thank you so much for your answer. I changed the fvSolution as you suggested only changing,
preconditioned DILU;
by
preconditioner DILU;

But another error shown below is facing me, which I couldn't solve. Kindly asking your help again.

Best regards,

fvSolution

error

Foam::error::printStack(Foam::Ostream&) with interDyMFoam -parallel
 

Dear Alexeym,

Sorry to bother you. I had been trying to continue the run from the latestTime of the previous setting. I restarted from 0 removing the previous decomposition and it is running now. I may contact you in case I need you help.

Thank again.

Best Regards

Teddy M.

Well, in fact, the cause of new error is the same: your mass transfer solver diverges. Since you like relaxation so much, you can start relaxing A-equations also.

Also, it is not quite clear: you use fvSchemes settings for quite non-orthogonal mesh (limiting non-orthogonal correction, cellLimited grad schemes) and in your fvSolution there is 0 non-orthogonal correctors.

You use fixed number of outer correctors, you relax all equations (even on Final iteration), you do not check your solution convergence. Are you sure, your results have anything to do with reality?

scalarTransport
 

Dear Alexeym,

Upon your comment, I took some time to study what the code does behind and try to see how good it represents reality. In single-phase simulation (simpleFoam), the numerical result is fitting very well with the experimental tracer data on the same pilot. The "scalarTrasnport" function also runs smoothly in multiphase (interDyMFoam for water and air) in OpenFOAM 5. The numerical trace material is defined by "setField" (sphereToCell) inside the water phase. The result shows the tracer material is clearly transported and diffused but not constrained in the water phase only rather it is also dispersed in the air phase, which is not the reality. I found a tutorial in another version, OpenFOAM v-1812 that restricts the tracer in one phase. The problem in this version is that the trace is not moving. It only diffuses locally outward from its original center. Do you know if there is a way to constrain the transport of trace in one phase in OpenFOAM 5 or other versions?

Thanks in advance,

Teddy M

Hi,

Could you be more clear with versions? You have found tutorial for ESI version of OpenFOAM and tried to use the same settings for Foundation OpenFOAM?

Your scalar being only diffused means that MULES compressed flux is zero. And this can be incompatibility between version. So can you elaborate on the way you are trying to limit your tracer to one phase?

scalarTransport
 

Dear Alexeym,

Thanks again for your reply. Let me try to be very clear.
I have both versions installed, from the Foundation (OF-5) and ESI (OF-v1812). I run the tutorial "waterChannel" on OF-v1812, where I originally found and the description of this tutorial states that passive scalar transport of tracer is phase constrained. I see in the result the tracer is distributed only in the water phase. But, since the tracer injection manner is "volumeMode", I couldn't see whether it is transported or not. I used "setField" rather, to inject the tracer and run again. In this case, the trace is only diffusing from the injection center defined by setField. Below is the line of code for MULES in "scalarTransport.C" of this version of OF. I am not sure if the 0 corresponds to phi.

if (bounded01_)
{
MULES::explicitSolve(s, phi, tTPhiUD.ref(), 1, 0);
}

I used the same geometry and setFieldDict to run on OF-5 from the foundation. This time the tracer is diffusing and also being transported along the flow direction to the outlet. But tracer material is found in the air phase too. In the real experiment, we inject tracer in the water phase and it is bounded in water only.
MULES is not called in "scalarTransport.C" of OF-5.

Teddy M

Hi,

This term is responsible for convection of the scalar:

(fragment you have posted bounds scalar in [0; 1] range, and 0 is lower bound).

So, if your scalar is not convected, then limitedPhiAlpha is zero. It is looked up like this:

phasePhiCompressedName_ by default is alphaPhiUn, it is created in createFields.H of, for example, interFoam and should be updated by MULES. Why in your simulation this flux is not updated? I do not know. Guess, additional context could be useful. Maybe you even can start NEW thread with corresponding question.

scalarTransport
 

Dear Alexeym,

I truly appreciate your explanation as it gives me some insight to further explore. I will search for a possible solution and will post here also if it can help others.

Best regards,

Teddy M.

scalarTransport
 

Dear Alexeym,

I just introduced [ phasePhiCompressed alphaPhi0.water; ] inside the function attached at the bottom of the controlDict, as shown below and re-run the simulation. The tracer is now constrained in the water phase and also convected well in the flow direction. I have a screenshot attached that shows the difference with the previous case, where phasePhiCompressed is alphaPhiUn by default as you said, after 6 seconds of simulation.
alpha.water is the same for both cases at all times.
Could you please check if this is the right way to modify for the solver to handle the convection?


Best regards,

Teddy M

Teddy,

I know this post has been a while but I will reply anyhow.

"phaseScalarTransport" is not implemented until OpenFOAM 7.0. If you use scalarTransport in OpenFOAM 5.0, the scalar will transport to the whole domain.

The "phaseScalarTransport" (in the OpenFOAM org version) is the "scalarTransport" in the ESI-OpenFOAM that enabled through "phase".

In addition, the phasePhiCompressed is defined with alphaPhiUn as the default as pointed out by Alex. However, I observed the same problem that using alphaPhiUn the scalar will not be convicted. I export the alphaPhiUn during the simulation. alphaPhiUn is zero. I also can not find anywhere the interFoam solver would pass a value to alphaPhiUn.

Meanwhile, if the alphaPhi0.water is used as the flux, partial of the scalar will be trapped at the old position where water used to be. I am actively addressing this issue.

Here is what I found so far. It looks like the OpenFOAM ESI v2006 has not completely implemented the phase contained transport. The OpenFOAM 8 implement the phase contained transport for VOF-like solver with addition estimation of the flux.
The flux is estimated as:

Now, I am going to imitate the OpenFOAM 8 implementation in an ESI solver and see what happens. Will update.


Thanks,
Rdf

An ad-hoc solution that I found for this problem.

https://www.cfd-online.com/Forums/op...gle-phase.html