Similarly to issue #67 , there are other places in the codebase that could benefit from being streamlined into a single codepath.
A few functions call similar-but-not-quite-the-same codepaths, which introduces extra complexity in understanding program state. Perhaps some functions could benefit from being renamed, or not overloaded, too.
ModelLists and mappings also have many similar stages, but sometimes call different functions due to the multi scale handling. It seems like it might be worthwhile to consider ModelLists as multi-scale models with only a single implicit scale (without making the API more complex on the user side). There is at least one difference worth keeping, which is that with a single scale the size of the output data can be known exactly and preallocated in advance.
Issues such as issue #85 might also arise less often in the future with code flow that only splits right when specialization is needed, instead of having two more distinct but still functionally similar codepaths
Similarly to issue #67 , there are other places in the codebase that could benefit from being streamlined into a single codepath.
A few functions call similar-but-not-quite-the-same codepaths, which introduces extra complexity in understanding program state. Perhaps some functions could benefit from being renamed, or not overloaded, too.
ModelLists and mappings also have many similar stages, but sometimes call different functions due to the multi scale handling. It seems like it might be worthwhile to consider ModelLists as multi-scale models with only a single implicit scale (without making the API more complex on the user side). There is at least one difference worth keeping, which is that with a single scale the size of the output data can be known exactly and preallocated in advance.