In brief, example 3 makes it easier to play with params for optimization to check for speed of convergence & adds a number of plotting options. Ex4 is a "point based" as opposed to voltage trace analysis based example, i.e. matches targte behaviour to optimised version at specific points e.g. t=100ms. Will be better for matching IV curves
@VahidGh If your saves V (x axis) & I (y axis) values it can be used with example 4 I believe
@travs That sounds like an issue with matplot lib...
@VahidGh Example 5 (not written yet :smile: ) will have a NetworkAnalyser, which will be able to read back in multiple traces and optimise on targets across multiple traces. Will be needed for network optimisation (c302 full network) but will also be useful for multiple IV (or freq vs current) traces (figures in boyle cohen)
@pgleeson, great. Yes, at the first I was following this approach as you were using in c302tuner but it was a bit slow because of calling jnml for simulations. so I decided to write a code following Boyle & Cohen approach and save traces and then using them.
@VahidGh If you want to use the python implementation of boyle/cohen, then you have full access to all variables. It will be faster too, but you need to implement a layer on top for the parameter management & also export values back to NeuroML
Ok so it seems like we’ve made meaningful progress on the neurotune issues and have some good progress going here. I’m seeing next actions as getting a chance to see @VahidGh ’s latest optimization code and following @pgleeson’s suggestions in pgleeson/neurotune#3 to try to do a channelml example or help him with one he may be working on.
@VahidGh not sure about the usual practice for that. The decision whether a gate is inactivating etc. is usually made beforehand based on the best knowledge of the type of channel. It's usually a fixed parameter in the ion channel model being fitted..?
We can do that demo @VahidGh@miladjafary at the next meeting, as we had originally planned for a bit of different topics here — just seeing if it was something we were ready to show for @pgleeson to see
the idea is a front end that shows us a dashboard of completion to pull together muscle cells / neurons / and their relations to channels, and also show relationship between data and simulation runs, and loop together with references
Just to put a spanner in the works... I get a bad feeling with talk of putting the output of ChannelWorm/optimisations etc. inside PyOpenWorm. I really feel that should be an API to published data/physiological database contents.
@slarson I think we need a Portal that use some service witch they can host on diff servers. For example IonChannel App can do all of operation related Ion Channels and also reaise some service as a web service for other App.
@miladjafary I’m fine for that — just so long there is a path to unification that is possible as the greater goal here is to have this all interconnect. But yes you are expressing the “unix philosophy” of building up components that do single things well and this is definitely consistent with our approach here
the Idea behind that interface diagram is that it is a valuable unification point; it doesn’t have to be the only one
@pgleeson “most data” being static … perhaps initially but it could evolve. I hadn’t pre-judged the volume of static vs. dynamic data. It seemed that the evolution of PyOpenWorm started when there was a lot of disparate ways to represent information about the same thing
@pgleeson so if we have access to an object that unifies info about say AVAL, why not also be able to access any optimization runs of models that have been run on the AVAL neuron? That’s why I have left the door open for dynamic info
Because the alternative is that runs optimizing a model about AVAL will get recorded in some other flat file somewhere that won’t be easy to find
and we’ll recap the same challenges that led us to PyOpenWorm in the first place
The basic idea behind both of these challenges, all, is that there should both be a focused place where information lives / is generated, but there should also be a pathway to unify that information — whether it is data, i.e. pyopenworm, or an interface, i.e. this new proposed one.
Aaanyway; when we see this ion channel app, we’ll better understand the unification paths that are possible
@travs can we update the agenda with items we covered struck through to see what we have left for next time?
@pgleeson I think the trick is just to make it clear which API functions bring back stable published data and which API functions bring back dynamic bits. There’s no argument against the value of the stable api for published data — we definitely want this :)
@miladjafary For some components whose goal is to integrate, some dependencies are not necessarily bad. The idea is to build such integrative components on a foundation of more single use components with limited dependencies
They say "Figure 5E shows that the current densities for the wild-type mutant ra612 mutant channels were comparable using either Ba or Ca as the charge carriers (n 13, wild-type in Ca; n 11, mutant in Ca; n 8, wild-type in Ba; n 13, mutant in Ba)."