Stop to avoid exceeding time allocation.

Questions and remarks about code_saturne usage
Forum rules
Please read the forum usage recommendations before posting.
Post Reply
ffan
Posts: 66
Joined: Thu Jul 24, 2014 3:23 pm

Stop to avoid exceeding time allocation.

Post by ffan »

Dear Code_Saturne users and developers,

I used v4.0.4 in a calculation, it stopped prematurely and said:

** Stop to avoid exceeding time allocation.
----------------------------------------
maximum time step number set to: 36

What caused this stop? What is Code_Saturne's criterion to stop the job and to print out this message? How does it decide the maximum time step number to stop the job (in this case, 36)? Thanks.

- ffan
Yvan Fournier
Posts: 4070
Joined: Mon Feb 20, 2012 3:25 pm

Re: Stop to avoid exceeding time allocation.

Post by Yvan Fournier »

Hello,

Are you running under a batch system ?

Regards,

Yvan
ffan
Posts: 66
Joined: Thu Jul 24, 2014 3:23 pm

Re: Stop to avoid exceeding time allocation.

Post by ffan »

Hi Yvan,

It is a cluster system with a batch system but, for this case, I just ran it on the login node without sending it to batch run. When I got the case back to run on my workstation, it worked alright without stopping. It is strange that it stopped prematurely on the login node, but ran without a problem on my workstation.

- ffan
Yvan Fournier
Posts: 4070
Joined: Mon Feb 20, 2012 3:25 pm

Re: Stop to avoid exceeding time allocation.

Post by Yvan Fournier »

Hello,

There might be resource limits set on that node.

What does "ulimit -a" (on the login node) report ?

Regards,

Yvan
ffan
Posts: 66
Joined: Thu Jul 24, 2014 3:23 pm

Re: Stop to avoid exceeding time allocation.

Post by ffan »

Hi Yvan,

This message "Stop to avoid exceeding time allocation" is printed by Code_Saturne to the listing file. So, something must have caused Code_Saturne to determine that it needs to stop to avoid exceeding time allocation. What is that Code_Saturne detected and decided to stop. Is there an easy way to find out?

- ffan

------------------------------------------------------
Nb of reversal of the velocity at the wall : 0
Nb of faces within the viscous sub-layer : 22560
Total number of wall faces : 22560
------------------------------------------------------------


===========================================================
** Stop to avoid exceeding time allocation.
----------------------------------------
maximum time step number set to: 168
===========================================================
===============================================================
** Remaining time management
-------------------------
Remaining time allocated to the job : ', 3.68000e+02
Estimated time for another time step : ', 3.72449e+02
mean time for a time step : ', 1.89641e+01
time for the previous time step : ', 1.89033e+01
security margin : ', 3.53500e+02
===============================================================
Yvan Fournier
Posts: 4070
Joined: Mon Feb 20, 2012 3:25 pm

Re: Stop to avoid exceeding time allocation.

Post by Yvan Fournier »

Hello,

You did not answer my previous question, which is probably related to the answer...

Regards,

Yvan
ffan
Posts: 66
Joined: Thu Jul 24, 2014 3:23 pm

Re: Stop to avoid exceeding time allocation.

Post by ffan »

Hi Yvan,

The following. Thanks. - ffan


-bash-4.1$ ulimit -a
core file size (blocks, -c) 0
data seg size (kbytes, -d) unlimited
scheduling priority (-e) 0
file size (blocks, -f) unlimited
pending signals (-i) 63521
max locked memory (kbytes, -l) unlimited
max memory size (kbytes, -m) unlimited
open files (-n) 1024
pipe size (512 bytes, -p) 8
POSIX message queues (bytes, -q) 819200
real-time priority (-r) 10
stack size (kbytes, -s) 10240
cpu time (seconds, -t) 3600
max user processes (-u) 90
virtual memory (kbytes, -v) unlimited
file locks (-x) unlimited
C.FLAG.
Posts: 32
Joined: Fri Apr 08, 2016 2:19 pm

Re: Stop to avoid exceeding time allocation.

Post by C.FLAG. »

Hi,

The line "cpu time (seconds, -t) 3600" seems to indicate that you can not run your simulation on the login node for a long time.

The best thing to do is probably to run very short jobs on the login node or to move to the compute nodes.

Regards,
Cedric
Post Reply