It depends on how your new systems will be used and what type of license you have. If you have a “User-Locked Node-Locked” license, then you need a license for each user and hostid that you a compiling on. If you have a “Node locked” license, the compilers can be installed on a single system but be used by N number of concurrent users. A “floating” license will allow compilation from any host and only limits the number of concurrent users.
There is no restriction on the number of cluster nodes that your resulting binaries are run. There is a restriction on number of OpenMP or auto-parallization (-Mconcur) threads. Below is a full explaination of these restrictions.
From the information you have given, I’m assuming you have a “Node-locked” license, in which I believe you would need to purchase an additional license for the new cluster with the exact number of users dependant upon the number of concurrent users you have. It might be beneficial to move to a floating license. However, please contact firstname.lastname@example.org since they will have the details about your account and will be able to better help. Please include your PGI PIN number.
From our sales department:
PGI license limits for multi-processing or multi-threaded programs
depend on whether the compiler or the user is controlling/managing
the multi-threaded or multi-process components.
An example of a multi-process application is a cluster application.
mpirun -np N a.out
will be allowed to run on any number N processes, regardless of the
PGI license used. Each process has its own memory space
and transfers information to other processes via message
passing libs like mpi. Users do this usually.
The exception to this is pghpf programs, where the control of
the program execution is generated by the compiler, and not
via user coding. For pghpf, a limit of 8 processes is integrated
at compile time for a Workstation license, and 16 for a CDK license.
An example of a multi-threaded is openmp (-mp) or
auto-parallelization (-Mconcur). All threads shared the same memory
space, and such applications run on multi-cpu boards that share
memory. PGI software creates private and shared areas in the memory
so the threads do not step on each other, while working on their
‘piece’ of the multi-threaded task.
The overhead of starting and controlling a thread makes running
more threads than total cpu cores impractical, so we assume any
discussion is about using the same number of threads as cpu cores.
The current release, 6.2-5 has increased the cpu socket minimum to 8.
If your current 6.2 license has the VENDOR_STRING=543210:4, for example, you should regenerate your license to see VENDOR_STRING=543210:8. This is only available to current release license holders.
This minimum will also transfer to any application linking a shared library that is compiled with such a license. If the user compiles
an application with a current license, the limit in the license (if
greater than 8, like CDK or SERVER floating licenses) will be imposed.
If the lib is statically linked, the limit in the main will supersede
the limit in the library.
What is meant by ‘cpu sockets’ is meant as follows. If you run a multi-threaded application created using -Mconcur or -mp when compiling,
you are limited as follows
- 8 threads on a machine with 8 single core cpus
- 16 threads on a machine with 8 dual core cpus
- 32 threads on a machine with 8 quad core cpus