Chronological Thread 

< Chronological >      < Thread >

---

David Nickerson wrote:
> Andrew Miller wrote:
>
>> Shane Blackett wrote:
>>
>>> Hopefully your maximum step size and your tabulation step size are much
>>> larger than the step size sometimes used by the adaptive integrator.
>>> Here forcing results to come back at a fixed spacing forces you not to
>>> capture this signal properly in your graphs. This seems really
>>> unfortunate, you may have correctly integrated a complicated action
>>> potential and then you draw a graph which completely misses it! This
>>> seems really bad. Isn't it much better is to concentrate your line
>>> segments in your graph in exactly the same places where the adaptive
>>> step size system found your solution to be complicated?
>>>
>>>
>> I have been looking into alternative approaches for choosing which
>> points to send, taking the general idea behind Shane's suggestion (since
>> providing the integrator is the point behind the first release, this is
>> essential). When we find a good method, it would be useful to put that
>> into some other type of metadata specification (probably not the
>> simulation metadata) so that similar results can be reproduced.
>>
>
> Does this kind of information belong in the graph metadata? I guess you
> can look at the simulation metadata as describing how a certain set of
> data can be generated from a model and the graph metadata as one way to
> represent such data (or sets of data).
If we decide how to specify the system for determining which points to
plot on the graph. However, there are more than one way to do this.
Perhaps something general like 'maximum resolution' which could be
re-used in a variety of strategies (including fixed grid and bounded
resolutions. Strategies which require choosing every nth integrator
point would be hard to do from this, however)?
> Then software is free to combine
> both the simulation metadata and graph metadata in order to determine
> how to perform a simulation (or set of simulations) and present the
> results in such a way as to meet the requirements of both sets of metadata.
>
>
>> I also noticed that we do not have any way to specify error control
>> parameters. I guess that this is genuinely simulation metadata, although
>> unfortunately it is somewhat dependent on the error control method
>> chosen. Are there any objections to leaving this out of the metadata
>> used for the first release of PCEnv? (it currently only extracts the
>> bound variable starting and ending time points). The CIS supports a
>> maximum step size, although it isn't on the UI now (the flow is
>> currently metadata => UI => CIS, although I could add hidden state to
>> pass through the UI if it was useful).
>>
>
> I think it makes sense to leave error control out for the first release.
> While error control is an important piece of simulation metadata, I
> generally find that all the models I work with will at least run and
> produce consistent results with a reasonable default error tolerance. I
> think there are quite a few issues to think through in terms of
> specifying the error control to be used in a given simulation. The
> actual error control used in most standard integration packages
> available is generally pretty internal to the package and only exposed
> via the user being able to specify relative and absolute tolerances
> either as scalars or vectors. So error control will probably always be
> tied to the integrator you choose to use, which has already been dropped
> from the requirements for the first release of PCEnv.
>
GSL actually separates as much of the step size control as possible from
the stepping function (they merely provide error estimates, and some
common code then compares them with the parameters). Obviously, it still
matters a lot how you get the error estimates, but that doesn't mean
that error control parameters are completely useless.

> If with the above comments you are saying the PCEnv provides no way for
> the user to control the maximum step size used in the integration, then
> I think such functionality is definitely required
Agreed, a lot of CellML models probably need this, so I will add this
before the first release.

Best regards,
Andrew
> as that is one of the
> main parameters in determining the success of a model's integration. If,
> on the other hand, you're just saying the the user can control it but it
> won't be read from the model metadata then I guess that is ok for the
> first release of PCEnv.
>
>
> Andre.
> _______________________________________________
> cellml-discussion mailing list
> cellml-discussion at cellml.org
> http://www.cellml.org/mailman/listinfo/cellml-discussion
>

---

• [cellml-discussion] Summary of simulation metadata meeting, David Nickerson, 09/07/2006
  • [cellml-discussion] Summary of simulation metadata meeting, Andrew Miller, 09/08/2006

---

Archive powered by MHonArc 2.6.18.