Posting after discussion with @jdhughes-usgs and @emorway-usgs. I may be mischaracterizing the issue, please correct if so
Is your feature request related to a problem? Please describe.
Some standard packages (RCH/A and EVT/A) support both array-based and list-based input. Advanced packages support only list-based input.
Describe the solution you'd like
Advanced packages could also support array-based input where applicable.
As part of this effort packages could also standardize internal data structures after package load. Currently different logic is needed depending whether input is list-based or array-based.
Describe alternatives you've considered
NA
Additional context
Motivations for this are
consistent internal handling of boundary package data structures
flopy IO efficiency
This came up in the context of a PRT FMI issue reported by @mnfienen (#2042)
@wpbonelli - I'm a huge fan of allowing array-based input more generally. In particular, UZF files can really bloat when always using list-based input only. If it helps on the internals, all the better!
Posting after discussion with @jdhughes-usgs and @emorway-usgs. I may be mischaracterizing the issue, please correct if so
Is your feature request related to a problem? Please describe. Some standard packages (RCH/A and EVT/A) support both array-based and list-based input. Advanced packages support only list-based input.
Describe the solution you'd like Advanced packages could also support array-based input where applicable.
As part of this effort packages could also standardize internal data structures after package load. Currently different logic is needed depending whether input is list-based or array-based.
Describe alternatives you've considered NA
Additional context Motivations for this are
This came up in the context of a PRT FMI issue reported by @mnfienen (#2042)