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

Create VariableSymbols for every differential order for variables? #299

Open
PTraeder opened this issue Nov 1, 2016 · 8 comments
Open

Comments

@PTraeder
Copy link
Contributor

PTraeder commented Nov 1, 2016

Since the LHS of an ODE can be typed "dynamically" to some extend ( magnitude information can be modified depending on the defining ODE) it might be sensible to create symbols for each and every occurring differential order of a given variable, not just all but the highest one.

This would help me shut up the warnings from issue#291 in cases where a suitable type can be inferred.
Otherwise a switch for typechecks that ignores magnitude is the only option.

@DimitriPlotnikov What do you think?

@DimitriPlotnikov
Copy link
Contributor

@PTraeder Actually for an ODE system:

g_in'' = -g_in'/tau_syn_in
g_in' = g_in' - g_in/tau_syn_in

g_in is a state variable, g_in' is added due to the first equation. Which symbols would you like to create additionally?

@PTraeder
Copy link
Contributor Author

PTraeder commented Nov 6, 2016

I think I am just generally confused with the ODE syntax.

Do we have the guarantee that the rhs of ODEs will only ever include derivations of order n-1 (where the order of the lhs would be n)?

@Silmathoron
Copy link
Member

Silmathoron commented Dec 14, 2016

Actually, I just stumbled upon this issue, which I think is related to a problem I saw regarding magnitudes: derivatives are not computed in the "coherent" magnitudes for NEST (e.g. I_syn_ex' can be nA/s or things like that). The derivative of a current should (to me) be pA/ms, that of a voltage should be mV/ms.

I do not understand what bothers @PTraeder but I think maybe the problem partly comes from the choice in the "default" magnitudes:

  • the international system's magnitudes are what they are (A, m, V...)
  • in neurosciences, the most relevant system of magnitudes is the one used in NEST because it gives results that are closest to the unit value, therefore easy to read/understand, and it is coherent (e.g. pA = mV*nS)

Therefore, I think it would be a good idea that:

  1. the units arrays be expressed in these neuroscience magnitudes
  2. the user be asked to declare all state variables using these magnitudes

@PTraeder
Copy link
Contributor Author

This really just related to implementation details and the concept behind @DimitriPlotnikov implementation of the ODE system's internals and the issue could be considered closed.

With regards to @Silmathoron suggestions: changing the standard "s" to a "ms" is probably perfectly reasonable, as this relates more to simulation resolution (I assume).
However wrt forcing the use of NEST conform units I have my doubts as it limits generality. What is your opinion @DimitriPlotnikov ?

@Silmathoron
Copy link
Member

Silmathoron commented Dec 14, 2016

I'm not talking about time: you would need to change all default magnitudes to match the "neuroscience system", which, I think, is:

  • pA
  • nS
  • mV
  • pF
  • \mu m
  • mH (millihenry)
  • pN
  • g
  • s

As you can see, time is usually in seconds: here, the problem comes from NEST... (I was a bit too quick in asserting the coherence of the NEST system)
However, I think in all current models, time never appears explicitly, or at least it is always divided by another time, so the problem does not occur and changing its unit should not matter except with the derivatives.

The way I see it, it would be better to be coherent and implement the "neuroscience system" as is... but this would mean converting the time constants.
However if you think converting back and forth from s to ms would be too much of a bother, you can probably use ms.

I would still recommend talking about this in more details with the community, though, as it is not a completely trivial matter.

@DimitriPlotnikov
Copy link
Contributor

@Silmathoron
Currently, we convert everything to the following "neuroscience" SI units:

milli seconds - ms
pico farad   - pF
milli volt    - mV
pico ampere  - pA
nano siemens - nS
mega ohm     - MOhm

@Silmathoron
Copy link
Member

Silmathoron commented Jun 1, 2017

Hi @DimitriPlotnikov!
Didn't we say we'd try to define SN (système NEST) units ^^

My idea was that the system should be coherent, based on the main NEST units (mV, pF, nS, ms)

Therefore the resistance should be such that U = RI works as [U] = mV = [R] [I] = [R] * pA
Which means that the magnitude of R in Ohms should be 1e-3 / 1e-12 = 1e9, which gives Gigaohms.

But this was just the way I thought we should try to use, so I'd like to have @jougs and @heplesser opinions on that matter, since I think it is more a matter of how handy and natural the units are...

@DimitriPlotnikov
Copy link
Contributor

@Silmathoron indeed. that is what we are working on.
The list I posted was created in one of the NESTML meeting. It is either complete not fixed. I'll created #362 to discuss this topic.

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

3 participants