Function for retrieving a full parameter set from a calibration output

[TorkelE]

A quick utility function I threw together. If you think it might be useful, I am happy to clean it up, add tests and documentation, and put it somewhere sensible. Partial functionality like this might exist already, but couldn't find it.

The idea is that it would be nice to have a function that takes the output of a calibration, and returns a full parameter set that can be used for e.g. simulations. For each parameter, if it has been fitted, its value in the optimum is selected (and automatically rescaled if needed). If it has a default (known) value, that is used. If it carries between different conditions, a condition id is designated to determine which condition to use. At the end, the output can be a map ([:kB => 1.0, :kC => 2.0]) or a vector ([1.0, 2.0]).

The implementation may still have bugs.

[sebapersson]

I like this idea, and would definitely have this as a util function. The parameter mapping can be surprisingly tricky though, and in addition to what your function currently handles it also has to handle (in order to simulate the model correctly):

1. Condition-specific parameters which the function currently does not account for (see https://sebapersson.github.io/PEtab.jl/dev/Beer/).
2. Models with steady-state simulations.
3. In order to also correctly perform simulation initial-values would also need to be returned.
4. Callbacks that change the parameters during simulations.

So maybe a better solution would be:

function get_best_ps(res, problem::PEtabODEProblem; pre_eq_id=nothing condition_id="__c0__", parmap=true) 
...
return ps, u0
end

Then if the user provides pre_eq_id and then a condition_id they get the parameters and u0 following a steady-state simulation.

What do you think? (this functionality is already present under the hood, so I can extend your function to correctly to all the mapping)

[TorkelE]

adding the pre_eq_id=nothing kwarg and making u0 and output as well sounds good (although maybe the function needs renaming then).

Didn't think of condition-specific parameters, but I agree that that should be accounted for. I actually have a parameter fitting where this is case, so I have some special interest in this.

Would it make sense to wait with (4) until the dosage part is completed, and then this could be modified accordingly?

If this functionality is already present, this is good. Is the path forward to:

1. We scrap this one and you implement something, using the additional internal knowledge you have.
2. We modify this PR, fixing 1-3, and maybe 4. Possibly using some additional internals stuff is you can give points on what to use
   ?

[sebapersson]

I say the way forward is that scrap this one, I will reimplement using internal functions and tag you when done (I should get this done today). And as callbacks are tricky, I agree lets wait until PEtabDose is completed, and then we tackle the callback problem.

And I am happy that condition specific parameters is relevant (was a pain to properly implement originally :). In the dev-docs you can now find (added yesterday) how to define a model with these https://sebapersson.github.io/PEtab.jl/dev/Julia_condition_specific/

[TorkelE]

Excellent! Also, thanks for the new docs, I am checking them out right now.