| 4 | | A job started by '''mrun''' will - according to its requested computing time, its memory size requirement and the number of necessary processing elements (on parallel computers) - be queued by the queuing-system of the remote computer into a suitable job class which fulfills these requirements. Each job class permits only jobs with certain maximum requirements (e.g. the job class {{{cdev}}} on the IBM Regatta "hanni" of the HLRN permits only jobs with no more than 7200 seconds required computing time and with using no more than 32 processing elements). The job classes are important for the scheduling process of the computer. Jobs with small requirements usually come to execution very fast, jobs with higher requirements must wait longer (sometimes several days).\\\\ |
| 5 | | Before the start of a model run the user must estimate how much CPU time the model will need for the simulation. The necessary time in seconds has to be indicated with the '''mrun option''' [[`-t`]] and has an influence on the job class into which the job is queued. Due to the fact that the model usually uses a variable time step and thus the number of time steps to be executed and consequently the time needed by the model is not known at the beginning, this can be measured only very roughly in many cases. So it may happen that the model needs more time than indicated for the option {{{-t}}}, which normally leads to an abort of the job as soon as the available CPU time is consumed. In principle one could solve this problem by setting a very generously estimated value for {{{-t}}}, but this will possibly lead to the disadvantage that the queued job has to wait longer for execution.\\\\ |
| | 4 | A job started by '''[../../tec/mrun mrun]''' will - according to its requested computing time, its memory size requirement and the number of necessary processing elements (on parallel computers) - be queued by the queuing-system of the remote computer into a suitable job class which fulfills these requirements. Each job class permits only jobs with certain maximum requirements (e.g. the job class {{{cdev}}} on the IBM Regatta "hanni" of the HLRN permits only jobs with no more than 7200 seconds required computing time and with using no more than 32 processing elements). The job classes are important for the scheduling process of the computer. Jobs with small requirements usually come to execution very fast, jobs with higher requirements must wait longer (sometimes several days).\\\\ |
| | 5 | Before the start of a model run the user must estimate how much CPU time the model will need for the simulation. The necessary time in seconds has to be indicated with the '''mrun''' option {{{-t}}} and has an influence on the job class into which the job is queued. Due to the fact that the model usually uses a variable time step and thus the number of time steps to be executed and consequently the time needed by the model is not known at the beginning, this can be measured only very roughly in many cases. So it may happen that the model needs more time than indicated for the option {{{-t}}}, which normally leads to an abort of the job as soon as the available CPU time is consumed. In principle one could solve this problem by setting a very generously estimated value for {{{-t}}}, but this will possibly lead to the disadvantage that the queued job has to wait longer for execution.\\\\ |
| 22 | | Only by the specification of {{{write_binary=true}}} the model is instructed to compute the remaining CPU time after each time step and stop, if the run is not going to be completed and finished briefly before expiration of this time. Actually the stop takes place when the difference from the available job time (determined by the '''mrun''' option {{{-t}}}) and the time used so far by the job becomes smaller than the time given by the model variable [../d3par#termination_time_needed termination_time_needed]. With the variable '''termination_time_needed''' the user determines, how much time is needed for binary copying of the data for restart runs, as well as for the following data archiving and transfer of result data etc. (as long as this is part of the job). Thus, as soon as the remaining job time is less than '''termination_time_needed''', the model stops the time step procedure and copies the data for a restart run to the local binary file [../iofiles#BINOUT BINOUT]. The so-called initialization parameters are also written to this file (see [[chapter 4.0]]). In a last step the model produces another file with the local name [[CONTINUE_RUN]]. The presence of this file signals '''mrun''' the fact that a restart run must be started and leads to the start of an appropriate job.\\\\ |
| | 22 | Only by the specification of {{{write_binary=true}}} the model is instructed to compute the remaining CPU time after each time step and stop, if the run is not going to be completed and finished briefly before expiration of this time. Actually the stop takes place when the difference from the available job time (determined by the '''mrun''' option {{{-t}}}) and the time used so far by the job becomes smaller than the time given by the model variable [../d3par#termination_time_needed termination_time_needed]. With the variable '''termination_time_needed''' the user determines, how much time is needed for binary copying of the data for restart runs, as well as for the following data archiving and transfer of result data etc. (as long as this is part of the job). Thus, as soon as the remaining job time is less than '''termination_time_needed''', the model stops the time step procedure and copies the data for a restart run to the local binary file [../iofiles#BINOUT BINOUT]. The so-called [../inipar initialization parameters] are also written to this file. In a last step the model produces another file with the local name [[CONTINUE_RUN]]. The presence of this file signals '''mrun''' the fact that a restart run must be started and leads to the start of an appropriate job.\\\\ |
