CFD Online Discussion Forums

CFD Online Discussion Forums (https://www.cfd-online.com/Forums/)
-   OpenFOAM Running, Solving & CFD (https://www.cfd-online.com/Forums/openfoam-solving/)
-   -   Problems with startTime latestTime (https://www.cfd-online.com/Forums/openfoam-solving/60651-problems-starttime-latesttime.html)

Marco Kupiainen (Kupiainen) February 16, 2005 08:13

Where does runTime.writeObjec
 
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

Hrvoje Jasak (Hjasak) February 16, 2005 08:21

When you create each IOobject
 
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

Marco Kupiainen (Kupiainen) February 16, 2005 08:51

It seems that the program doe
 
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.

Mattijs Janssens (Mattijs) February 16, 2005 09:17

muSgs_.writeOpt() = IOobject:
 
muSgs_.writeOpt() = IOobject::AUTO_WRITE;

(haven't checked)

Mattijs

Eugene de Villiers (Eugene) February 16, 2005 09:41

This is weird, I wrote and ra
 
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.

Marco Kupiainen (Kupiainen) February 16, 2005 10:50

I'm using coodles with the 1-
 
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.

Mattijs Janssens (Mattijs) February 16, 2005 10:59

Maybe stupid question: do you
 
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

Marco Kupiainen (Kupiainen) February 16, 2005 11:07

This is how my controlDict lo
 
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

Marco Kupiainen (Kupiainen) February 16, 2005 11:14

While trying to make the code
 
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?

Eugene de Villiers (Eugene) February 16, 2005 11:19

The one-equation SGS model on
 
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.

Mattijs Janssens (Mattijs) February 16, 2005 11:22

turbulence->muSgs()().writeOp
 
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()

Marco Kupiainen (Kupiainen) February 16, 2005 11:40

Added turbulence->muSgs()
 
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.

Eugene de Villiers (Eugene) February 16, 2005 11:46

Curiouser and curiouser. I
 
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.

Hrvoje Jasak (Hjasak) February 16, 2005 11:53

Hmm, all of this should have
 
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

Henry Weller (Henry) February 17, 2005 19:19

B T U k muSgs muTilda p are t
 
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.

Marco Kupiainen (Kupiainen) February 18, 2005 02:52

It is looking for muSgs.
 
It is looking for muSgs.

Henry Weller (Henry) February 18, 2005 03:23

> I'm using coodles with the
 
> 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.

Henry Weller (Henry) February 18, 2005 03:48

I have just run coodles on th
 
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?

Marco Kupiainen (Kupiainen) February 18, 2005 07:22

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

Henry Weller (Henry) February 18, 2005 07:52

OK then it does appear to be
 
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.


All times are GMT -4. The time now is 13:02.