Allow probing of point state by tag. #2417
Conversation
| for (auto lr = lr_beg; lr != lr_end; ++lr) { | ||
| const auto& [lid_beg, lid_end] = lr->second; | ||
| for (auto lid = lid_beg; lid != lid_end; ++lid) { | ||
| auto cg = lid + cg_lo; | ||
| if (cg >= cg_hi) continue; | ||
| const auto& handle = R.handles.at(cg); | ||
| if (handle.mech_id != mech_id) return; | ||
| auto mech_index = handle.mech_index; | ||
| R.result.push_back(fvm_probe_scalar{{data + mech_index}, | ||
| point_info_of(target, | ||
| lid, | ||
| mech_index, | ||
| synapses.at(mech), | ||
| R.M.mechanisms.at(mech).multiplicity)}); | ||
| } | ||
| } |
There was a problem hiding this comment.
just for my understanding - can there ever be more than one probe resolved and pushed to result?
There was a problem hiding this comment.
Formally, yes, as synapse_ranges is a multimap of ranges. This could happen
if two synapses are given the same label. We could forbid that, but currently don't.
d = A.decor()
d.place('(...)', A.synapse('expsyn'), 'syn-1')
d.place('(...)', A.synapse('exp2syn'), 'syn-1')Come to think of this particular example, we probably should forbid this...
Note: I'd suggest we make a new PR for blocking this, since changing the API is an orthogonal concern. I'll spin off an issue, if that's ok.
There was a problem hiding this comment.
Ah, that's impossible, as the probe contains the mechanism type (the id in the resolution step):
if (handle.mech_id != mech_id) return;
So, multiple synapses of the same type can appear in the same probe, here.
This concludes the introduction of 'labels' for synapse identification / placements started back in
PR #1504 by @noraabiakar. Labels are now used when probing a synapse's state.