New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

allow input fields to not be in the output #58

Closed
gdementen opened this Issue Feb 13, 2014 · 2 comments

Comments

Projects
None yet
1 participant
@gdementen
Member

gdementen commented Feb 13, 2014

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

@ghost ghost assigned gdementen Feb 13, 2014

@gdementen

This comment has been minimized.

Show comment
Hide comment
@gdementen

gdementen Apr 28, 2014

Member

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.

Member

gdementen commented Apr 28, 2014

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

This comment has been minimized.

Show comment
Hide comment
@gdementen

gdementen Jan 23, 2015

Member

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...

Member

gdementen commented Jan 23, 2015

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 gdementen closed this in ec595f8 Jun 3, 2015

@gdementen gdementen added this to the 0.10 milestone Jun 3, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment