Linter

[dilpath]

A list of things that should be checked by extending the libpetab-python PEtab v2 linter.

NN model via NN model YAML format

• NN inputs/outputs are valid/unique PEtab IDs (inputs and outputs can be the same PEtab ID if the NN does nothing -- this is fine)
• layers/activation functions are in this list: https://petab-sciml.readthedocs.io/latest/layers.html

Hybridization table

• targetIds are not also targetIds in the condition table
• targetIds are not also inputIds or parameterIds in the array data files
• NN inputs are not in targetValues
• NN outputs are not targetIds
• targetValues contain valid PEtab math expressions
• pre-initialization--hybridized NNs are evaluable (i.e. only depend on things that are available before simulation)

Condition table

• targetIds are not also inputIds or parameterIds in the array data files
• NN inputs are not in targetValues
• NN outputs are not targetIds

Array data files

• any input in the file must have an array defined for all initial PEtab conditions

Parameter table

• a parameter with nominalValue:=array must be defined by an array
• all parameters of the NN are explicitly specified to be estimated or fixed
• if posterior then all ML parameters require one of the following
  • a proper prior
  • finite bounds

[sebapersson]

Thanks, this is great! A few comments (I will think about any additional points as well)

NN inputs/outputs are valid/unique PEtab IDs

I do not think we should require outputs to be valid/unique PEtab IDs. Since the forward pass can be written arbitrarily, nothing prevents an output from reusing an input ID.

Parameter table

• If any priors are defined in the problem, then (unless ML parameters also have priors) the ML parameter bounds need to be finite.

Hybridization table

• For simulation hybridization: should the inputs be required to be computable, and should outputs be restricted to model parameters and/or model states

[dilpath]

Thanks, this is great! A few comments (I will think about any additional points as well)

NN inputs/outputs are valid/unique PEtab IDs

I do not think we should require outputs to be valid/unique PEtab IDs. Since the forward pass can be written arbitrarily, nothing prevents an output from reusing an input ID.

Yes you're right, I meant that they are unique compared to PEtab IDs in the mechanistic model or other PEtab tables. The identity NN is supported 😀 Updated the list.

Parameter table

• If any priors are defined in the problem, then (unless ML parameters also have priors) the ML parameter bounds need to be finite.

Added 👍

Hybridization table

• For simulation hybridization: should the inputs be required to be computable, and should outputs be restricted to model parameters and/or model states

I am not sure what the check would look like to ensure that inputs are computable -- would it be different to the PEtab v2 check that will exist for condition table math expressions anyway?

[sebapersson]

I am not sure what the check would look like to ensure that inputs are computable -- would it be different to the PEtab v2 check that will exist for condition table math expressions anyway?

Probably not actually, good point!

[dilpath]

should outputs be restricted to model parameters and/or model states

I think not, since then a simulation-hybridized NN can't take output from a pre-initialization--hybridized NN as input. They can also appear in observable formulae as I recall...

[sebapersson]

I think not, since then a simulation-hybridized NN can't take output from a pre-initialization--hybridized NN as input. They can also appear in observable formulae as I recall...

Fair point!

[sebapersson]

Will the linter also check that array files follow the correct format following the schema? I think it would make the most sense in the linter.

@m-philipps and @dilpath

[m-philipps]

I haven't got around to the array files yet, but I agree that it's suitable for the linter.