Raise an error for not allowed or incorrect instructions
kupiqu opened this issue · 1 comments
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).
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?