[amtri]

Hello,

I have a couple of questions regarding results files naming conventions:

1) I have seen models containing results files in the step "0" named, say, "a" and "a.org". The object type inside is "a". Can I safely assume that any file whose object does not match the file name can be ignored? If not, what is one to do when two independent files refer to the same object?

2) Along the same lines, I have cases where only file refers to a specific object; however, the object and the file names are not the same.

I'm trying to figure out what the rule is for accepting a file containing cell results - take it or ignore it. If somebody could clarify this I would appreciate it.

Thanks.

-amtri

[marupio]

1) The a.org file is like a back-up. a is the file it is reading from and writing to in later timesteps.

2) I don't understand what you mean.

Most of the time the files OpenFOAM uses for output can be found in the solver's createFields.H. Any GeometricField (e.g. volScalarField, volVectorField, etc...) with a constructor that takes an IOobject and a mesh will read from the file when it initializes. E.g.:

volScalarField variableName
(
    IOobject
    (
        // ... IOobject constructor options
    ),
    mesh
);

Also, note the IOobject details:

IOobject
(
    name,
    instance,
    [local],
    READ_OPTION,
    WRITE_OPTION
)

name = the filename
instance = the path (e.g. runTime.timeName() would be [case]/[timeValue]; constant() would be [case]/constant)
local = optional. an extension to the path. e.g. [case]/constant/localName
READ_OPTION = MUST_READ, READ_IF_PRESENT, or NO_READ - tells OpenFOAM if this file can be read.
WRITE_OPTION = AUTO_WRITE, NO_WRITE - this indicates whether the file is able to be written.

Not sure if I answered your question.

[amtri]

marupio,

Thanks for the response. I take it I wasn't clear enough when asking the question in the first place.

Also, these questions usually refer to the "0" state - the initial conditions. This is not surprising, since the user will usually put these files him/herself.

To be more precise, here is specific case:

I have a model where in directory "0" I have a file called "omega". However, the object type for this file is "epsilon" - as defined in the OpenFOAM header inside the file. So my question is: is this a valid file? Are there any rules whereby the results/initial conditions file name matches the name of the "object" entry in the file's OpenFOAM header?

If this is a valid file, then this brings up the question: in your response you stated that "a.org" is a backup file. How can I tell that? What if, rather than calling it "a.org" a user had called it "a.b", or "c"? At what point does OpenFOAM decide that this is just an extraneous file that the user added in the directory and it shouldn't bother with it?

Thanks.

[akidess]

OpenFOAM will only read files from the zero directory that were specified in createFields.H, as outlined by David. The other files will be ignored. In your case with a.org I'm guessing the file is used in a script that will reset a by copying a.org, then running setFields, and then running the solver (which then reads the newly set a file). What happens if the header specifies another object I'm not sure.

[marupio]

Originally Posted by amtri

marupio,
However, the object type for this file is "epsilon" - as defined in the OpenFOAM header inside the file. So my question is: is this a valid file? Are there any rules whereby the results/initial conditions file name matches the name of the "object" entry in the file's OpenFOAM header?

The header portion of the file is rarely used. Most of the time OpenFOAM just checks to see that the first word after the comments is "FoamFile". Sometimes it also checks the "class" field (I know Paraview does this), but I don't know of any instances where it takes input from the "object" field.

Likely what happened here was a file named epsilon was copied to produce the file for omega. It shouldn't have any effect.

Originally Posted by amtri

If this is a valid file, then this brings up the question: in your response you stated that "a.org" is a backup file. How can I tell that? What if, rather than calling it "a.org" a user had called it "a.b", or "c"? At what point does OpenFOAM decide that this is just an extraneous file that the user added in the directory and it shouldn't bother with it?

As Anton says, you can tell by looking at the createFields.H file for your solver to see what files it is expecting to see. Look for the IOobject names... that is the file name.

Hope that helps!

-Dave

[amtri]

Hmm... I think I'm starting to understand this. So maybe you can help me clear something.

The OpenFOAM database I'm looking at has the following files at step "0":

U
fixedInlet
frontBackUpperPatches
initialConditions
k
nut
omega
p
turbulentBoundaryField

Some of these files are included into others - and don't even an an OpenFOAM header in them. I'm not worried about them.

If I look in the controlDict file, the application is "simpleFoam".

I now go into the OpenFOAM directory

OpenFOAM-1.6.x/applications/solvers/incompressible/simpleFoam

and look at the file createFields.H

According to the file (please correct me if I'm wrong), there are 2 IOobjects, both MUST_READ: "p" and "U".

Does this mean I shouldn't read anything else?? How about the turbulence variables? I know they are important, because on subsequent steps they are written as output.

What am I missing?

Thanks million to both!

-amtri

[marupio]

One easy way to tell what it expects is to have an empty 0 directory and see what it complains about, adding one file at a time. You're right, it reads turbulence-related files, and those are buried a little deeper. The reason is: it depends on the turbulence model.

I believe it reads these when it executes this line:

    autoPtr<incompressible::RASModel> turbulence
    (
        incompressible::RASModel::New(U, phi, laminarTransport)
    );

This will read what turbulence model you specified in your constant directory, and load that one. For example, k-epsilon reads these files at src/turbulenceModels/RAS/incompressible/kEpsilon/kEpsilon.C

    k_
    (
        IOobject
        (
            "k",
            runTime_.timeName(),
            mesh_,
            IOobject::MUST_READ,
            IOobject::AUTO_WRITE
        ),
        mesh_
    ),

    epsilon_
    (
        IOobject
        (
            "epsilon",
            runTime_.timeName(),
            mesh_,
            IOobject::MUST_READ,
            IOobject::AUTO_WRITE
        ),
        mesh_
    ),

In fact, I believe all RAS turbulence models only require "k" and "epsilon" with the exception of Spallart-Alarmas (or however it is spelled), which also requires "nut".

Another thing, some files are created for *output*, and not necessarily *input*. If you look in your createFields.H, you'll see #include "createPhi.H". createPhi is another GeometricField named "phi" whose read and write are set to: READ_IF_PRESENT, and AUTO_WRITE. That means: if the file "phi" is present, it will read it, otherwise it will calculate it. This also means that when you perform a simulation, the file "phi" will show up in your results.

[amtri]

marupio,

Thanks for the explanations. But this is NOT pretty.

Isn't there a place in the documentation that tells me what is expected to be there? I cannot imagine that a user will have to wade through the source code to determine what to create for initial conditions.

I expected to see something like: "if application is ABC then...". Also, you are right that if I remove all files and see what OpenFOAM complains about will tell me what should be there; but it won't tell me what it could also optionally read IF it were there...

Section 3.5 of the User Guide has a list of all solvers. That's a good start. But somewhere there should be a list of all required and optional variables for each solver. Maybe this IS in the documentation, but not in as neat a fashion as I imagine.

Maybe someone can venture on how I can follow the threads to get this information?

Thanks.

-amtri

[mirko]

Originally Posted by amtri

marupio,

Thanks for the explanations. But this is NOT pretty.

Isn't there a place in the documentation that tells me what is expected to be there? I cannot imagine that a user will have to wade through the source code to determine what to create for initial conditions.

I expected to see something like: "if application is ABC then...". Also, you are right that if I remove all files and see what OpenFOAM complains about will tell me what should be there; but it won't tell me what it could also optionally read IF it were there...

... stuff deleted ...

Thanks.

-amtri

Regarding prettiness, beauty is in the eye of the beholder. Joking aside, in OF, the code IS the documentation. The sooner you get comfortable staring at the code, the better. Also take a look at the doxygen documentation. That will help you navigate the code.

OF developers don't have the time and resources to maintain a full-fledged documentation effort. We don't pay them enough for that

Mirko