Richard Jackson wrote:
Can you reformulate the problem to put everything in one solve block? Failing that, the only solution is to speed up the first solve block. Can you say any more about the equations in that solve block?
I could try to reformulate that in a single block, however I have some concerns that it will work. The solution calc(i) comes from the block in the form of calc(c1, c2... cN, p1,p1... p6), where c1... cN are vectors of 7 values each, since each experiment comes with a set of N constants. In the SolveBlock, I keep them as parameters - free - as shown... and after the block I insert the values. This leads me to the calc(p1, p2... p6) solution (of course, including any 6 values for the parameters, this solution is a 7 x 11 matrix). So, I do not think that inside the SolveBlock is allowed to write the equations in the form: x[i = z[i
However, I am not sure if I could use the vectorized form x = z (with the vectorization arrow above both, x and z).
And even if I succeed in doing everything in a SolveBlock and use minner, at a later stage I will have to include in the model the derivatives of the current equations. So, I would have to both integrate (most probably using Odesolve) and to make the optimization using minerr or minimize... and therefore, I would need again the two SolveBlocks.
So, what I can do is to reduce the calculation time for any individual operation/block that I have. Following this idea, I removed from the first SolveBlock the equations of the form f(unknown1, unknown2,...) and I included their actual axpressions (e.g. unknown1 + unknown2 * unknown3, etc). And this gave me an improvement.
But since I have to see if there are other minima (and there are) and see which is most satisfactory in terms of best fit (I always look at the SSE or reziduals), I have to start also from different guess values for the six parameters... and the calculation time is very sensitive to that.
I will keep looking for improvements. Thank you for your reply; they are very helpful.
So, from what I learned, the calculation time can be reduced by:
- using a single SolveBlock instead of multiple, where possible
- writing the actual expressions in the SolveBlock, and not calling them (do not define them 'above' the SolveBlock and then use them in the block)
In calculation loops, reducing the limiting calculation sequence will reduce the overall calculation time.
Basically, it is about reducing the number of operations and function evaluations as much as possible.
At least, these gave some improvement in my calculations.
Werner Exinger wrote:
What we found out here a sghort time ago was that programs using stack() and augment() are much slower than programs with selfwritten routines - incomprehensible, but true.
Indeed, it is better to create your own routine instead of using stack(). The built-in routine was slower than my routine for arranging the solution of a SolveBlock.
Thank you Werner.