Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Interpreter data_handle methods to get information associated with the data_handle. #2876

Open
nrnhines opened this issue May 13, 2024 · 1 comment

Comments

@nrnhines
Copy link
Member

Data_handles to a RANGE or hoc variable presently print information about themselves as a string, e.g., given the objects and variables created by:

from neuron import h
s = h.Section()
s.insert("hh")
ic = h.IClamp(s(.5))
artcell = h.IntFire1()
h("x = 5")
cv = h.CVode()
cv.use_fast_imem(1)

then

print(s(.5)._ref_v)
print(s(.5).hh._ref_m)
print(ic._ref_dur)
print(artcell._ref_tau)
print(h._ref_x)
print(s(.5)._ref_i_membrane_)
print(h._ref_t)

prints

% python3 temp.py
data_handle<double>{Node::field::Voltage row=0/2 val=-65}
data_handle<double>{cont=hh m row=0/1 val=0}
data_handle<double>{cont=IClamp dur row=0/1 val=0}
data_handle<double>{cont=IntFire1 tau row=0/1 val=10}
data_handle<double>{raw=0x6000011616a0}
data_handle<double>{Node::field::FastIMemSavRHS row=0/2 val=0}
data_handle<double>{raw=0x10188d7c8}

Note that, in every case, if ref is a data_handle, then ref[0] would print the value.
It would be nice if ref.thread_id() would return the thread id associated with the variable handle. In the above cases a ref to 'x' and 't' would return -1, since they are not associated with threads.

It would also be nice to have ref.name() or var or varname return in the above cases the name of the variable, I.e.
"v", "m", "dur", "tau", "x", "I_membrane", "t"
and
ref.container() or something like that, return in the above cases the relevant container, ie., the object which prefixes the name, I. e:

>>> s(.5)
__nrnsec_0x138088000(0.5)
>>> s(.5).hh
hh
>>> ic
IClamp[0]
>>> artcell
IntFire1[0]
>>> h
<TopLevelHocInterpreter>

Then getattr(ref.container, ref.name()) == ref[0]

Lastly, it would be nice if type(ref) would be a hoc.Reference instead of hoc.HocObject. The latter has the disadvantage that dir(ref) prints the large dict of HocObject instead of the few relevant names and methods of a reference.

@nrnhines
Copy link
Member Author

This enhancement was proposed in order to simplify the usage of Vector.record (and Vector.play) in a multithread and/or local variable time step method context. I.e. a single arg data_handle should suffice for all range variable references without the need to specify an initial POINT_PROCESS or ARTIFICIAL_CELL instance hint or sec=section keyword arg hint. The only case that would still require a hint is the Vector.record(h._ref_t) where a hint is needed for which thread time is recorded. However, note that the thread_id is not a valid hint since the thread is dynamically determined by the topology of the model. It is not clear to me that resolution of this issue is a prerequisite to, or even much of a help for, #2858

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant