saved data recomputation ....
 

hello

Is it possible to recompute a OpenFoam calculation to continue it?
If so, somebody knows how we can do that?

thank you

If you mean continuing from an existing calculation, then the entry
within the system/controlDict will do that. This also happens to be the default if the "startFrom" entry is completely missing. With this you can simply remove any unwanted time directories to define the latest time for a subsequent restart.

Is there any way to call this while my solver is running?

For example, I'm trying to implement variable deltaT (time step) and if I pick a deltaT that is too high and the solution starts to diverge, I want to restart my simulation based on the latestTime.

Any ideas on how to do this? I've tried using:

runTime.setTime(latestTime, latestTime)
where latestTime = the last stored solution.

When I do this, it does reset the time but it doesn't read the stored solution at latestTime, instead it restarts based on the solution that was previously diverging.

Ben, you could try using storeOldTime() and oldTime(). Or maybe you can find some other ideas in the following thread:
http://www.cfd-online.com/Forums/ope...-openfoam.html

Hmm, I thought that I could just reset the time, as I did above and then read in the stored data using:

when I do an Info << runTime.timeName() << endl; I get the proper time (ie, the old time that I'm trying to revert back to) but for some reason even this doesn't read in the old stored solution.

Ok, so I know what my problem is but I don't know how to fix it.

I detect whether my solution is diverging using a flag and if it's diverging i have:

The problem that I have is that this will read in the old solution correctly but it creates a new volScalarField that only exists within the if {} statement and not outside the if {} statement. It also creates a new volScalarField when all I want to do is replace the old one.

So one idea that I have is to read in the old solution into a temporary volScalarField and then copy the temporary field to the proper volScalarField. How do I copy the temporary volScalarField into my actual volScalarField?

akidess: I'm not sure how to use storeOldTime() and oldTime(). I tried something like:

scalar.storeOldTime()

but how do I then revert back to this old value?

I tried this: scalar = scalar.oldTime() but this doesn't seem to do anything.

I'm not too sure about the usage of oldTime either, I just stumbled across it in the code. I would have used it the same way you did (maybe an additional nOldTimes() to see if something was stored).

So if that doesn't work, your own approach seems promising. Can you maybe use

Again, I'm kinda just making guesses using the source guide, but I'm interested in your solution!

- Anton

Thanks for the suggestion. When I try the tmp<scalar> part I get the compiler error:

and when I try the scalar == old part I get:

It looks like I'll have to brush up on my C++ although I think this is actually an easy problem to solve.

I'm surprised that this sort of time control isn't more popular amongst foamers since it could dramatically reduce computation time by allowing large/dynamic time steps.

About the first error: We'll have to use a normal scalarField then instead of the tmp<scalar> field. I guess the performance impact won't be noticable anyways.

So did you try

and got an error on "=="? I don't see why that would lead to an error, but you can also see if a regular "=" works. The difference as I understand it is that "=" makes a copy of the field, while "==" will replace the field.

Most Foamers seem happy with the built in time control based on the Courant number. It's good enough for most of my own simulations.

Aha, that seems to have worked! (reading old solution into a new volScalarField and then using scalar == scalar_old). Thanks!

I don't have a Courant number because I don't have a momentum balance in my model (which is why I need to use my own method to control the time step).

Great! I was starting to run out of ideas ;)

I had an unstable case where the time adjustment based on the Courant number would lead to an oscillating time step and bad results, and I think a time step control similar to yours could help there as well. For more stable cases it can be a let-down that this method has no means to increase the timestep.

- Anton