[anja]

Hi,

does someone know, where I can get basic information on the coodles solver, as there no links in the UserGuide?

Thanks a lot,
Anja

[eugene]

Your best bet would be inspecting the source code. What kind of information were you looking for?

[anja]

I don't know how to set the initial variables, e.g. muSgs and muTilda.
Furthermore I get error messages concerning the laplacian schemes.

[eugene]

I take it you are using the coodles tutorial case as a template?

muSgs and muTilda are just nuSgs and nuTilda multiplied by the density.

Use the fvSchemes and fvSolution dictionaries from the coodles tutorial case. If you still have problems, please post the error messages here.

[anja]

Yes, I do use the tutorial as a template.

Error for example:
Non-optional dictionary entry 'laplacian(nu,U)' not found in dictionary .../system/fvSchemes::laplacianSchemes in file .../system/fvSchemes::laplacianSchemes

[hjasak]

Works out of box for me. The laplacian schemes section is as follows:

laplacianSchemes
{
default none;
laplacian(muEff,U) Gauss linear corrected;
laplacian((rho*1|A(U)),p) Gauss linear corrected;
laplacian(alphaEff,h) Gauss linear corrected;
laplacian(DkEff,k) Gauss linear corrected;
laplacian(DBEff,B) Gauss linear corrected;
laplacian(DmuTildaEff,muTilda) Gauss linear corrected;
}

Incodentally, when you hit messages like this, feel free to edit the offending dictionary to get it to work. In your case, I would add something like:

laplacian(nu,U) Gauss linear corrected;

into the appropriate secton and try again. Hope you can follow my idea.

Hrv

[eugene]

Yeah, but if you are running coodles, there should be no need to define laplacian(nu,U).
More info please.

[anja]

I also had to add:
laplacian(1|A(U),p)Gauss linear corrected;

But now it's saying:
Invalid boundary type name 'pressureTransmissiveOutlet'

[anja]

Okay, I'm so so sorry. I made a mistake in the ControlDict, which was not a problem with coodles at all.

But here is the next one, I try to postprocess my results with paraFoam and then:
FOAM FATAL IO ERROR:wrong token type - expected scalar found on line 36 the word 'nan'

What does that mean?

[anja]

There might be a problem with the 'Courant number'.

The tutorial for the lid-driven cavity flow says, that to achieve temporal accuracy and numerical stability when running icoFoam, a Courant number of less than 1 is required.

But which number is required for using coodles?

[eugene]

nan means "not-a-number". This means youre calculation has blown up and written some nonsence to file.

Max courant number for standard coodles should also remain below 1. Preferrably below 0.7-8'ish.

[anja]

I tried to set Co=0.75, but all I get during the calculation is:
Mean and max Courant Numbers = nan nan
time step continuity errors : sum local = nan, global = nan, cumulative = nan
time step continuity errors : sum local = nan, global = nan, cumulative = nan
bounding k, min: 0 max: 0 average: 0

Does someone have any suggestion why this happens?

Thanks a lot for the help,
Anja

[anja]

Or can someone please explain me, what B for the initial variables of the coodles means?

Thanks again,
Anja

[fabianpk]

It is the term form filtering the Navier stokes equations, you can take a look at the H file of the LES model you are using to see its exact definition. For example /OpenFOAM/OpenFOAM-1.2/src/LESmodels/compressible/oneEqEddy/oneEqEddy.H

B = 2/3*k*I - 2*nuEff*dev(D)

/Fabian

[eugene]

B is only needed as initial condition when you are using a Reynolds stress SGS model. It represents the SGS stresses.

On the rest, keep making your timestep smaller. If that doesnt eventually work, you have problems with your boundary conditions.

[melanie]

Hi,

I want to run a coodle calculation from a simpleFoam result, as an initial guess of the flow. I copied the case and made the adequate corrections in the system files, but there is still something wrong as I get the error message:

--> FOAM FATAL ERROR : dimensions of phi are not correct

From function CrankNicholsonDdtScheme<type>::fvcDdtPhiCorr
in file finiteVolume/ddtSchemes/CrankNicholsonDdtScheme/CrankNicholson

I suppose that the trouble comes from the compressibility, but I don't find where to set the dimension of phi.
Could someone give me a hint ? Thanks !
mélanie

[gschaider]

If you open the file with the phi-data, just below the header before the line internalField you'll find a line "dimensions" with 7 numbers (Which number corresponds to which SI-unit is documented in the Programmer's Manual).

BUT: most solvers (don't know about coodle, never worked with that) calculate phi from U and rho if they don't find it in the initial time-step. So you might as well remove phi from the ICs and start the simulation.

[grtabor]

phi will be one of the fields in the timestep directory that you are starting from; the dimensions are contained in the header. Alternatively just delete the file; coodles should recalculate it during startup if it can't find it.

Gavin

[melanie]

Thanks for your answers; I looked in the time directory and did not find the phi file, but I forgot to mention what's in the log-file:

Create mesh for time = 0

Reading thermophysical properties
Selecting thermodynamics package hThermo<pureMixture<constTransport<specieThermo<hC onstThermo<perfect
Gas>>>>>

Reading field U
Reading/calculating face flux field phi

Creating turbulence model
--> FOAM Warning :
From function cubeRootVolDelta::calcDelta()
in file cubeRootVolDelta/cubeRootVolDelta.C at line 54
Case is 2D, LES is not strictly applicable

Creating field DpDt

Starting time loop
Time = 5e-07

Mean and max Courant Numbers = nan nan

As the same case is running well with oodles (exactly the same except the application and thermophysical properties), I think it does not come from LES.
Thanks !
mélanie

[grtabor]

Looks like you must have changed _something_ as the code is now starting up, albiet with a problem with the Courant number. Why are you trying to run an LES case in 2d?

The courant numbers are evaluated in
src/cfdTools/compressible/CourantNo.H - have a look there to figure out why you are generating NaN's. Looking at what is there, my guess is that there is something wrong with your rho field; since

surfaceScalarField SfUfbyDelta =
mesh.surfaceInterpolation::deltaCoeffs()*mag(phi)/fvc::interpolate(rho);

and this is on the bottom it could be screwing things up.

Gavin