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

Inconsistent handling of "integration_method" in simulation config #275

Open
seirios opened this issue Nov 1, 2024 · 3 comments
Open

Inconsistent handling of "integration_method" in simulation config #275

seirios opened this issue Nov 1, 2024 · 3 comments

Comments

@seirios
Copy link

seirios commented Nov 1, 2024

Hi!

I'm seeing inconsistent handling of the "integration_method" variable as either an integer or a string.

When using an integer (0), I get:

$ bluepysnap validate-simulation simulation_config.json
FATAL: simulation_config.json:
        run.integration_method: 0 is not of type 'string'
        run.integration_method: 0 is not one of ['0', '1', '2']

and when using a string ("0"), I get:

sim = snap.Simulation('simulation_config.json')

=> libsonata._libsonata.SonataError: Invalid value: '"0"' for key 'integration_method'

I'm using py-bluepysnap/3.0.1 module from BB5.

@mgeplf
Copy link
Contributor

mgeplf commented Nov 4, 2024

Thanks for the report.

It looks like the snap version (ie: bluepysnap validate-simulation simulation_config.json) is correctly implemented according to the spec:
image

From: https://sonata-extension.readthedocs.io/en/latest/sonata_simulation.html#:~:text=specific%20details.-,integration_method,-text

However, I'm not sure why it's a string, considering it's numeric data.
Even more puzzling is why we use numbers and not names.
Probably worth getting input from @WeinaJi, @jorblancoa or @ferdonline since they generally handle the simulation config specs and implementation.

@WeinaJi
Copy link

WeinaJi commented Nov 4, 2024

There is a mismatch between the spec and the implementation in the libsonata parser.
The string "0"/"1"/"2" was in the legacy BlueConfig format and we copied it to the sonata spec. However, in the libsonata parser, we accept this key value to be numbers 0/1/2 and pass it to neurodamus and eventually to NEURON.

I can update the spec to use the int values 0/1/2, if that's fine for you.
For names such as "euler", "nicholson", "nicholson_ion", we need to update the libsonata parser, but NEURON still accepts integers.

@jorblancoa
Copy link
Contributor

I guess being an integer was done to be consistent with NEURON secondorder
https://nrn.readthedocs.io/en/latest/python/simctrl/programmatic.html#secondorder

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

4 participants