A file format standard for specifying jaxley models

[jnsbck]

@kyralianaka implemented some kind of yaml parser to set up her networks in jaxley. I think this is a really great tool!
Since I am currently writing an io submodule, I thought it would be a great addition to also include a file parser, that would let the user specify networks without having to code. I.e. via from_yaml, to_yaml or from_json, to_json. To do this well, we should come up with a file format that is suitable for this, such that we can write a parser. Therefore I am starting this discussion, so you can all chime in.

Considerations:

• Modules should be specifiable at every level.
• one should be able to name everything (like groups, channels, etc.)
• connectivities should be specifiable
• morphology (could be fpath to .swc file or sth.)
• Format should be as future proof as possible (I think since the API is pretty much set in stone now, this should be doable if we think careful about it)
• every parameter should be setable ideally.

Idea sketch:

I think something along the lines of the following could work.

Network:
 - name: net
 - Connection:
  - type: TestSynapse
  - from:
   - cell: cell1
   - branch: 0
   - comp: 0
  - to:
   -  cell: cell2
   - branch: 1
   - comp: 1
 - Cell:
  - name: cell1
  - Connection:
   - type: branch
   - from:
    - branch: branch1
   - to:
    - branch: branch2
  - Branch:
   - name: branch1
   - group: soma
   - nsegs: 4
   - compartments: comp1
   - Compartment: 
    - name: comp1
    - Channel:
     - type: HH_Na
     - name: Na1
     - gNa: 0.1
     - eNa: 35
  - Branch:
   - name: branch2
   - nsegs: 4
   - compartments: comp1
   - Compartment: 
    - name: comp1
- Cell:
 - name: cell2
 - ...

another idea sketch, that is more similar to how jaxley is set up

Compartment:
 - name: comp1
 - ...

Compartment:
 - name: comp2
 - ...


Branch:
 - name: branch1
 - input: 
  - comp1
  - comp1
  - comp1
  - comp1

...

Network:
 - name: net1

[michaeldeistler]

This is cool, but I would argue it should live outside of jaxley, in sth like jaxley_tools

[jnsbck]

should we move the whole io there as well then?

[michaeldeistler]

hm, not fully sure. To me the whole io feels sufficiently close to jaxley, but I don't have a strong opinion

[kyralianaka]

Making something like this (interpretable) would be nice, but I would caution against adding a lot of detail.

I would err on the side of leaving out connectivity because it's not very easy to look at, and nobody would want to write or read in a yaml or json file which cells are connected to which. Unless maybe you just specify full connectivity or sparse connectivity.

It really seems to work the best when lots of parameters are shared e.g. mechanisms, synapse types, coordinates, etc. ... otherwise things could get out of hand very quickly.

Something I could see doing is just creating a tutorial where one specifies module characteristics in a yaml file and then loads it in a notebook and does something with it, and then suggest that other people could do something similar if they wanted, but of course @jnsbck feel free to try what you want :)

[michaeldeistler]

I talked to Anton Arkhipov and he suggested to use sonata.