Physical thread is a term that I don't care for, but it refers to an operating system thread, aka a real thread or simply just a thread. An thread is an element of a user-level process (aka a running program of an application).
In the abstract, a thread represents a process resource, and this resource is tracked and managed by operating system (similarly, open file handles represent process resources tracked by the operating system).
(There are threads that run solely within the operating system: here when I speak to threads I'm evoking those running in a user process.)
The operating system is aware of threads (since it create them upon request), and, threads are eligible for time slices of available CPUs. The operating system scheduler manages the threads in terms of the available processors. (Requests for CPU time slices are manifest in the threads themselves; thread creation is the request for scheduling of time slices.)
A part of the operating system scheduler will analyze prioritization and fairness, and perform context switching, so when it determines that another thread is more eligible to run than one currently running, it will swap the running one out by saving any necessary CPU context to memory in the operating system's data structure associated with that thread, and restore the CPU context from (the memory data structure for) the other thread in order to let the processor resume that other thread.
Typically, the scheduler performs this analysis on events, such as
external device input that is destined for a thread (keyboard input on thread that is doing a read operation, disc io that was previously requested is ready, network packet of interst arrived...)
the thread itself issues a command that blocks, such as a read request
the clock/timer goes off signaling to the operating system the passage of time.
any other external event (interrupt) or command issued by a thread (syscall) allows the operating system to re-evaluate priorities
(There are a number of clever data structures inside the operating system to make the analysis of what thread to run next easier to do.)
The processor participates in context switching under command of the various parts of the scheduling and interrupt handling portions of the operating system. While modern processors offer multiple simultaneously executing CPU cores, it is basically the operating system that does context switching, not the processor context switching itself (at least not directly; operating system parts perform context switching by giving the processor appropriate sequences of machine code instruction programming).
However, beyond threads, there are many other ways of handling the management and scheduling of work or jobs that needs to be done. These other approaches somehow make use of threads, and the way they do can vary. Many approaches run within a single user process, (e.g. within a process that is running a program of some application).
One mechanism is to maintain a queue of work or jobs to be done, and perhaps run each job to completion using a single thread. Nominally, an element on such a queue might refer to a function or method to run (to call) to execute the job. As one job is completed, the application's work queue handler takes another job from the queue to run on the thread.
Other programs (like those that use the runtime execution engine of Java, C#, etc.. as well as those using some library packages for C) similarly manage queues of work to be done. Some use multiple threads to consume work from their work queues. This allows a certain concurrency in that one job doesn't have to be run to completion before another one can be started. Such mechanisms have various names such as N:1 threads, MxN threads, green threads.
There are also message queues, buses, or brokers; In some sense, we can think of a message as job, and thus message queue as a job queue. Also, there are batch scheduled jobs, and time-scheduled work, as in cron.
As with green threads, these mechanisms are not necessarily seen by the operating system (as anything more than a thread in a process), and thus, their jobs are not necessarily considered during the operating system's scheduling of threads.
(Operating system threads tend to have higher overhead than application-level job queues, which makes the lighter weight mechanisms often preferred. Using numerous threads that perform blocking I/O is sometimes thought of as wasteful, since a blocking thread has the full cost of an thread but isn't doing any work while blocked.)
When the jobs on application work queues take a generic form, some call these jobs logical threads. Sometimes these are also referred to as tasks. In some sense, tasks or jobs are higher level in that are more representative of domain- and/or user-oriented work to be done, whereas (physical) threads are more raw compute resources offered by the operating system.