-
Notifications
You must be signed in to change notification settings - Fork 22
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
Add a flag to disable some checks #427
Comments
Here is an example that fails: https://neuromorpho.org/neuron_info.jsp?neuron_name=Neuron-8-E-and-I-synapses The file is: And fails to load because of the following error:
|
which standard? swc, h5v1, or ascii?
I think this is doable, however not sure how difficult in the c++ implementation. In general, MorphIO should support all custom types in the swc spec.
This is a limitation of the representation which is section-based. MorphIO has to satisfy all supported representations, and some point-based features are just not compatible with all three.. @lidakanari |
@eleftherioszisis I agree this might be disruptive for other tools. However, in some cases where we need for example to view the morphology, or compute persistence, it does not make sense to discard the whole cell. I propose to have an optional argument to resolve these cases. The default behavior does not need to change. However, we can set the optional argument to "not fail the loading for non breaking issues" in software such as TMD. In addition, it would be important to still show a warning so the user is aware of the unusual behavior. I would suggest to at least try to support the data that are provided by neuromorpho.org (so swc variants) |
We currently have to focus on the MMB work; I'm open to the idea, so if you want to make an example PR that we can look at, that would work. I have a similar concern to @eleftherioszisis, in that we currently assume that the results of the parser stage pass all the invariants that the rest of the code depends on. Relaxing the parser means these invariants would have to be checked elsewhere, or that the code may crash or produce incorrect results. Fixing all these would be extremely difficult, because we'd probably only run across them when problems are raised. |
I explored the code a bit and there is a |
Yup, makes sense. |
MorphIO performs many checks when loading a file, but sometimes these checks are more restrictive than the standard (e.g. soma representation is more restrictive than the standard, it does not accept custom tree types, it does not accept bifurcations at the first point, etc.). It would be nice to be able to choose which level of checks are performed. We could start with just 2 levels: the min level for MorphIO to be able to load the file and the max level which is the current behavior. Later we could add a few other intermediate levels if it is needed.
The text was updated successfully, but these errors were encountered: