Thread wizard shows 18 of 175 model configurations: the model tree query accepts only sdm#Model

[mosoriob]

Question

Which software types belong in the model tree? Then apply that rule to the three queries that
use modelcatalog_software.

Why this blocks the SOW

At TACC the thread wizard cannot reach one single runnable model.

• TACC holds 175 leaf model configurations. The Models step shows 18. It hides 157.
• 61 of the 175 have every required input annotated in CKAN, so a thread can bind data to
  them. 0 of those 61 are visible.
• The Height Above Nearest Drainage (HAND) model has 44 configurations at TACC. All 44 are
  hidden.

This blocks #92, which needs a model with
real data. It also blocks #77: TACC must
meet a Models step that works.

Root cause

Three queries filter the software table on one exact type:

where: { type: { _eq: "https://w3id.org/okn/o/sdm#Model" } }

• GetModelTreeWithRegions — src/graphql/generated/modeling.ts:1396 — the wizard Models step
• GetModelTree — src/graphql/queries/model-catalog.graphql:7 — /regions/:id/models
• GetModelFamilies — src/graphql/queries/model-catalog.graphql:169 — model registration

sdm#Model is the generic type. The catalog also uses more exact subtypes. At TACC:

type	software	leaf configurations
sdm#Model	27	18
sdm#EmpiricalModel	7	53
sdm#Theory-GuidedModel	6	72
sdm#CoupledModel	4	21
sd#Software	8	8
sdm#TheoryAndEmpiricalModel	1	2
sdm#TheoryBasedModel	1	1
sdm#DataAssimilation	1	0

The legacy Lit UI reads these types the opposite way. ui/src/model-catalog-api/util.ts:38
drops sdm#Model to find the exact subtype, and util.ts:15-30 maps each subtype to a
display name. So Lit treats the subtypes as models. The React query treats them as not-models.

/models is not affected. ModelsBrowsePage uses SearchModelConfigurations, which reads the
configuration table and applies no type filter. That is why
#76 saw /models render correctly.

Evidence

Measured live in the running app, under a real Tapis token, on the dev cluster. The same
modelcatalog_software traversal, with the predicate changed:

predicate	leaf rows	HAND rows
type _eq sdm#Model (today)	19	0
no type predicate	174	44
type _neq sd#Software	169	44

In the wizard itself, a search for HAND in the Models step returns
"No models match your search."

What to decide

_neq sd#Software is the obvious candidate, but confirm it:

1. Is sd#Software the only type that must stay out of the model tree? Check what the 8
   sd#Software entries at TACC are.
2. Should GetModelFamilies use the same rule? It feeds model registration, so today a new
   version cannot be registered under HAND.
3. RegionModels shows the same tree per region. Same rule, or a different one?

[mosoriob]

Answer

No type belongs out of the model tree. All three queries drop the predicate. Fixed in PR #101, verified live in the running app: the wizard Models step now reports 175 models where it reported 18.

The premise of the three sub-questions was that some type must be excluded. It is wrong.
modelcatalog_software.type classifies a model. It does not say whether a row is a model.

• The ETL only migrated rows matching ?id a sdm:Model in the RDF, then stored the most specific sdm: subtype it found, defaulting to sdm#Model (etl/extract.py:145-171). Every migrated row is a model by construction, and the subtypes are narrower classes of model, not non-models.
• Rows written through the REST API's generic softwares resource get the ontology superclass sd#Software (model-catalog-api/src/mappers/resource-registry.ts:77). It means unclassified, not not a model.
• The legacy Lit UI reads the same column as a display label and never filters on it (ui/src/model-catalog-api/util.ts:14-44).

Q1 — is sd#Software the only type that must stay out?

No. It must stay in. All 8 sd#Software rows at TACC are models: MODFLOW-2001 ×3, MODFLOW-96 ×2, ParFlow, an InSAR Deformation Processing Workflow, and a Particle Filter Groundwater Assimilation. _neq sd#Software — the candidate the ticket proposed — would have hidden them and stopped at 169 of 175.

An allowlist of sdm# subtypes is worse. model-catalog-api already keeps one (getSoftwareTypeFilter, src/service.ts:59-76) and it is already stale: TACC's /models returns 44 of 55 software rows, silently dropping TheoryBasedModel, TheoryAndEmpiricalModel, DataAssimilation and every sd#Software row. An allowlist goes wrong every time the catalog gains a subtype, and it fails without a word. Filed separately as #102 — see Out of scope below.

Q2 — should GetModelFamilies use the same rule?

Yes. It feeds the Model Family picker on registration. Filtered, it could not offer any family whose type is a subtype, so no new version could be registered under HAND. Now 55 families, not 27.

Registration still writes sdm#Model for a newly created family (src/schemas/registration.ts:12). That is correct and unchanged: the generic type is the honest default when no subtype is known. Reading and writing are different questions here.

Q3 — RegionModels, same rule or a different one?

Same rule. /regions/:id/models shares GetModelTree and shows the same tree. It applies no region predicate of its own (the port is structural — see the comment at RegionModels.tsx:24-31), so a different rule would only have made the two disagree.

Effect at TACC

	before	after
software (model families)	27	55
versions	11	51
leaf configurations	18	175
HAND configurations	0	44

HAND — the largest family at TACC — is typed sdm#EmpiricalModel, precisely what the filter excluded.

Verified live

Signed in as mosorio against TACC's Hasura, on the real thread nzGQkhtRsudfSEHkDGct (Maximize Pumping, Texas). The Models step banner reads "0 of 175 models" — the 175 is allRows.length, exactly the count measured against Hasura. All three shipped documents were also run directly against graphql.mint.tacc.utexas.edu and each returns 55 / 51 / 175 with 44 HAND leaves.

No writes. The thread still has zero thread_models and TACC's catalog is untouched — the walkthrough read only.

The next wall for #92, and it is not this one

That banner says 0 of 175, not 175. The 0 is the indicator facet, a filter this ticket never touched: ModelsStep keeps only rows whose outputs carry the thread's response_variable_id, and that thread's indicator is total_water_storage, which no configuration at TACC produces. It is a legacy lowercase id; every live indicator uses CSDMS-style names.

Now measurable across the whole catalog for the first time:

• 141 of 175 leaves carry at least one output standard variable. 34 carry none and are unreachable through any indicator.
• 146 distinct output standard variables exist.
• The three most common are RECHARGE_VOLUME_FLUX, DRAWDOWN and STORAGE_VOLUME — 44 leaves each, i.e. the whole HAND family.

So #92 must pick a thread whose indicator is one of the 146, or set one. Picking any of those three lands on all 44 HAND configurations. This is the pattern the map already named: each fix reveals the next wall one step further in.

Scope

grep over ui-react confirms these were the only ontology-type filters in the app. The one remaining use of a type URI is the write-side constant on registration, which is correct. That answers the map's open question about whether other queries filter this way: none do.

Out of scope

The identical fault in model-catalog-api — #102, /models returning 44 of 55 plus four custom-handlers.ts handlers cut to 27. ui-react talks to Hasura directly and never calls that API (#72 deleted the dead MODEL_CATALOG_API key). The only consumer is the Lit UI, which stays unrouted and is being retired, so nothing on the path to sign-off depends on it. Filed so it is not lost, not carried on this map.