The original question was
How can I plot variables mtau and minf when working with NEURON using Python ? I use sec._ref_v and sec._ref_mtau_hh and both of them produce hoc error.
but the actual question seems to have been "how can I record the time course of mtau and minf?" It's a good thing I didn't start telling you how to plot things, because you were primarily interested in setting up vector record.
mtau_hh and minf_hh are both GLOBALs, so they don't "belong" to any section or segment--they aren't "properties" of any section or segment. The hoc syntax for referring to a GLOBAL that belongs to a density mechanism is
varname_suffix
Notice that this involves neither the name of the section, nor a numerical value that specifies a segment in a section. The Python syntax is
h.varname_suffix
(assuming you have imported h), and again there is nothing that specifies either the name of a particular section nor a segment in a section.
The hoc syntax for recording a RANGE variable is
vecname.record(§ionname.rangevarname_suffix(range))
or
sectionname vecname.record(&rangevarname_suffix(range))
where the "range argument" lies in the interval 0..1 and specifies the compartment whose range variable will be recorded.
The Python syntax for recording a RANGE variable is
vecname.record(sectionname(range)._ref_rangevarname_suffix)
or
seg = sectionname(range)
vecname.record(seg._ref_rangevarname_suffix)
The hoc syntax for recording a GLOBAL is
vecname.record(&varname_suffix)
and for Python it is
vecname.record(h._ref_varname_suffix)
Finally, a comment about GLOBALs vs. RANGE variables. GLOBALs are used in NMODL for two main reasons. One is for those parameters that are to have the same value across every instance of a particular ion channel or other mechanism. The other use is a way to reduce memory usage by "intermediate variables" such as gating state time constants and steady state values. The memory savings is proportional to the number of intermediate variables that are declared to be GLOBAL and the number of instances of the mechanism in question. In most cases the savings is trivial, except perhaps in very large models where any savings might spell the difference between being able to fit the entire model into memory versus having to use swap space which can slow things down tremendously.
It is rarely a good idea to record the time course of a GLOBAL, because the value that it holds depends on factors that are outside of your control or even your ability to determine. Why? Consider minf_hh. The value it holds at the end of an fadvance depends on which segment of which section happened to be the very last segment in the model at which minf_hh was calculated. You don't know anything about that segment. In order to make sense of a recording of minf_hh, it is a very good idea to promote that variable to a RANGE variable, as you did. That removes all uncertainty because you have complete control over where you are monitoring minf_hh.