Menu
▾
▴
sbmlsolver-devel
|
From: W E. W. <wew...@gm...> - 2006-09-05 19:28:00
|
Hi, Can we move the function static int CvodeSettings_setTimeSeries(cvodeSettings_t *set, double *timeseries, int PrintStep); to the API interface please? If one wants to set a whole time series it is much more straightforward to do this using this function than using: SBML_ODESOLVER_API int CvodeSettings_setTimeStep(cvodeSettings_t *, int, double); Especially that in case of this function it is not clear how to specify the length of the time series to set first. All the best. Eryk |
|
From: Rainer M. <ra...@tb...> - 2006-09-06 10:42:19
|
On Tue, 5 Sep 2006, W Eryk Wolski wrote: > Hi, > > Can we move the function > static int CvodeSettings_setTimeSeries(cvodeSettings_t *set, double > *timeseries, int PrintStep); > > to the API interface please? If one wants to set a whole time series > it is much more straightforward to do this using this function than > using: > > SBML_ODESOLVER_API int CvodeSettings_setTimeStep(cvodeSettings_t *, > int, double); > Especially that in case of this function it is not clear how to > specify the length of the time series to set first. > > > All the best. > Eryk Hi Eryk, Your point is good, but I remember that there was a reason to make this function "static/private". Unfortunately, I currently don't remember what the reason was ... It might either a) cause conflicts with the indefinitely setting or b) cause potential problems when a user sets a time series with starting values other then 0. However b seems to be avoided anyways because it is set to 0 and the first value of the passed time series is ignored. So I just added set->Indefinitely == 0; to be safe, and made this function part of the API. Or are there any concerns? Can anyone think of another reason to have this function private? Is it un-safe to have a function where two values must correspond to each other (PrintStep is the size of the array timeseries)? James, would you also want to move CvodeSettings_setAdjTimeSeries to the API? If no objections are brought up, I can submit these changes to CVS. Rainer |
|
From: Rainer M. <ra...@tb...> - 2006-09-06 11:09:03
|
Ok, I said something wrong in my email before: > However b seems to be avoided anyways because it is set to 0 and the > first value of the passed time series is ignored. That's NOT true. Actually the first value of the passed timeseries will be the first output time and the internal time array is one double bigger as the passed one. Maybe this was also a reason to make the function private, as this might cause confusion. ...? Rainer On Wed, 6 Sep 2006, Rainer Machne wrote: > On Tue, 5 Sep 2006, W Eryk Wolski wrote: > >> Hi, >> >> Can we move the function >> static int CvodeSettings_setTimeSeries(cvodeSettings_t *set, double >> *timeseries, int PrintStep); >> >> to the API interface please? If one wants to set a whole time series >> it is much more straightforward to do this using this function than >> using: >> >> SBML_ODESOLVER_API int CvodeSettings_setTimeStep(cvodeSettings_t *, >> int, double); >> Especially that in case of this function it is not clear how to >> specify the length of the time series to set first. >> >> >> All the best. >> Eryk > > Hi Eryk, > > Your point is good, but I remember that there was a reason to make this > function "static/private". Unfortunately, I currently don't remember what > the reason was ... > > It might either > a) cause conflicts with the indefinitely setting or > b) cause potential problems when a user sets a time series with starting > values other then 0. > > However b seems to be avoided anyways because it is set to 0 and the > first value of the passed time series is ignored. > > So I just added set->Indefinitely == 0; to be safe, and made this function > part of the API. > > Or are there any concerns? Can anyone think of another reason to have this > function private? > Is it un-safe to have a function where two values must correspond to each > other (PrintStep is the size of the array timeseries)? > > James, would you also want to move CvodeSettings_setAdjTimeSeries to the > API? > > If no objections are brought up, I can submit these changes to CVS. > > Rainer > > > > ------------------------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > sbmlsolver-devel mailing list > sbm...@li... > https://lists.sourceforge.net/lists/listinfo/sbmlsolver-devel > |
|
From: Rainer M. <ra...@tb...> - 2006-10-01 13:54:10
|
Hi, > So I just added set->Indefinitely == 0; to be safe, and made this function > part of the API. This was actually a bug. The indefinetely setting didn't work anymore when afterwards CvodeSettings_setTime was called. Sorry for that. A correct version is in CVS. However, this brings up this up again: Having CvodeSettings_setTimeStep in the API > ... might either > a) cause conflicts with the indefinitely setting or > b) cause potential problems when a user sets a time series with starting > values other then 0. But I guess it shouldn't be a problem. The first time in the passed array will be the next time step for indefinite integration and the user has to know about consequences of indefinite integration anywas. Rainer On Wed, 6 Sep 2006, Rainer Machne wrote: > On Tue, 5 Sep 2006, W Eryk Wolski wrote: > >> Hi, >> >> Can we move the function >> static int CvodeSettings_setTimeSeries(cvodeSettings_t *set, double >> *timeseries, int PrintStep); >> >> to the API interface please? If one wants to set a whole time series >> it is much more straightforward to do this using this function than >> using: >> >> SBML_ODESOLVER_API int CvodeSettings_setTimeStep(cvodeSettings_t *, >> int, double); >> Especially that in case of this function it is not clear how to >> specify the length of the time series to set first. >> >> >> All the best. >> Eryk > > Hi Eryk, > > Your point is good, but I remember that there was a reason to make this > function "static/private". Unfortunately, I currently don't remember what > the reason was ... > > It might either > a) cause conflicts with the indefinitely setting or > b) cause potential problems when a user sets a time series with starting > values other then 0. > > However b seems to be avoided anyways because it is set to 0 and the > first value of the passed time series is ignored. > > So I just added set->Indefinitely == 0; to be safe, and made this function > part of the API. > > Or are there any concerns? Can anyone think of another reason to have this > function private? > Is it un-safe to have a function where two values must correspond to each > other (PrintStep is the size of the array timeseries)? > > James, would you also want to move CvodeSettings_setAdjTimeSeries to the > API? > > If no objections are brought up, I can submit these changes to CVS. > > Rainer > > > > ------------------------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > sbmlsolver-devel mailing list > sbm...@li... > https://lists.sourceforge.net/lists/listinfo/sbmlsolver-devel > |
|
From: Rainer M. <ra...@tb...> - 2006-09-06 14:47:40
|
The functions CvodeSettings_setTimeSeries and CvodeSettings_setAdjTimeSeries have been moved to the API. Please update your CVS. Rainer On Tue, 5 Sep 2006, W Eryk Wolski wrote: > Hi, > > Can we move the function > static int CvodeSettings_setTimeSeries(cvodeSettings_t *set, double > *timeseries, int PrintStep); > > to the API interface please? If one wants to set a whole time series > it is much more straightforward to do this using this function than > using: > > SBML_ODESOLVER_API int CvodeSettings_setTimeStep(cvodeSettings_t *, > int, double); > Especially that in case of this function it is not clear how to > specify the length of the time series to set first. > > > All the best. > Eryk > > ------------------------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > sbmlsolver-devel mailing list > sbm...@li... > https://lists.sourceforge.net/lists/listinfo/sbmlsolver-devel > |
|
From: James Lu <jam...@oe...> - 2006-09-06 16:17:15
|
hi Rainer: In looking at the adjoint code again, I saw that IntegratorInstance_reset calls IntegratorInstance_set, which consists of calls: CvodeData_initialize and IntegratorInstance_initializeSolver. I just found that the bug in running examples/adj_sensitivity.c is associated with the IntegratorInstance_set called after the forward phase. In fact, what is need is IntegratorInstance_initializeSolver: CvodeData_initialize shouldn't be called before the adjoint phase starts. Could you tell me circumstances in which IntegratorInstance_reset is used? And is it possible (perhaps after some reorganization) to have access to simply IntegratorInstance_initializeSolver...what is the best way to go about it? thanks, James |
|
From: Rainer M. <ra...@tb...> - 2006-09-06 16:29:03
|
On Wed, 6 Sep 2006, James Lu wrote: > hi Rainer: > > In looking at the adjoint code again, I saw that IntegratorInstance_reset > calls IntegratorInstance_set, which consists of calls: CvodeData_initialize > and IntegratorInstance_initializeSolver. > > I just found that the bug in running examples/adj_sensitivity.c is associated > with the IntegratorInstance_set called after the forward phase. In fact, what > is need is IntegratorInstance_initializeSolver: CvodeData_initialize > shouldn't be called before the adjoint phase starts. > > Could you tell me circumstances in which IntegratorInstance_reset is used? > And is it possible (perhaps after some reorganization) to have access to > simply IntegratorInstance_initializeSolver...what is the best way to go about > it? > > thanks, > > James Hi James, > circumstances in which IntegratorInstance_reset is used? It is used in iterative forward integration runs, i.e. re-initialization of the solver to initial conditions. After one integration the calling application can either use a completely new settings structure, or just change some settings of the current settings. Then _reset will call CvodeData_initialize to get all initial conditions from the odeModel and then re-init the solver structures. As discussed with you in private emails, it might be a good idea to untangle a first creation of a solver and the reinitialization. The latter is required in two cases: a) a completely new run of the solver, starting with initial conditions at time zero, for this _reset and _set functions can be used b) cases where either the calling application (_setVariableValue) or an event changes an ODE variable during one integration run Actually, once a CVODE solver structure is created from an SBML/odeModel, it can be used as it is forever and only requires CVodeReinit, because the dimensionality NEQ of the problem should not change. The reason this is mixed is mainly because we found the Reinit function only some months ago. This is currently also true for sensitivity analysis, because its dimension NSENS also never can change, as it is done for all constants of the model. However, we plan to have a custom sensitivity analysis, where parameters can be chosen by the calling application. So the sensitivity code requires a different handling and cannot just be reinit-ed during runs because NSENS might change. Rainer |
Thanks for helping keep SourceForge clean.
X