Skip to content
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

pst_from support for single column parameter files #490

Open
wkitlasten opened this issue Mar 21, 2024 · 2 comments
Open

pst_from support for single column parameter files #490

wkitlasten opened this issue Mar 21, 2024 · 2 comments

Comments

@wkitlasten
Copy link
Collaborator

MODFLOW can handle a single column of data with nlay x nrow x ncol entries (e.g., K). pst_from.add_parameters() does not seem to like those files (no index, no header). Doesn't it seem reasonable to support such a file when index_cols=None and use_cols=None?

I will try to address this tomorrow (fair warning!). Anything I might be missing?

@briochh
Copy link
Collaborator

briochh commented Mar 21, 2024

@wkitlasten this seems like something that should be supported. I would vote for using index_col=None but specifying use_col=0 for the headerless single column list file type.

The main thing to look out for is that (I think) the presence of a non None index_col is what triggers a lot of assumptions about the input file structure (ie list rather than array style). This could be switched over to use_cols being the trigger and the index that is required for the parameter name being derived from the dataframe index.

There maybe a bit of chasing it through required. Give a shout if you get stuck.

@briochh
Copy link
Collaborator

briochh commented Apr 18, 2024

The option here is to support single col inputs as either list-like or array-like.
For list-like, we would need to support passing to add_parameters() without index_cols argument and move the list-like setup trigger to use_cols. May just need chasing through methods a bit.
For array-like, we would need to circumvent the automatic get_xy trigger.
The array option might actually be easier to implement but for me it feels better to set these up list-like. Obviously supporting spatial definition for inputs like this is tricky and we might need to look at allowing more granular specification of arguments at add_pars time to support mixed model input format types (i.e. specification of input specific get_xy function/spatial mapping rather than relying on what is on the parent object).

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

No branches or pull requests

2 participants