You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Right now, DataTable initialisation (from CSV files) is very tightly coupled to the risk factors defined in the config JSON files. Adding risk factors tends to break the DataTable if corresponding CSV data columns have not been provided.
We should investigate the parts of the code that prevent this from adding non-data-driven risk factors which are not initialised with data from the DataTable (CSV files), and change it to allow us to choose how risk factors are individually initialised.
We will probably, for example in the new EBM, need to declare risk factors depending on the "Foods" fields in France.NewEBM.json, and initialise/update them with our own method.
In an ideal world, the main config file, e.g. France.Config.json, should not contain risk factor variables (which are duplicated in the dynamic model config JSON anyway).
Edit: after discussion with Israel, it is agreed that the RF definition in France.Config.json is redundant, and can be removed.
The text was updated successfully, but these errors were encountered:
Right now,
DataTable
initialisation (from CSV files) is very tightly coupled to the risk factors defined in the config JSON files. Adding risk factors tends to break theDataTable
if corresponding CSV data columns have not been provided.We should investigate the parts of the code that prevent this from adding non-data-driven risk factors which are not initialised with data from the DataTable (CSV files), and change it to allow us to choose how risk factors are individually initialised.
We will probably, for example in the new EBM, need to declare risk factors depending on the
"Foods"
fields inFrance.NewEBM.json
, and initialise/update them with our own method.In an ideal world, the main config file, e.g.
France.Config.json
, should not contain risk factor variables (which are duplicated in the dynamic model config JSON anyway).Edit: after discussion with Israel, it is agreed that the RF definition in
France.Config.json
is redundant, and can be removed.The text was updated successfully, but these errors were encountered: