From: Rainer M. <ra...@tb...> - 2006-10-03 09:51:20
|
Hi Andrew, the bug described below by Nicolas seems related with the processEvents code in IntegratorInstance_updateData. You had replaced the update of assignment rules with the code that is only executed if engine->processEvents is true (1). Then assignmentsBeforeEvents and assignmentAfterEvents are executed there. However, it seems that these do not involve the reaction assignment rules!! That seems to underly the problem that Nicolas describes. If I evaluate all assignment rules in the updateData function the results seem to be OK, again. Where would be the best way to fix this without removing this optimization of assignment rule ? Rainer Rainer Machne wrote: > Hi All, > > for the record, and for anyone interested in bug fixing :), i forward > this email to the list. > > Again or still, we seem to have a piecewise bug. The reason for the > strange behaviour described by Nicolas below is unclear. > > A piecewise expression used in an assignment rule contains the "time". > The respective expression seems to be set true at time 57... while it > should only become true at time 60. > > The only suspicion I have is that the assignment rule is not updated > correctly and that the rule still has some value which it took in an > internal CVODE evaluation when it internally was already at time 60 for > evaluating f. > Andrew, is it possible that your priority for assignment rule evaluation > doesn't account for rules that contain "time"? > > I will look at it next week but maybe you have an idea. > > Rainer > > > ---------- Forwarded message ---------- > Date: Tue, 12 Sep 2006 18:03:20 +0100 (BST) > From: Nicolas Le Novere <le...@eb...> > To: ra...@tb... > Subject: piecewise ... > > Dear Rainer, > > We are still working on the problematic model that led us to ask-you > to modify SBMLodeSolver for piecewise functions (we are doing other > things as well, don't worry :-) > > I attach a model that should be fine. I tested it without rule, and > with only the assignment rule for Sstar. In both case, the model > worked perfectly. Now, with the piecewise function (only one piece for > the moment), we encounter all kinds of problems: > > For some reason, at t=57, Sstar jumps from 0.012 to 14.45, the value > it will take after the piecewise jump for calcium at t>60. But the > calcium is still unchanged! > > Then, after t=60, even if Sstar increased 0.012 to 14.45, the > reactions involving it remain unchanged, until t=62.44. > > Is-it a problem of output only? Is-it a problem in the patching of > SBMLodeSolver? > > I join the SBML and the output of > > odeSolver -w --time 100 --printstep 1000 > dAlcantara_Bidirectional_Plasticity_CorrectedOnePiece.xml > > (renamed .clean to go through the mail filters) > > |