Every section has built-in range variables that include i_cap and cm--compute dvdt from those.
In the NEURON block declare
RANGE dvdt
In the ASSIGNED block declare
i_cap (mA/cm2)
cm (micorfarad/cm2)
dvdt (mV/ms)
As the final statement in the INITIAL block declare
dvdt = (1000)*i_cap/cm
and whenever you need the current value of dvdt, calculate it as
dvdt = (1000)*i_cap/cm

Further considerations:

If your synaptic mechanism's learning rule depends only on dvdt at the instant of synaptic activation, you should compute the new w in the NET_RECEIVE block. This will allow stream-specific plasticity, i.e. regardless of how many NetCons converge on a single instance of your synaptic mechanism, the weight associated with each afferent event stream will depend only on the history of that stream.

If you have some other conceptual model of the relationship between synaptic weight and local dvdt, a very different implementation may be required. If this is the case, perhaps we should have a private discussion via email or Skype so that I can properly advise you how to carry that out.

So neither cm nor i_cap is automatically known to code within an NMODL-defined mechanism. No problem. Only needs a few minor additions to what I have already recommended.

Add these declarations to the NEURON block of the NMODL code for your synaptic mechanism:
RANGE cm : set equal to cm in relevant segment
POINTER icap : link to i_cap in relevant segment

All that remains is to use the necessary hoc statements to assign a value to cm and link icap to i_cap in the segment to which the synaptic mechanism is attached. So consider the completely arbitrary example of a synaptic mechanism that is an instance of the class Whatever (i.e. the mechanism's NEURON block declares POINT_PROCESS Whatever) attached to the middle of a section called erewhon:

thanks for your help. so far it work great. But now I was trying to speed up the simulations by using variable time step with cvode. But i_cap is fluctuating pretty much when using this and also dvdt is behaving strange because it is not any longer a linearly scaled version of i_cap. So I tried to set the tolerance with the atolscale method but this didn't work.

I don't know, but there are other ways to speed up simulations. On a multicore PC or Mac it is often possible to get significant speedups without requing any revisions to your hoc code (some mod files may need changing to make them threadsafe) by using multithreaded simulations--see http://www.neuron.yale.edu/phpBB/viewto ... =22&t=1476

Thanks for your quick response. I was just about to edit my post because I found out what the problem seems to be. My pointprocess which has a pointer to i_cap also inserts a NONSPECIFIC_CURRENT (which then influences i_cap).

So, just using a different mechansim to insert the current resolves the problem.

It would be a good idea to do a bit of accuracy testing by decreasing dt for the fixed step method
and decreasing tolerance for cvode. Neither method is designed for the case where dv/dt appears on the
right hand side of the y' = f(y) equations inside f. For the fixed step method, one expects 1st order
accuracy since i_cap is calculated just before solving the equations in state blocks. i.e i_cap is evaluated using
v(t+dt)-v(t)/dt and that value is the one you are using as a constant for the integration interval t-dt/2 to t+dt/2.
It your case it is fine to use cnexp since v' and i are constants during the integration interval.

For cvode it would be nice to be able to use v' directly since it just so happens that the evaluation of
y' = f(y) does the v's prior to the nmodl states. Therefore, in principle, one could reach into the y' vector when
it is time to evaluate w'. However, also in principle, cvode could slow down since there is no provision in the
jacobian for terms involving y' on the right hand side. I see that when cvode is used, i_cap is evaluated after the
nmodl ode's y' are evaluated. So you are using the value from the previous evaluation of f(y).
You might experiment with editing nrn/src/nrncvode/occvode.cpp . Notice the two fragments having the lines: