To address the issue of timing of calcium rise in the junctional dyad, I first tried to just facilitate the calcium-sensitivity of release. Nope, again too fidgety and prone to spontaneous release when pushing the sensitivity too far.
I then had an idea I was slightly proud of – that was after
I had the bucket size insight. I thought – ok, let’s split the dyad into an
“inner dyad”, which is even smaller, and where ICaL and RyR meet,
and an “outer dyad”, where e.g. the Na-Ca exchanger could reside. In this way,
we would have even tighter coupling with a smaller bucket, and thus faster
dynamics. Going over papers on dyad sizes and counts, a back-of-an-envelope
calculation revealed we can push the inner dyad size down quite a bit. This has
worked really well for a lot of aspects, we had nice calcium dynamics,
alternans, DADs, all looked pink and rosy. Except then I realised that the
model had massive issue with the release being far too refractory. I tried to
address it, but could not (even with genetic algorithms etc.). I was quite
stuck.
Then I came up with an alternative – somewhat less elegant
in my view – the tightest coupling could be represented by a small population
of RyR directly coupled to ICaL (like in ToR-ORd), which would
provide enough early calcium rise to trigger the much larger population of more
standard Bers/Grandi RyRs. This should also facilitate fast rise of calcium and
should be less prone to issues with refractoriness… and it was!
So, then I went forward with this alternative, and it
actually made it throughout the years to the final version. It was really hard
to let go the two-tier dyad idea, which seemed elegant and I was working with
it for over a year. I was switching to a markedly different system which
initially didn’t work as well in some regards – but it could be ultimately
developed much further.
This choice also illustrates a common situation in model
development – you just go for the more promising option, not knowing if it will
be the ultimately used one. Sometimes it happened that this more promising
option would lead me to an even more desperately stuck state, so then I’d
revisit a prior idea that I left in a drawer as unpromising… or yet another
idea. I’d draw trees of what options are left to achieve what I wanted. Often
one gets more experience in one development branch that can be used to fix
issues in other branches. Of course, sometimes just nothing works.
Comments
Post a Comment