Stage ME-model e-type in SONATA nodes

[ilkilic]

Adds the missing etype to staged single-cell SONATA nodes, sourced from the ME-model’s E-model classification. This satisfies the BluePySnap biophysical-node requirement. Missing mtype and etype classifications are omitted instead of being written as empty strings.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

Flag	Coverage Δ
pytest	100.00% <100.00%> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

Files with missing lines	Coverage Δ
src/entitysdk/staging/ion_channel_model.py	100.00% <ø> (ø)
src/entitysdk/staging/memodel.py	100.00% <100.00%> (ø)

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[eleftherioszisis]

Is it acceptable if etype = "" to write that?

[ilkilic]

You are right, an empty string could cause failures downstream. In principle, an me-model should always have an etype but since the schema does not enforce this, it is safer to fail early. I will make staging raise StagingError when the associated me-model has no etype.

[eleftherioszisis]

Given that pref_label is in the db I would not normalize its value with strip. It should always be correct and the data considered correct or in need of correction to be dealt with somewhere else.

Suggested change

	etypes = memodel.emodel.etypes or []
	if not etypes or not etypes[0].pref_label.strip():
	raise StagingError(f"MEModel {memodel.id} has no e-type on its associated E-model.")
	etype = etypes[0].pref_label.strip()
	if etypes := memodel.emodel.etypes:
	etype = etypes[0].pref_label
	else:
	raise StagingError(f"MEModel {memodel.id} has no e-type on its associated E-model.")

[eleftherioszisis]

I would also do exactly the same for mtype before downloading below so that it fails early.

[eleftherioszisis]

I suppose these should not be set as ""

[ilkilic]

After discussing this further with @darshanmandge, we concluded that etype needs to remain optional as well. Ion channel models are also staged as SONATA circuits but do not have mtype or etype classifications. The current BlueCelluLab execution path does not require these properties so I propose writing them when available and omitting the datasets otherwise rather than failing staging or writing empty strings.
@chr-pok, would it be possible to make mtype and etype optional in BluePySnap validation when they are unavailable?

One additional consideration is that Neurodamus currently reads mtype unconditionally during normal loading while missing etype is tolerated. Its dry-run path reads both properties unconditionally. We will therefore need to update those paths before migrating the execution backend to Neurodamus.

[eleftherioszisis]

The current BlueCelluLab execution path does not require these properties so I propose writing them when available and omitting the datasets otherwise rather than failing staging or writing empty strings. @chr-pok, would it be possible to make mtype and etype optional in BluePySnap validation when they are unavailable?

The node files generated should conform to the SONATA spec, where mtype and etype are mandatory. See: https://sonata-extension.readthedocs.io/en/latest/sonata_tech.html

Parsers are implemented according to the spec, therefore the spec should determine what should be there, not BlueCelluLab.

[chr-pok]

@chr-pok, would it be possible to make mtype and etype optional in BluePySnap validation when they are unavailable?

I think we could make them optional under certain conditions. In the longer term, the plan was to refine the validation and specs w.r.t. the properties that are really mandatory depending on the different types of circuits (like regular circuit, EM circuits, etc.). There is a ticket for it already: https://github.com/openbraininstitute/prod-build-circuit/issues/49 (but not yet worked on).

But for the time being you could skip SNAP validation when registering the circuit. There is a flag for this and this is already skipped in the EM synapse mapping task as well until we have a better solution: register_circuit(..., skip_validation=True)

[ilkilic]

But for the time being you could skip SNAP validation when registering the circuit. There is a flag for this and this is already skipped in the EM synapse mapping task as well until we have a better solution: register_circuit(..., skip_validation=True)

Thanks, that sounds like a good temporary solution. I understand this means the generated circuits won’t fully conform to the current sonata spec but we need to support these circuit types now. I have updated this PR to only write mtype and etype when available. I will use skip_validation=True during registration and link to openbraininstitute/prod-build-circuit#49. Does that sounds reasonable to you @eleftherioszisis ?