libNeuroML icon indicating copy to clipboard operation
libNeuroML copied to clipboard

Feat: support addition of new LEMS Components to NeuroML models

Open sanjayankur31 opened this issue 1 year ago • 3 comments

These will not be validated since they're not part of the schema, but this will allow users to use Components of newly defined ComponentTypes in Python, without having to resort to editing XML later.

sanjayankur31 avatar Jul 31 '24 18:07 sanjayankur31

@pgleeson this seems to allow the addition of "<Component ..>" bits to the other elements. For ex:

        cell = component_factory("Cell", id="simple_cell")  # type: neuroml.Cell
        cell.set_spike_thresh("40mV")
        cell.set_init_memb_potential("-70mV")
        cell.set_specific_capacitance("1 uF_per_cm2")
        cell.add_membrane_property(
            "Component", id="test_comp", type="test_type", value="10 mV"
        )
        cell_str = str(cell)
        print(cell_str)

generates:

<Cell id="simple_cell">
    <morphology id="morphology">
        <segmentGroup id="soma_group" neuroLexId="GO:0043025">
            <notes>Default soma segment group for the cell</notes>
        </segmentGroup>
        <segmentGroup id="all">
            <notes>Default segment group for all segments in the cell</notes>
        </segmentGroup>
    </morphology>
    <biophysicalProperties id="biophys">
        <membraneProperties>
            <Component value="10 mV" id="test_comp" type="test_type"/>
            <spikeThresh value="40mV"/>
            <specificCapacitance value="1 uF_per_cm2"/>
            <initMembPotential value="-70mV"/>
        </membraneProperties>
        <intracellularProperties/>
    </biophysicalProperties>
</Cell>

The "Component" class requires an id and type, and then can take any other arguments---these extra ones won't be validated against the schema, but LEMS will throw errors if they are wrong/missing.

What do you think? Testing to see if LEMS is happy with this.

(If this is OK, I'll update the schema in the NeuroML2 repo too. Haven't changed that yet.)

sanjayankur31 avatar Aug 01 '24 08:08 sanjayankur31

Hrmmm, am unsure about all this... Seems to be making the schema more complex than it needs to be to fix some issues with just one of the APIs. Need to think about it a bit and discuss next time in the office...

Note there are a lot of whitespace changes in the schema which should be updated separately..?

pgleeson avatar Aug 01 '24 11:08 pgleeson

Cool, sounds good.

I think this should propagate to all APIs that properly support the anyAttribute XSD construct, since it's part of the XSD standard:

https://www.w3.org/TR/xmlschema11-1/#Wildcards

The change to generatedssuper is just me making this also accessible via the component factory framework for consistency. People can also do:

from neuroml import Component

newcomp = Component(id="something", type="something else")
newcomp.anyAttributes_ = {"att1": "1mV"} # generateDS does not handle these in the constructor for some reason

Basically each element has gained an optional "Component" child element that may be used to refer to new ComponentTypes. NeuroML files with Components are now valid against the schema too. Then LEMS will do the final checks on whether the Component refers to the right ComponentType and if it has the necessary parameters etc.

In addition to making stuff with Components valid NeuroML, the main advantage is that people don't have to manually edit XML (or JSON/YAML if we also start supporting them) files---for large cells and so on, that's tedious and error prone, and it disconnects the XML serialization from the API based model description.

Yeh, the whitespaces are because of pre-commit removing trailing whitespaces, we'll get rid of those changes before merging. We'll probably want this to bump the schema version anyway (I'll go see if there's a way of disabling that pre-commit hook for the xsd files in the meantime)

sanjayankur31 avatar Aug 01 '24 11:08 sanjayankur31