| 87 | | * The old configuration file {{{.mrun.config}}} has been split into two files {{{.palm.config.<configuration_identifier>}}} and {{{.palm.iofiles}}}, where {{{<configuration_identifier>}}} (short {{{<ci>}}}) is an arbitrary string that you can define. \\\\ "Configuration" means a setting for a specific computer with a specific compiler, compiler options, libraries, etc. \\ If you like to run '''PALM''' with different configurations, e.g. one with debug options switched on, and one with high optimization, you need to create separate files for each configuration, e.g. {{{.palm.config.optimized}}} and {{{.palm.config.debug}}}. This replaces the old block structure in {{{.mrun.config}}}. The configuration file to be used is defined by {{{palmrun}}}- or {{{palmbuild}}}-option {{{-h}}}., e.g. {{{palmrun ... -h optimized}}} will use {{{.palm.config.optimized}}}. You find examples of {{{.palm.config.<...>}}} files in your '''PALM''' copy under {{{.../trunk/SCRIPTS}}} \\\\ You will need only one file {{{.palm.iofiles}}} which contains the file connection statements to be used for all configurations. \\ The file attributes (second column in the file connection statements) have been partly changed. The second attribute, which was either {{{loc}}}, {{{locopt}}} or {{{job}}}, has been completely removed. Optional input files now require {{{inopt}}} as first attribute. Those input files to be send to the remote host require {{{tr}}} as second attribute (instead of {{{job}}}). {{{fl}}} and {{{flpe}}} must be changed to {{{ln}}} and {{{lnpe}}} respectively. \\\\ For output files, a wildcard {{{*}}} can be given as file activation string in the third column. In such a case, existing local output files will always be copied to their permanent position. No warning will be given if they do not exist. \\\\ Wildcards (*) are allowed for local names of output files (e.g. {{{BINOUT*}}}) and file extensions of input files (e.g. {{{_p3d*}}}). Using wildcards, only one file connection statement is required, e.g. for nested runs which require different input files for each domain ({{{_p3d, _p3d_N01, _p3d_N02}}}, etc.) or which generate different output files (e.g. {{{BINOUT, BINOUT_N01}}}, etc.). The additional extensions that are identified from the existing files (e.g. {{{_N01, _N02}}}) will be automatically added to the local filename (in case of input files) or to the file extension (in case of output files). \\\\ The utility program {{{interpret_config}}} has been removed. The configuration files are now directly interpreted by the shellscripts. |
| 88 | | |
| 89 | | * Only one call of {{{palmbuild}}} is required to compile for both the utilities and the PALM source code (there is no option {{{-u}}} anymore). The compiled routines (object files and executables) are put into folder {{{MAKE_DEPOSITORY_<configuration_identifier>}}}, where {{{<configuration_identifier>}}} equals the string given with {{{palmbuild}}}-option {{{-h}}}. |
| 90 | | |
| 91 | | * {{{palmrun}}} does not compile any more at the beginning of a batch job. The palm-executable for the batch-job (or for the interactive session) is created as part of the {{{palmrun}}}-call that you have manually entered at your terminal, and it is created before the batch-job is submitted. The executable is put into the folder {{{SOURCES_FOR_RUN_<run_identifier>}}}, where {{{<run_identifier>}}} is the string provided with {{{palmrun}}}-option {{{-d}}}. This folder is now put into the folder set with variable {{{fast_io_catalog}}} (see below for {{{fast_io_catalog}}}). If you do not use a user-interface, {{{palmrun}}} will not compile at all and will take the executable from folder {{{MAKE_DEPOSITORY_<configuration_identifier>}}} that has been generated with your last call of {{{palmbuild}}}. If {{{palmrun}}} cannot find the folder {{{MAKE_DEPOSITORY_<configuration_identifier>}}}, it will internally call {{{palmbuild}}} in order to generate it. If {{{palmrun}}} finds a folder {{{SOURCES_FOR_RUN_<run_identifier>}}} that has been generated by a previous call of {{{palmrun}}}, it will ask you if executables from that folder shall be used. This way, you can avoid to re-compile your user-interface with each call of {{{palmrun}}}. Automatically generated restart runs will always use executables from {{{SOURCES_FOR_RUN_<run_identifier>}}}. \\\\ You may have to remove folders {{{SOURCES_FOR_RUN_...}}} manually from time to time, because they are not deleted automatically at the end of a job (or the last job of a restart job chain). |
| | 87 | * The old configuration file {{{.mrun.config}}} has been split into two files {{{.palm.config.<configuration_identifier>}}} and {{{.palm.iofiles}}}, where {{{<configuration_identifier>}}} (short {{{<ci>}}}) is an arbitrary string that you can define. \\\\ "Configuration" means a setting for a specific computer with a specific compiler, compiler options, libraries, etc. \\ If you like to run '''PALM''' with different configurations, e.g. one with debug options switched on, and one with high optimization, you need to create separate files for each configuration, e.g. {{{.palm.config.optimized}}} and {{{.palm.config.debug}}}. This replaces the old block structure in {{{.mrun.config}}}. The configuration file to be used is defined by {{{palmrun}}}- or {{{palmbuild}}}-option {{{-c}}}., e.g. {{{palmrun ... -c optimized}}} will use {{{.palm.config.optimized}}}. You find examples of {{{.palm.config.<...>}}} files in your '''PALM''' copy under {{{.../trunk/SCRIPTS}}} \\\\ You will need only one file {{{.palm.iofiles}}} which contains the file connection statements to be used for all configurations. \\ The file attributes (second column in the file connection statements) have been partly changed. The second attribute, which was either {{{loc}}}, {{{locopt}}} or {{{job}}}, has been completely removed. Optional input files now require {{{inopt}}} as first attribute. Those input files to be send to the remote host require {{{tr}}} as second attribute (instead of {{{job}}}). {{{fl}}} and {{{flpe}}} must be changed to {{{ln}}} and {{{lnpe}}} respectively. \\\\ For output files, a wildcard {{{*}}} can be given as file activation string in the third column. In such a case, existing local output files will always be copied to their permanent position. No warning will be given if they do not exist. \\\\ Wildcards (*) are allowed for local names of output files (e.g. {{{BINOUT*}}}) and file extensions of input files (e.g. {{{_p3d*}}}). Using wildcards, only one file connection statement is required, e.g. for nested runs which require different input files for each domain ({{{_p3d, _p3d_N01, _p3d_N02}}}, etc.) or which generate different output files (e.g. {{{BINOUT, BINOUT_N01}}}, etc.). The additional extensions that are identified from the existing files (e.g. {{{_N01, _N02}}}) will be automatically added to the local filename (in case of input files) or to the file extension (in case of output files). \\\\ The utility program {{{interpret_config}}} has been removed. The configuration files are now directly interpreted by the shellscripts. |
| | 88 | |
| | 89 | * Only one call of {{{palmbuild}}} is required to compile for both the utilities and the PALM source code (there is no option {{{-u}}} anymore). The compiled routines (object files and executables) are put into folder {{{MAKE_DEPOSITORY_<configuration_identifier>}}}, where {{{<configuration_identifier>}}} equals the string given with {{{palmbuild}}}-option {{{-c}}}. |
| | 90 | |
| | 91 | * {{{palmrun}}} does not compile any more at the beginning of a batch job. The palm-executable for the batch-job (or for the interactive session) is created as part of the {{{palmrun}}}-call that you have manually entered at your terminal, and it is created before the batch-job is submitted. The executable is put into the folder {{{SOURCES_FOR_RUN_<run_identifier>}}}, where {{{<run_identifier>}}} is the string provided with {{{palmrun}}}-option {{{-r}}}. This folder is now put into the folder set with variable {{{fast_io_catalog}}} (see below for {{{fast_io_catalog}}}). If you do not use a user-interface, {{{palmrun}}} will not compile at all and will take the executable from folder {{{MAKE_DEPOSITORY_<configuration_identifier>}}} that has been generated with your last call of {{{palmbuild}}}. If {{{palmrun}}} cannot find the folder {{{MAKE_DEPOSITORY_<configuration_identifier>}}}, it will internally call {{{palmbuild}}} in order to generate it. If {{{palmrun}}} finds a folder {{{SOURCES_FOR_RUN_<run_identifier>}}} that has been generated by a previous call of {{{palmrun}}}, it will ask you if executables from that folder shall be used. This way, you can avoid to re-compile your user-interface with each call of {{{palmrun}}}. Automatically generated restart runs will always use executables from {{{SOURCES_FOR_RUN_<run_identifier>}}}. \\\\ You may have to remove folders {{{SOURCES_FOR_RUN_...}}} manually from time to time, because they are not deleted automatically at the end of a job (or the last job of a restart job chain). |
| 200 | 200 | * {{{ {{cpu_hours}}, {{cpu_minutes}}, {{cpu_seconds}} }}}: Will be replaced based on the total CPU time in seconds provided with {{{palmrun}}}-option {{{-t}}}, .e.g. {{{-t 3666}}} will replace {{{ {{cpu_hours}}=1, {{cpu_minutes}}=1, {{cpu_seconds}=6 }}}. |
| 201 | 201 | * {{{ {{nodes}} }}}: The number of nodes requested by the job. It will be replaced by the result of {{{ totalcores / ( noMPIt * noOpenMPt )}}}, where {{{totalcores}}} is the total number of cores as requested with {{{palmrun}}}-option {{{-X}}}, {{{noMPIt}}} is the number of MPI-tasks to be started on each node, as given my {{{palmrun}}}-option {{{-T}}}, and {{{noOpenMPT}}} is the number of OpenMP-threads to be started per MPI-task, as given by {{{palmrun}}}-option {{{-O}}}. |
| 202 | 202 | * {{{ {{tasks_per_node}} }}}: The number of MPI-tasks to be started on each node, as given my {{{palmrun}}}-option {{{-T}}}. |
