Where does runTime.writeObjects() look for what to write to file? I am currently trying to keep running a case from the latest time I computed, but discovered that the variables needed in initial data
B muSgs muTilda
are not saved. Where does one control what variables are saved in each timestep?

best regards
Marco

When you create each IOobject you need to specify the properties which include NO_WRITE or AUTO_WRITE.

For example:

Info<< "Reading field U\n" << endl;
volVectorField U
(
IOobject
(
"U",
runTime.timeName(),
runTime,
IOobject::MUST_READ,
IOobject::AUTO_WRITE
),
mesh
);


If you want things to be written with runTime.writeObjects(), find where they are created and specify IOobject::AUTO_WRITE.

Alternatively, set the auto-write on IOobject (see the appropriate header) using the writeOpt() member.

Enjoy,

Hrv

It seems that the program doesn't do what it is supposed to do:
in e.g. ..../src/LESmodels/compressible/GenEddyVisc.C

...
muSgs_
(
IOobject
(
"muSgs",
runTime_.timeName(),
runTime_,
IOobject::MUST_READ,
IOobject::AUTO_WRITE
),
mesh_
)
...
the AUTO_WRITE is on, but still no output. Similarily with the other variables I am looking for. You mentioned something with setting the auto-write on IOobject using the writeOpt() member. How does one do this in practice?
M.

muSgs_.writeOpt() = IOobject::AUTO_WRITE;

(haven't checked)

Mattijs

This is weird, I wrote and ran that LES code and it worked fine originally; I have the results to prove it.

What model are you running? I know of none that will solve for muSgs, muTilda and B as you seem to imply. Only Spalart-Allmaras will dump mutilda and only ReynoldsStress will dump B. What code did you use to compute the latest time? I suspect it wasnt the same code with the same LES models that you are trying to restart.

Note, oodles and coodles use different variables.

I'm using coodles with the 1-eqn model. It needs B and muSgs and muTilda in order to start.
This is also the same code I'm trying to restart.

Maybe stupid question: do you have your writeInterval set? writeObjects() only dumps changed variables and only if the writeInterval time has come.

If you want to force it just add it to coodles.C just before the writeObjects call.

Mattijs

This is how my controlDict looks like:
applicationClass coodles;

startFrom latestTime;

startTime 0;

stopAt endTime;

endTime 1;

deltaT 1e-07;

writeControl timeStep;

writeInterval 100;

cycleWrite 0;

writeFormat ascii;

writePrecision 6;

writeCompression uncompressed;

timeFormat general;

timePrecision 6;

runTimeModifiable yes;


but

h04n05:~>ls 0/
B T U k muSgs muTilda p
h04n05:~>ls 5e-05/
T U U_0 k k_0 p p_0 phi phi_0 rho rho_0 time
The other variables are printed, but not the turbulence model variables...

Marco

While trying to make the code force writing by adding

muSgs.writeOpt() = IOobject::AUTO_WRITE;
muTilda.writeOpt() = IOobject::AUTO_WRITE;
B.writeOpt() = IOobject::AUTO_WRITE;

runTime.writeObjects();
to the coodles.C. However muSgs, muTilda and B are undefined giving rise to compiling errors...
coodles.C(73): error: identifier "muSgs" is undefined
muSgs.writeOpt() = IOobject::AUTO_WRITE;
^

coodles.C(74): error: identifier "muTilda" is undefined
muTilda.writeOpt() = IOobject::AUTO_WRITE;
^

coodles.C(75): error: identifier "B" is undefined
B.writeOpt() = IOobject::AUTO_WRITE;
^
What to do?

The one-equation SGS model only needs muSgs and k to restart. Check GenEddyVisc.C which is the base class for oneEqEddy. FoamX just creates all the possible fields a SGS model could use, thats why they appear in your starting time directory.

Change
writeControl timeStep;
writeInterval 10;

In your controlDict to write out data after 10 timesteps.

turbulence->muSgs()().writeOpt() = IOobject::AUTO_WRITE;

So
- get the muSgs field from the turbulence model
- use an extra bracket pair to get access to the raw volScalarField
- apply writeOpt()

Added

turbulence->muSgs()().writeOpt() = IOobject::AUTO_WRITE;

and now the code compiles, but to no vein. Problem still persists :-(

h04n05:~>ls 0/
B T U k muSgs muTilda p
h04n05:~>ls 1e-07/
T U k p p_0 phi rho time
h04n05:~>ls 2e-07/
T U U_0 k k_0 p p_0 phi phi_0 rho rho_0 time


I have already looked in the ..../src/LESmodels/compressible/GenEddyVisc.C

and everything is correct there. I really don't have any clues any more. There is something wrong with the code anyway, so much is clear to me.

Curiouser and curiouser.

If what Mattijs suggets doesnt work (the object was created using AUTO_WRITE after all), you can write the file using a more brute-force approach:

Near the bottom of your top level code put:

if(runTime.outputTime())
{
turbulence->muSgs()().write();
}

The real question is: "why is it not working in the first place?" All the code seems to be in order.

Hmm, all of this should have worked first time anyway and it's not too surprising that AUTO_WRITE; did not do the trick. I don't fancy digging through it myself but this is what you do:

switch on database debugging in ~/.OpenFOAM-1.0/controlDict:

database 1;

in the DebugSwitches section. Database will now tell you everything. :-)

I have checked the oodles tutorial and all is well (that's worth doing on your installation as well.

My guess is that due to a cock-up there are two IOobjects with the same name nuSgs, which messes up the database.

A progress report would be nice :-)

Hrv

B T U k muSgs muTilda p are the fields FoamX writes out but not all are used, it depends on the choice of model. e.g. muTilda is only used by SpalartAllmares and hence is not written by during the code run unless you choose the SpalartAllmares model. So everything should be fine for restarting, is that the case? What missing fields is the code looking for during restart?

There will however be a problem running FoamX on the timesteps dumped by the code because it will expect these extra fields. The simple way out of this problem is to copy the missing fields (which are not used by the code) to the from the 0 directory to the timestep of interest. We will look into this limitation of FoamX in the future.

It is looking for muSgs.

> I'm using coodles with the 1-eqn model. It needs B > and muSgs and muTilda in order to start.

Are you sure it needs all these three in order to start? muTilda is only used by the SpalartAllmares and you say you are running the 1-eq model.

I have just run coodles on the tutorial case and I get k k_0 muSgs p p_0 phi phi_0 rho rho_0 T time U U_0 dumped in the time directories and the restart is fine. The problem you are seeing appears to be a platform-dependent database registration failure. We have never seen such a problem on Linux but something possibly similar happened on the Itanium machine using the Intel compiler. What platfor and compiler are you using?

It is an Itanium 2 platform, using Intel compiler
icpc 8.1.026 with -gcc-version=330 flag.

OK then it does appear to be the problem seen before which is associated with the Intel compiler optimiser for the Itanium 2. I might be able to find a work-around but it might be better if you use gcc-3.4.3 instead which we know produces an exectuable which runs correctly on the Itanium 2.