Yeah, I was struggling with tracing all the evaluation of expressions. Appreciated learning how functional principles work. This was really helpful. Thanks!

Short answer, replace

T[r_, s_, t_] := \[Theta] (T0 - Tm) + Tm

with

T[r_, s_, t_] = \[Theta] (T0 - Tm) + Tm

Explanation

SetDelayed (:=) holds the right hand-side unevaluated when it creates the DownValues. Set (=) does not, allowing the right hand side to be evaluated before it creates the DownValues. Let's walk through it, starting with

T[r_, s_, t_] := \[Theta] (T0 - Tm) + Tm

The DownValues looks like this

{HoldPattern[T[r_, s_, t_]] :> \[Theta] (T0 - Tm) + Tm}

Now let's evaluate a T with some arguments:

T[a, b, c]
(* All arguments get evaluated first, and they have no replacement rules, so we move on to T. *)
(* There's only one DownValues to check, and it does match, so we do a replacement *)
\[Theta] (T0 - Tm) + Tm
(* Now we evaluate this new expression, looking at OwnValues for each symbol... *)

The expression at this point is very complicated, so I won't reproduce it, but it does contain r, s, and t. But r, s, and t are just symbols, and they have no OwnValues, so they do not undergo further replacement. I think you're expecting that r should be replaced with a, s with b, and t with c. The problem is that a, b, and c were only necessary to do the first DownValues replacement. The evaluator was doing something like this

\[Theta] (T0 - Tm) + Tm /. {r -> a, s -> b, t -> c}

There are no occurrences of r, s, or t to replace, so nothing happened, and it moved on the next evaluation step.

When you evaluate T[r_, s_, t_] := ..., you are not setting up a procedure that has local variables defined on a stack. You are simply setting up a replacement rule so that if the pattern on the left is matched, it will be replaced with the (unevaluated) expression on the right. When you later evaluate T[1, 2, 3], every r in the right hand side gets replaced with 1, but this does not mean that there is some local variable r that has been bound to the value 1.

Now, if you had used Set instead,

T[r_, s_, t_] = \[Theta] (T0 - Tm) + Tm

then \[Theta], T0, and Tm would have been evaluated before updating the DownValues. Eventually, that leads to an expression involving r, s, and t. So, future evaluation of T[1,2,3] will result in the evaluator effectively doing <complicated expression> /. {r->1,s->2,t`->3}.

In practice, I find that using Set for creating DownValues can be a bit tricky, especially during the exploratory/experimental phase of development. I tend to do a bunch of little tests which end up polluting the Global context with a bunch of symbols, and every once in awhile I carelessly use one of these symbols in a Set expression both as argument pattern and in the right hand side. Then I get unexpected results trying to use the function I so defined. SetDelayed avoids this problem. Once everything has settled down, I could go back and replace gratuitous uses of SetDelayed with Set, but I tend not to.

Hmm, looks like you'll need to download the notebook to see the actual behavior of the Manipulate expressions.

Also, you mention that T depends on t and s(t), but you set up the Manipulate with s and t as independent variables. I'm not sure what you expect to happen here.

Yes, presently it is set as independant variables. I have only a graph and not an expression for this function, I was just manually inputting the values of s and t. But maybe I should approximate an expression for s. I will see how mathmematica can give me an expression if I give it a set of points (s,t). Thanks for this point.

No, that’s not how it works. Mathematica will fetch the DownValues/OwnValues of T when needed. It won’t speculatively look ahead to see if those DownValues/OwnValues might in turn depend on something before deciding to evaluate T. Also, in the Manipulate expression, s and t are local, so if T was defined outside of the Manipulate, those s and t variables won’t match anyway.