Allow users access to local parameters from Python

[hsauro]

Not urgent: On the to do list.

Currently there is no way for a user to access local parameters in an SBML model. The current approach it to call the promote method that promotes all local parameters to be global. An alternative would be to extend the Python syntax to allow synta such as:

print r.J1.k1

where J1 is a reaction and k1 is a local parameter to that reaction.

Question, Does Antimony support local parameters?

[luciansmith]

Antimony converts local parameters to global parameters when importing, and
doesn't create models with local parameters. I could probably use the
syntax you suggest to make it work, though, whenever you felt it was a
priority.

[Karrenbelt]

I would really like to have this feature. Is there yet something that allows one to access the local parameters through python? I noticed that roadrunner simulates just fine with local parameters in the SBML document (they are not ignored), but I would also like to be able to set and retrieve their values from a roadrunner instance.

[matthiaskoenig]

If you send the SBML file with the local parameters I can post the 3 lines to promote the local parameters to global parameters and how to access/changes them subsequently.

Just can't find an example xml with local parameters to test the example.

[Karrenbelt]

I know that is possible; it is the current workaround.

The thing is though that I have reaction specific parameters, which I would like to strip when I change rate-laws, but also global parameters that I do not wish to strip from the model when I change rate laws. Having local parameters thus seems to make sense in order to achieve this, and as stated roadrunner will interpret them properly during simulation. I just cannot change them on the roadrunner instance, which I would like to be able to do.

Another easy workaround would be for me to put references to all the rate-law-related parameters in a separate container, so I can use that instead. Regardless of these workarounds though, it would be good to have access to them through the roadrunner instance them in python

[matthiaskoenig]

Personally, I just use some simple naming syntax which allows me to filter the parameters belonging to a reaction.
All my reactions are uppercase ids, e.g. HK1, PFK1 with the corresponding parameters having the reaction prefix HK1_Km_atp, HK1_Km_glc, HK1_Vmax, PFK1_Km_atp, PFK1_Vmax.
This allows then to very easily filter subsets, e.g. parameters for a reaction.
For instance get all Km values, get all Vmax values, get all parameters of a reaction ...
Much simpler if you have one list of global parameters.

In my opinion local parameters should be avoided due to the risk of shadowing global objects like global parameters, compartments, ... .

[Karrenbelt]

well perhaps, but they have been introduced in L3V2.

And if they're part of a kinetic rate law they will affect roadrunner simulation results, but you cannot access them through the roadrunner instance in python. That is suboptimal, particularly since local parameters shadow global ones as you've stated, but you don't have access to them.

Anyway, there are ample workarounds, regardless of that, I think they should be accessible through roadrunner.

[hsauro]

The real problem is (from my point of view) is that it would probably cost around 5K dollars to implement (in terms of programmer time) and the question is whether the change is worth that amount of resources or are their simpler workarounds that costs very little? Herbert Sauro

…

On Wed, Jul 24, 2019 at 8:44 AM Zarathustra ***@***.***> wrote: well perhaps, but they have been introduced in L3V2. And if they're part of a kinetic rate law they will affect roadrunner simulation results, but you cannot access them through the roadrunner instance in python. That is suboptimal, particularly since local parameters shadow global ones as you've stated, but you don't have access to them. Anyway, there are ample workarounds, regardless of that, I think they should be accessible through roadrunner. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#100?email_source=notifications&email_token=AAIBSDWXPAXKX2QDNFP4QJLQBB2CFA5CNFSM4A6AYAKKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD2WYBZI#issuecomment-514687205>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAIBSDQKBU7Z7DGHVGDY76LQBB2CFANCNFSM4A6AYAKA> .

-- Herbert Sauro, Associate Professor University of Washington, Bioengineering 206-685-2119, www.sys-bio.org [email protected] Books: http://books.analogmachine.org/

[Karrenbelt]

alright, the alternative would be to raise a warning when loading any model containing local parameters, with the suggestion to promote local parameters to global ones.

[hsauro]

That would work and be simple to implement. If there were a lot of demand for access to local parameter it would probably be implemented but you're the only person so far who has requested it. Herbert

…

On Wed, Jul 24, 2019 at 9:00 AM Zarathustra ***@***.***> wrote: alright, the alternative would be to raise a warning when loading any model containing local parameters, with the suggestion to promote local parameters to global ones. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#100?email_source=notifications&email_token=AAIBSDROKRRPPE6GRRSZGETQBB34FA5CNFSM4A6AYAKKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD2WZREQ#issuecomment-514693266>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAIBSDUUSK4PFASSF3QIHITQBB34FANCNFSM4A6AYAKA> .

-- Herbert Sauro, Associate Professor University of Washington, Bioengineering 206-685-2119, www.sys-bio.org [email protected] Books: http://books.analogmachine.org/