Fix HH-type channel gate export

[HengyeZhu]

Reasons for the changes

• HH2_magic recomputes m_fcond/h_fcond/n_fcond in BREAKPOINT after SOLVE, so currents use gate values at the new time step.

• HH2_reason computes these multipliers inside evaluate_fct before SOLVE and then reuses them in BREAKPOINT, so currents use the previous time step’s gate values.

• NEURON recognizes cnexp only when the DERIVATIVE block contains the direct linear form x' = (x_inf - x)/x_tau.

• Introducing intermediate rate_* variables can prevent cnexp recognition and force Euler-style updates.

Key exporter changes

• parseTimeDerivs: For HH/HH2-style first-order gates, emit state' = (inf - state)/tau inline so NEURON recognizes cnexp. Avoid intermediate rate_* variables for gates; keep the legacy rate_* path for non-gate components.
• parseDerivedVars: Move gate multipliers (fcond) into BREAKPOINT so they are computed after SOLVE, using updated gate values. Keep top-level ion-channel derived vars (fopen, gion, etc.) in BREAKPOINT as before; non-gate derived vars remain in rates().

Examples

• HH2-style channels: Gate multipliers must be computed after SOLVE, not inside rates() or the DERIVATIVE block. Computing fcond in rates() causes a one-time-step lag (uses t_n instead of t_{n+1}), producing systematic current differences.
• cnexp recognition: Gate ODEs must be in canonical form x' = (x_inf - x)/x_tau without extra rate_* intermediates; otherwise NEURON can fall back to Euler.
• cadad vs cadad_RE_soma_nml: The ODE forms and unit conversions are effectively equivalent; the divergence came from initialization. cadad.mod overwrites cai with cainf at t=0, while the original export preserved Python-initialized cai. Fix: in the NML export, set cai = cainf in INITIAL before copying into internal state.
• IT2 nax_nml vs nax_BS: The discrepancy was caused by ordering inside rates(): tau was computed from stale alpha/beta while inf used updated rates. Fix: update alpha/beta immediately after computing forward/reverse rates, then compute time course and inf. (This modification has not been integrated into the PR yet)
• IT2 kap_nml vs kap_BS: For the n gate, apply Q10 scaling before enforcing the global minimum (nmin) to match the original mechanism. The l gate already matches original behavior with no additional changes needed. (This modification has not been integrated into the PR yet; perhaps this issue can be addressed during the modeling stage.)

[sanjayankur31]

Thanks @HengyeZhu , we'll start looking at this. In the meantime, do you want to start an impact assessment to see how this affects other existing models? You can get the "core" osb models (models that we trust and ones we use for impact assessments) using this script:

https://github.com/OpenSourceBrain/osb-model-validation/blob/master/utilities/getcoreosbprojects.sh

Then, one needs to run omv in all of them one by one to run all the omv tests. They should all pass to begin with. Ones that fail will need us to look into them.

[HengyeZhu]

I ran the models using the jNeuroML_NEURON engine. The results showed both improvements and setbacks. On the positive side, the tolerance could be lowered—often by one or two orders of magnitude, and in some cases dramatically, from 1e-5 to 1e-16. On the negative side, some OMV tests failed.

Next, I’ll examine the models in detail and provide a summary.

[sanjayankur31]

That sounds good. Yeh, we'd expect tolerances to drop for quite a few models, but the ones where the tests fail will need a little bit of looking into.

Welcome to the editorial team, by the way. Congratulations!

[HengyeZhu]

Thanks! I'm very honored to join the team!

[HengyeZhu]

The modifications pertain solely to the export logic of jnmlnrn, and only the tests for jnmlnrn have been rerun accordingly.

The previously mentioned test failures were due to missing environment dependencies.

Regarding the jnmlnrn results, most showed improvement, while the cases marked as worse were attributable to the original mod files utilizing lookup table or Euler methods, rather than the cnexp numerical integration approach.

Additionally, some mod or hoc files require downloading, which I will address later, and the source of certain mep data is unclear, making debugging difficult.

Some results remained unchanged because the project does not involve hh gates.

Among these, the results for CA1PyramidalCell are particularly notable: one segment was flagged as worse while all others showed improvement. The cause of this discrepancy has not yet been identified.