Test Granule cell model with neuronunit

[ddelpiano]

hi @rgerkin we tried yesterday the neuroml-db parsing functionality with the Granule model and this works on scidash. We thought this might be a good candidate for the 2 models/tests present by default for new users, in case we will need:

• the class to assign to this model.
• what test class we should use for the test instance in order to simulate this.

[rgerkin]

@ddelpiano @gidili I think I can run it with a few changes (tested):

• First, the NeuroML-DB version contains the model only but no inputs. Therefore it fails extra_capability_checks for ReceivesCurrent (based on having pulsegenerator and input or explicitinput in the .nml files). But if I use the corresponding version on OSB, it has those, basically because it adds [one more .nml file] (https://github.com/OpenSourceBrain/GranuleCell/blob/master/neuroConstruct/generatedNeuroML2/GranuleCell.net.nml), corresponding to a one-neuron network that has these components. So NeuronUnit needs to start from that file (at the URL https://raw.githubusercontent.com/OpenSourceBrain/GranuleCell/master/neuroConstruct/generatedNeuroML2/GranuleCell.net.nml), from which it can find those components, as well as recursively load the rest of the channels, etc. In testing things on NeuroML-DB with NeuronUnit, Justas worked around this in a way that won't really work for us, and I don't want to put the time into it at the moment. For the purpose of "getting one or two more models into SciDash" let's just focus on the OSB versions of those models for now.
• Second, the current NeuronUnit code was failing to find the target of the pulsegenerator because it had an input tag rather than explicitinput, so I've fixed this in NeuronUnit, and now it can pass the capability checks and be considered appropriate for tests required the ReceivesCurrent capability.
• Third, I previously did not properly understand how to handle the namespacing in XML/NeuroML, and my solution was to generate new files that stripped the name space completely from the header. I now know how to handle this without rewriting the file, so this should generalize to anything on OSB without me making my own copy of the file first.
• Fourth, with those changes everything passes but I am still unable to simulate the model using my own NEURONBackend, which in one sense is irrelevant because we won't be using that (we will be using the Geppetto backend, which should already be able to handle this OSB project), but it does sort of matter because it means I can't test anything yet on the other side of the simulation, after the result is returned, for example if the score works. I think I should write some sort of formal Geppetto backend that lets me use your API in my development environment to run models locally (or otherwise) using Geppetto, but outside of SciDash so I can strictly test NeuronUnit using Geppetto.

The fixes above are local, and I need to know where you want me to apply them. Should I branch off of the dash branch of NeuronUnit, or some tag that you are using? I want to only apply this narrow set of changes to whatever version of NeuronUnit you are using, but I'm not sure which one that is.

[ddelpiano]

Hi @rgerkin ,

We currently use neuronunit from a fork I made before the last release we made in the summer, currently we install this from the tag 4.0.0 as per requirements.txt.

Sciunit instead it's a dependency of neuronunit and it comes installed from there and for this we take your repo from development - this changed recently when we improved the installation process since before we were using a fork made along the one for neuronunit and using that for the installation.

If you want to push the fixes on top of what we are using for production it would be ideal to branch out from the tag 4.0.0, push fixes there and retag this branch so that we can move our requirements.txt to use your repo and the new tag and test if everything works fine. Thx!

[rgerkin]

OK, so it looks like tag 4.0.0 is at commit scidash/neuronunit@94f32028740ed9280fce725482a56bbc731c3773, and you always use scidash/sciunit dev. I have had a scidash/sciunit dash branch for a while, which is frozen (unless you guys specifically request a change or fix on it), which maybe you didn't know about. Assuming that scidash/sciunit dev is working for you, I should update scidash/sciunit dash to match it and then add a ddelpiano/neuronunit release that uses that branch. This will ensure that future changes to scidash/sciunit dev don't break anything for the app.

When you say re-tag, do you mean use the same tag (4.0.0) for a new code state or a new tag (e.g. 4.0.1)?

I will be sure to apply the changes focally to the 4.0.0 state and not bring any other changes with them.

[gidili]

@rgerkin We were using the dash branch for a long time but at some point dev was merged into dash because some commits went there that we needed and it brought it a bunch of other changes so we took that opportunity to switch back to dev at that point and forked from there. I think you can get safely rid of the dash branch! @ddelpiano can correct me if I am wrong on this

[rgerkin]

You may not be using the dash branch now, but do you want such a branch (or tag) that is guaranteed to be stable? Dev is not.

[ddelpiano]

I have had a scidash/sciunit dash branch for a while, which is frozen (unless you guys specifically request a change or fix on it), which maybe you didn't know about. Assuming that scidash/sciunit dev is working for you, I should update scidash/sciunit dash to match it and then add a ddelpiano/neuronunit release that uses that branch. This will ensure that future changes to scidash/sciunit dev don't break anything for the app.

@rgerkin from what I recall from the previous contract we tried to use dash for the release but the branch was moved forward for reasons that I don't remember (it was in August) and we were not able to run simulation from there. Then we moved backwards commit by commit trying to find the point where neuronunit was still compliant with the UI and I ended up forking and using the tag 4.0.0 that, after testing, was still working. My 2 cents, I would branch out from the tag 4.0.0 something new since we know that UI and library works along from that point, we can call the branch metacell, release or whatever you prefer works for us, push the changes you are planning to apply there and retag!

(sorry if I missed any other message in the meanwhile, I had this opened and filled in for 2 hours meanwhile I was in other meetings :) )

[ddelpiano]

You may not be using the dash branch now, but do you want such a branch (or tag) that is guaranteed to be stable? Dev is not.

@rgerkin a new branch branched out from tag 4.0.0 would ideal, thanks!

[rgerkin]

There is a new branch metacell which I believe has only two new commits since your 4.0.0, both of which are required for me to run the model.

[rgerkin]

I also added a metacell branch to sciunit, branched from today's dev branch (you've always been using SciUnit dev so presumably that's as good a place as any to start).