# Very long Refine/Solve batch run - is my code broken, or just complicated?

So I'm trying to run some Mathematica code in batch mode from my university cluster. Specifically, I'm trying to find the equilibria of a system of ordinary differential equations. Inspired by the answer to my original question on the Math site, I'm using a combination of Refine and Solve for this.

Code for a simpler but related system, which runs swimmingly on either the cluster or my own machine is this:

Since then, I've tried to run this adapted code for a considerably more complicated system:

This is taking forever. In the "longer than a day, devoured all the RAM on a 48 Gb cluster node and was well on its way to eating the RAM on a 96 Gb node before I killed it" sense of the word. Which is fine if the code is actually working - it's something of a hard problem for a computer to do, and if it just takes a long time, so be it. My problem is there's also the distinct possibility I've done something wrong, created a runaway process, etc. and I'm not a good enough Mathematica programmer to spot it (I'm a rather poor Mathematica programmer in fact). Anyone able to spot anything clearly pathological about what I've done?

Edit: Adding in editable/cut-and-pasteable code. Converting between the standard form and the input form has changed the code slightly, including swapping Simplify and Solve, but I have no idea if that matters.

Refine[(Simplify[#1, ϑ > 0 && ρp > 0 && σp >
0 && ρd > 0 && σd > 0 &&
ρa > 0 && σa > 0 &&
1/ω > 0 && α > 0 && ψp > 0 && μp > 0 &&
μa > 0 && θp > 0 && νup > 0 && θ >
0 && ζ > 0 && ψa > 0 &&
θa > 0 && νua > 0 && γ > 0 && ϕ >
0 && κ > 0 && νcp > 0 &&
τ > 0 && νca > 0] & )[
Solve[{ϑ*H - ρp*σp*
Cp*(Us/N) - ρd*σd*D*(Us/N)*ρa*σa*
Ca*(Us/N) == 0,
ρp*σp*Cp*(Us/N) + ρd*σd*
D*(Us/N)*ρa*σa*Ca*(Us/N) + ϑ*H == 0,
(1/ω)*Ua - α*Up - ρp*ψp*
Up*(H/N) - μp*σp*Up*(Cp/N) -
μa*σa*Up*(Ca/N) - θp*
Up + νup*(θ*M + ζ*D) == 0,
α*Up - (1/ω)*Ua - ρa*ψa*
Ua*(H/N) - μp*σp*Ua*(Cp/N) -
μa*σa*Ua*(Ca/N) - θa*
Ua + νua*(θ*M + ζ*D) == 0,
(1/ω)*Ca + γ*ϕ*D + ρp*ψp*
Up*(H/N) + μp*σp*Up*(Cp/N) +
μa*σa*Up*(Ca/N) - α*Cp - κ*
Cp - θp*Cp + νcp*(θ*M + ζ*D) == 0,
α*Cp + γ*(1 - ϕ)*D + ρa*ψa*
Ua*(H/N) + μp*σp*Ua*(Cp/N) +
μa*σa*Ua*(Ca/N) - (1/ω)*
Ca - κ*τ*Ca - θa*Ca +
νca*(θ*M + ζ*D) ==
0, κ*Cp + κ*τ*Ca - γ*ϕ*
D - γ*(1 - ϕ)*D -
ζ*D + νd*(θ*M + ζ*D) == 0,
Us + H + Up + Ua + Cp + Ca + D == 0,
Up + Ua + Cp + Ca + D == 0}, {Us, H, Up, Ua, Cp, Ca, D, N,
M}, Reals]], Null]


Update

Per some suggestions below, am now trying the following:

Solve[{ϑ*H - ρp*σp*
Cp*(Us/N) - ρd*σd*D*(Us/N)*ρa*σa*
Ca*(Us/N) ==
0, ρp*σp*Cp*(Us/N) + ρd*σd*
D*(Us/N)*ρa*σa*Ca*(Us/N) + ϑ*H ==
0, (1/ω)*Ua - α*Up - ρp*ψp*
Up*(H/N) - μp*σp*Up*(Cp/N) - μa*σa*
Up*(Ca/N) - θp*Up + νup*(θ*M + ζ*D) ==
0, α*Up - (1/ω)*Ua - ρa*ψa*
Ua*(H/N) - μp*σp*Ua*(Cp/N) - μa*σa*
Ua*(Ca/N) - θa*Ua + νua*(θ*M + ζ*D) ==
0, (1/ω)*Ca + γ*ϕ*D + ρp*ψp*
Up*(H/N) + μp*σp*Up*(Cp/N) + μa*σa*
Up*(Ca/N) - α*Cp - κ*Cp - θp*
Cp + νcp*(θ*M + ζ*D) ==
0, α*Cp + γ*(1 - ϕ)*D + ρa*ψa*
Ua*(H/N) + μp*σp*Ua*(Cp/N) + μa*σa*
Ua*(Ca/N) - (1/ω)*Ca - κ*τ*Ca - θa*
Ca + νca*(θ*M + ζ*D) ==
0, κ*Cp + κ*τ*Ca - γ*ϕ*
D - γ*(1 - ϕ)*D - ζ*
D + νd*(θ*M + ζ*D) == 0,
N == Us + H + Up + Ua + Cp + Ca + D,
M == Up + Ua + Cp + Ca + D , ϑ > 0, ρp >
0, σp > 0, ρd > 0, σd > 0, ρa >
0, σa > 0, ω > 0, α > 0, ψp > 0, μp >
0, μa > 0, θp > 0, νup > 0, θ > 0, ζ >
0, ψa > 0, θa > 0, νua > 0, γ > 0, ϕ >
0, κ > 0, τ > 0, νca > 0, νd > 0}, {Us, H, Up,
Ua, Cp, Ca, D, N, M}, Reals]


It hasn't immediately solved the problem (let it run for ~hour on a local machine), but sending it to the cluster to see if it gets fixed.

-
You have missed an & between the last and second-to-last closing brackets in the second screenshot above. However, while this may contribute (substantially) to your difficulties due to lack of simplification, I doubt it is the sole cause of them. Also, especially for complex inputs like this, please provide copyable text--don't make us re-type it! –  Oleksandr R. Feb 26 '12 at 4:25
@OleksandrR I'll look into that and see if it helps. As to copyable text, I'd love to, but I'm not sure the best way to put copyable text in such that it's useful - the raw text dump seemed unsuitable. Is there another approach you'd suggest? –  Fomite Feb 26 '12 at 4:53
@EpiGrad To format the code for the code-environment here one way is to go anywhere inside your code with the cursor (or mark the cell) and press Ctrl+Shift+I (or use Cell->Convert To->InputForm) and use this here. –  halirutan Feb 26 '12 at 13:33
@halirutan I've attempted to add in copyable text - Mathematica shuffled some things around, but hopefully it works the same. –  Fomite Feb 26 '12 at 17:54
I have some advice, but I'm not sure, yet, if it will speed things up. So, let me play with it a bit, and I'll try to post an answer tomorrow, or Tuesday. –  rcollyer Feb 27 '12 at 4:12

I've found with some of my own code that putting in the simplifying equations INTO the solve function speeds things up (sometimes significantly, in the "I don't know if this is going to finish" -> seconds timeframe). That is, instead of writing:

Solve[{EquationToSolve==0},{a,b,c}]//Simplify[#,a>0 && b<0 && c>=0]


Write

Solve[{EquationToSolve==0, a>0, b<0, c>=0},{a,b,c}]


I think this has something to do with Mathematica trying to simplify things immediately as it finds solutions, and since it can start simplifying early, the final answer turns out much faster.

Obviously this is not useful if you're looking for a general solution, but in many cases you can look at many more "specific" solutions in the same amount of time it would take you to solve for the general one.

-
I'll give this a stab tomorrow - this project got shelved a bit as my life exploded. Looking at adapting your example, the Simplify parts disappear - but do I need to retain the "Refine" wrapping around everything. I can't...really tell what it does in my code. The very finest cargo cult programming. –  Fomite Mar 12 '12 at 3:26
I just noticed something else. Your last two equations (Us + H + Up + Ua + Cp + Ca + D == 0, Up + Ua + Cp + Ca + D == 0) simply state that Us==-H if I'm reading them right. That would also simplify things, but MMA should be picking that up. Might want to just set up the equations that way though. –  tkott Mar 12 '12 at 10:08
Yeah, I think those bits are errors - those should be == N and == M. –  Fomite Mar 14 '12 at 8:15
Eeek, and another thing. I wouldn't recommend using "N" or "D" for variable names. Those are actual functions in MMA, and might mess things up (probably not, but out of habit I never use them any more) –  tkott Mar 14 '12 at 10:14
Heh - thanks for your help. I'll come up with different variable names for them just in case. Using your solution, do I still need the Refine statement wrapped around everything? –  Fomite Mar 14 '12 at 17:51

Might try without the inequalities and Reals domain specification. For one thing, they are not sll that helpful when there are free parameters that can take values in a large range. For another, you will ahve a better chance of it not hanging your machine. (By "better" I don't mean "guaranteed". No promises on this one.)

Of course if you do get solutions, you will then need to figure out which ones are viable for your inequality purposes.

-