You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
For larger problems, create_parameter_mapping and fill_in_parameters can consume quite some time. This could be made more efficient:
parameter scale and plist should be computed only once and be stored in the parameter mapping
it should be clarified what needs to be updated in fill_in_parameters. Should it just recompute everything dependent on variable parameters, or every ExpData field?
much time is spent in both amici and libpetab for checking which model entities are state variables based on the SBML model. in the amici case, we already created the model beforehand and know which entities are state variables. this information should be used by both the petab and amici parameter mapping.
currently we have a two-stage parameter mapping, first libpetab, then amici. some parts are redundant, and it may be easier to have it completely in amici.
It should be clarified which ParameterMappingForCondition attributes are mutable so we can cache some quantities. Modification should only be allowed through a defined API that will update/clear caches as required.
Consider moving from dict-based mapping to ndarray-based mapping
The text was updated successfully, but these errors were encountered:
For larger problems,
create_parameter_mapping
andfill_in_parameters
can consume quite some time. This could be made more efficient:fill_in_parameters
. Should it just recompute everything dependent on variable parameters, or every ExpData field?ParameterMappingForCondition
attributes are mutable so we can cache some quantities. Modification should only be allowed through a defined API that will update/clear caches as required.The text was updated successfully, but these errors were encountered: