Following discussion at the field-aligned modeling ISSI meeting, there's a consensus that having a single package to read output from multiple models and expose them via a single API would be very useful.
Currently, the Strand object is tied fairly closely to the reading of HYDRAD results. A reasonable plan might be to pull out the non-HYDRAD specific bits, create a BaseStrand object and then let HYDRADStrand, RADYNStrand, etc. inherit from this. We could then use a factory pattern such that users instantiate a Strand and the particular subclass is created based on the input file type. This is similar to how the Map object works in SunPy.
@goobley has already developed [radynpy]() so we should be able to benefit from the readers already implemented there. These could be pulled into this package or radynpy could just be an optional dependency.
Following discussion at the field-aligned modeling ISSI meeting, there's a consensus that having a single package to read output from multiple models and expose them via a single API would be very useful.
Currently, the
Strandobject is tied fairly closely to the reading of HYDRAD results. A reasonable plan might be to pull out the non-HYDRAD specific bits, create aBaseStrandobject and then letHYDRADStrand,RADYNStrand, etc. inherit from this. We could then use a factory pattern such that users instantiate aStrandand the particular subclass is created based on the input file type. This is similar to how theMapobject works in SunPy.@goobley has already developed [radynpy]() so we should be able to benefit from the readers already implemented there. These could be pulled into this package or radynpy could just be an optional dependency.