multiple SOLVE

[stil]

Hello all,

I am wondering what could be the problem using multiple SOLVE statements in the same breakpoint block ... ?

How should I do if I want to have a kinetic scheme on one side, and a set of rates equations on the other, such as in :

Code: Select all

BREAKPOINT {
	SOLVE kstates METHOD sparse
	SOLVE states METHOD cnexp
}

DERIVATIVE states{
	RRate' = kk2 * XX4C * YYC - kk3 * RRate
	VesReleased' = RRate
}

KINETIC kstates {
	~XX		<->	XXC		(4*konX*cai, koffX)
	~XXC	<->	XX2C	(3*konX*cai, 2*koffX)
	~XX2C	<->	XX3C	(2*konX*cai, 3*koffX)
	~XX3C	<->	XX4C	(1*konX*cai, 4*koffX)
	CONSERVE XX+XXC+XX2C+XX3C+XX4C = 1

	~YY <-> YYC		(konY*cai, koffY)
	CONSERVE YY+YYC = 1
}

This seems to work, so i was wondering what should i expect to face doing like this, and what could be a workaround in this situation ?
Thanks !

[ted]

The emphasis is on "seems to work." I have seen one instance of a mod file that used a BREAKPOINT block with two SOLVE statements, one for a DERIVATIVE and the other for a KINETIC block. It also "seems to work" in the context of the published model that uses it. And that was a surprise to me and others.

So there isn't a lot of information or experience that would serve as the rational basis for an answer to the question "what could go wrong." We don't have an example of such usage that fails, so that eliminates the "known knowns."

Regarding "known unknowns," or at least "reasonably speculated unknowns," the one that comes to mind is sequence-dependent errors. It's not too hard to imagine that problems would arise if the first SOLVE statement depends on results generated by the calculations performed by the second SOLVE statement. Sequence-dependence won't be a problem if the second SOLVE statement depends on the results of the first SOLVE statement, or if the two sets of calculations are entirely independent. In the case of your example, the DERIVATIVE block depends on values calculated by the KINETIC block, but not vice versa, so the sequence
SOLVE kineticblock
SOLVE derivativeblock
shouldn't cause any sequence-dependence errors.

That leaves the "unknown unknowns," regarding which there is, by definition, nothing objective to be said except: do what you can to devise and run tests that validate your results. There's nothing worse than a program that runs without error messages but generates incorrect results, except perhaps when you have to retract a paper that was based on those results.

[stil]

Okay, i understand.

Thanks a lot for these explanations!

[jjnaylor]

What if both blocks depend on each other? In this example, what if the kinetic scheme somehow depended on the RRate or VesReleased? Is there a way to work around this? I tried putting the derivative block into a point process and use pointers, or making global statements (but I learned that you can't have a GLOBAL state variable).

[ted]

What if both blocks depend on each other?

My expectation is that this will fail--you'll end up having to rewrite the equations in such a way that they can all go into one equation block, i.e. you'll end up with either one KINETIC block or one DERIVATIVE block. But you're always free to try whatever you like, and discover for yourself whether it works or not.