[eric-meng]

Hey forumers,

I usually meet errors when I try to re-run my case with latestTime option in controlDict

1) sometimes the time folders are not exact as what it should be according to the set-up of writeControl and writeInterval, instead, it is of very close decimals

like 200 could be 199.9999999999

in this case, if you re-run you case you may be prompted that can not find p in 200, you have to rename 199.999999999 to 200 to keep running

2) another problem is

the writing to time folder has been aborted before complete information is put in, this situation comes when you try to stop your solver when it happens to be writing data in the time folder

so next time you run your case from this folder with lastestTime option, it won't run

you have to delete this folder to use the second latest time.

this is not a big problem unless you run your case in parallel on a supercomputer that has so many users so that you have to wait in a queue for 1-2 days to run you case.

are there any ideas that can ensure successfully consecutive running?

[piu58]

> like 200 could be 199.9999999999

That is because of the binary code floating points. No thing to worry about.


> are there any ideas that can ensure successfully consecutive running?

Set

runTimeModifiable yes;

in controlDict and don't finish with ^C but with setting endTime to a value not too far in the calculated future.

[LuckyTran]

1) You have to be careful with your writePrecision because there is a difference between 199.9999999999 vs 200.0000000000 vs 200.


2) Instead of using latestTime, you can use startTime and set the time of the 2nd latest folder. This saves you from having to manually delete the corrupted dir. Apart from that, I really don't get why you would intentionally stop the solver while it is writing... Just let it finish. If the queue time is so long, a few minutes should not hurt.

[eric-meng]

Originally Posted by LuckyTran

1) You have to be careful with your writePrecision because there is a difference between 199.9999999999 vs 200.0000000000 vs 200.


2) Instead of using latestTime, you can use startTime and set the time of the 2nd latest folder. This saves you from having to manually delete the corrupted dir. Apart from that, I really don't get why you would intentionally stop the solver while it is writing... Just let it finish. If the queue time is so long, a few minutes should not hurt.

Hi LuckyTran, thanks for your reply

I have tested before, it is not the reason of timePrecision, as to writePrecision, I think I have to keep it in a small level for the sake of storage space.

sometimes, it really prompts cant find p in 200, such that I have to rename 199.9999 to 200


I run my case in a supercomputer the time is not control-able to me

anyway I have to use some shell commands to re-run my case now, meanwhile the latestTime folder will be deleted automatically every time

[eric-meng]

Originally Posted by piu58

> like 200 could be 199.9999999999

That is because of the binary code floating points. No thing to worry about.


> are there any ideas that can ensure successfully consecutive running?

Set

runTimeModifiable yes;

in controlDict and don't finish with ^C but with setting endTime to a value not too far in the calculated future.

Hi piu58, sorry for late reply


your suggestion for my second question is very good, I will try it


while for the first one, this may still cause unusual stop for my case... hope the naming of time folder can be optimised in the future

Thank you