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

Raise an error for not allowed or incorrect instructions #7

Open
kupiqu opened this issue Feb 6, 2015 · 1 comment
Open

Raise an error for not allowed or incorrect instructions #7

kupiqu opened this issue Feb 6, 2015 · 1 comment

Comments

@kupiqu
Copy link
Collaborator

kupiqu commented Feb 6, 2015

I have experienced two issues recently about introducing instructions that were not correct, but no error was raised (one related to the gaba connectivity and the other one about changing values in buildmodel). Of course that was my fault of using incorrect instructions, and It is true that one can use the verbose mode and check, one by one the different equations and initial conditions, but this would be better used for debugging purposes for us, not for an average user using a stable version (a user just wants to get her work done, and unless an error happens, not to worry much).

Therefore, I would highly encourage having an instruction monitor, so this sort of errors are not silent but reported as an error (i.e. stopping the simulation).

@jsherfey
Copy link
Owner

jsherfey commented Feb 6, 2015

Further comments:

The intention would be to detect if there is a syntactic error in a function call.

For instance

models{1} = buildmodel(MSNpop_spec,'override', {'MSN','g_m',g_m},'verbose',0);

Instead of

models{1} = buildmodel(MSNpop_spec,'override', {'MSN','parameters','g_m',g_m},'verbose',0);

should raise an error, and as informative as possible about possible causes to guide the user:

  • In our current implementation, if you introduce 3 params in {}, the second one should be either 'label' or 'N' (if I'm not wrong), anything different than that should raise an error and stop the simulation.

If the only possiblity for 4 params is through 'parameters' (which I am not completely sure of), then an informative error output would be sth like:

  • " 3 params within {} implies modifying a 'label' or 'N', but instead 'g_m' was found, did you forget to add 'parameters' first? "

Of coarse this is just an example, to illustrate it, and if we change this to make it more transparent (as you suggested in the previous issue), that will be great.

But to show another example of monitoring imaging the following example:

models{1} = buildmodel(MSNpop_spec,'override', {'MNS','label','MSN_D2'},'verbose',0);

There is a typo in the original label which is not monitored, as a result model{1} is called MSN instead of MSN_D2 and that can create some trouble reusing model{1} in a more complicate model.

Or this other typo

models{1} = buildmodel(MSNpop_spec,'override', {'MSN','n',200},'verbose',1);

The resulting model would still have the previous number of cells instead of 200, without any error being raised.

These are sort of things that we would need to double-check internally in my opinion, so they are consistent, or otherwise inform about the issues. What do you think?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants