Thanks for your reply.
As of today only way PBS exposes number of processors via “ncpus”. This a resource that can be set by admins to what ever value the find useful but by default pbs sets it to physical processor.
So while PBS accounts for ncpus as of today. It does not really allocates a cpu (physical/logical) to a job. Allocation is important for jobs because there might be some jobs that would not want to share computational resources (FPU) on a physical processor and there might be some that would find it okay to share the processor with its tasks.
PBS does not natively support this allocation of resources. This is to some extent possible to achieve by using hooks but then unless scheduler is aware of the allocation it may take some wrong decisions to place the job on a wrong node.
A job wants 4ncpus and its tasks to take up a thread on each core. Now if a node has 4 cores with 2 threads on it and admin has set the value of ncpus to number of threads (8) that are there on the system then PBS scheduler will see that this node has enough space to run the job and place the job there.
After this if another job comes in that wants 2ncpus and its tasks to be allocated on the same core then PBS scheduler may just place this job also on the same node because there were 4 ncpus free even though that node had no core totally free to be allocated to the job.
So the motivation behind writing the use cases was to get these problems addressed.
I hope I’ve not confused you