allow input fields to not be in the output

[gdementen]

It might be a good idea to rework the way to declare fields:

input:
    - earny: float
    - wstatus: int
    - wzas: int
    - yob: int
output:
    - cscar: int
    - csw: float
    - cswl1: float

[gdementen]

Another option would be to make the saving to hdf5 step an explicit function, so that the modeller can choose when and what to save.

[gdementen]

Another option would be to make the saving to hdf5 step an explicit function, so that the modeller can choose when and what to save.

[gdementen]

Basically, we get two different options:

• do it in the field definition (like above or output=False in the current way to defined them)
• explicit step (hdf(dump())

explicit step seems better in the long term but has more implications because there might not be a "user" .h5 file at all.

In either case, we cannot rely anymore on lag fields being present in the hdf file (for lags > 1 period), so we will need to store them elsewhere, in either a system table in the same file, or in another file entirely. It is probably cleaner to use another file entirely to not pollute the user file with something he does not care about.

By the way, only saving the fields which are not manually saved by the user seem like a bad idea, because it would be too fragile: the user could save it at a different time than what we need (eg before the field is updated within the period), or only under some condition... So, we will just save them in the system file (or table within normal hdf file) and close our eyes on potential duplication with what the user saves...

[gdementen]

Basically, we get two different options:

• do it in the field definition (like above or output=False in the current way to defined them)
• explicit step (hdf(dump())

explicit step seems better in the long term but has more implications because there might not be a "user" .h5 file at all.

In either case, we cannot rely anymore on lag fields being present in the hdf file (for lags > 1 period), so we will need to store them elsewhere, in either a system table in the same file, or in another file entirely. It is probably cleaner to use another file entirely to not pollute the user file with something he does not care about.

By the way, only saving the fields which are not manually saved by the user seem like a bad idea, because it would be too fragile: the user could save it at a different time than what we need (eg before the field is updated within the period), or only under some condition... So, we will just save them in the system file (or table within normal hdf file) and close our eyes on potential duplication with what the user saves...