NDSolve and {C, K, Slot} and other built-ins as a variable name

Question

The following problem is an exploration of what causes the error "Input is not an ordinary differential equation" in Mathematica as it seems to have changed from version 8 to version 9.

Specifically I have found that in Mathematica 9 I have come across the issue that

NDSolve[{x'[t] == 5, C'[t] == 5, x[0] == 1, C[0] == 1}, {x, C}, {t, 0, 100}]

gives the error, whereas in version 8 it does not. So something is up, but my question has more to do with if this is a bug in v8 or a bug in v9, that is, I get that C is a built in symbol: so is this error a correct catching of an input mistake? If so then

NDSolve[{C'[t] == 5, C[0] == 1}, C, {t, 0, 100}]

Should also give an error and it does not.

I really want to understand what is possibly going on, since as an ecologist I have to deal with equations that have C in them for "consumer" and I am forced to troubleshoot any issues that might come up with people not understanding the shadowing issue.

Clarification

It has been pointed out that it is bad coding style to use user defined symbols that start with a capital letter, as this will avoid clashes with Mathematica built-in definitions. That is fine, but does that matter?

What I am trying to ask more generally is whether the issue is that Mathematica is specifically checking for C and related symbols in NDSolve? Because I have no problems using symbols that have existing UpValues/DownValues as variable names (upper or lowercase) and even Protected in the exact same context.

What I want to try and understand is are there semantic reasons that this fails, ie could I cause the same error with user generated code? Or is this just a hard coded one off that Wolfram is doing for this case?

Further Clarification

If this is just an issue of using built-ins why can I use C in Solve and even DSolve! if it is an error in NDSolve? Again seems more and more like a specific check in NDSolve. For example

 DSolve[{x'[t] == 5, C'[t] == 5, x[0] == 1, C[0] == 1}, {x, C}, t]

Gives back an answer ... so suddenly this same input string is valid ODE again?

Now there are other built-ins that have this behavior such as K and Slot. As a challenge to all that would just tell me to code differently (which I do ... this is a question of why Mathematica works this way) can you use any of the reasons that you given to make a user defined symbol that will trigger the same error? If not then I will conclude that Mathematica is specifically checking for such symbols and move on. But I want to be totally clear that this is not just a question about coding style but if there are differences between system symbols and user defined symbols in this context. What if I make a package that has defined symbols in it, will I ever be able to cause the same problem if a naive user shadows some of my imported symbols into their global context?

One interesting suggestion is that somehow NDSolve is introducing C or K or Slot when it processes the input and that is causing errors. If so then I should never be able to create this problem with user defined symbols, but I do not yet know if this is the correct idea.

Answer 1

The symbol C is reserved for undetermined constants. From its documentation:

C[i] is the default form for the i^th parameter or constant generated in representing the results of various symbolic computations.

This means even though it has no values, C can be introduced by other functions at any time, and also it might be interpreted in specific ways by various functions. Now, I can't tell you very specifically why it works in one case and not the other. My guess would be that in trying to bring the equation into a normal form, NDSolve attempts an integration or a solve which introduces another C into the equation, and then it can no longer deal with the system. In the case with only one dependent variable this doesn't happen, and so it works by chance. But in general, you're tempting fate by using C as input to the solver, be it NDSolve, DSolve, Solve, Reduce, or any of their related functions.

Also, since, say, UpValues has no such interpretation, you can probably use it safely inside of NDSolve. That still doesn't mean that's a good idea.

Answer 2

This is not really an answer but most likely a related issue.

During my working with this issue, I think I've stumbled with another system symbol (even a set of them, since small variation of its name cause the same problem).

And this one doesn't start with an UpperCase...

The only difference between the two codes are the variables' names volume and acc

a = 80;
le = 62;
g = 9.8;
tf = 200;
b = 3.4;
r = 5.86/le;
ppa = 32*22;


ClearAll[h, t, x, u, acc, volume];
ans = Flatten@NDSolve[{
     b*u[t, x]*Derivative[0, 1][h][t, x] + 
       b*h[t, x]*Derivative[0, 1][u][t, x] + 
       b*Derivative[1, 0][h][t, x] == r,
     (r*u[t, x])/(b*g*h[t, x]) + (Abs[u[t, x]]*(b + 2*h[t, x])^(4/3)*
          u[t, x])/(a^2*(b*h[t, x])^(4/3)) + 
       Derivative[0, 1][h][t, 
        x] + (u[t, x]*Derivative[0, 1][u][t, x])/g + 
       Derivative[1, 0][u][t, x]/g == 0,
     Derivative[1, 0][acc][t, x] == b*h[t, x]*u[t, x],

     h[0, x] == 1*ppa/ppa,
     u[0, x] == 0,
     h[t, le] == acc[t, le]/ppa,
     u[t, 0] == 0,
     acc[0, x] == 1*ppa
     },
    {u, h, acc},
    {t, 0, tf},
    {x, 0, le}
    ];


ClearAll[h, t, x, u, acc, volume];
ans2 = Flatten@NDSolve[{
     b*u[t, x]*Derivative[0, 1][h][t, x] + 
       b*h[t, x]*Derivative[0, 1][u][t, x] + 
       b*Derivative[1, 0][h][t, x] == r,
     (r*u[t, x])/(b*g*h[t, x]) + (Abs[u[t, x]]*(b + 2*h[t, x])^(4/3)*
          u[t, x])/(a^2*(b*h[t, x])^(4/3)) + 
       Derivative[0, 1][h][t, 
        x] + (u[t, x]*Derivative[0, 1][u][t, x])/g + 
       Derivative[1, 0][u][t, x]/g == 0,
     Derivative[1, 0][volume][t, x] == b*h[t, x]*u[t, x],

     h[0, x] == 1*ppa/ppa,
     u[0, x] == 0,
     h[t, le] == volume[t, le]/ppa,
     u[t, 0] == 0,
     volume[0, x] == 1*ppa
     },
    {u, h, volume},
    {t, 0, tf},
    {x, 0, le}
    ];


(h/.ans)[200,0]
(*6.55942*)


(h/.ans2)[200,0]
(*2.31421*)

So, same code, different answers.

Answer 3

From @Szabolcs comment we see that we can recreate this issue using an arbitrary System symbol so it is not an issue of some kind of functionality of the built in symbol, though he mentions that he can find models that it will still work for so it seems to be a bug, not a check.