Daniel Huppmann

I'm not opposed to that approach in principle, just slightly worried about how big the refactoring will be... If someone volunteers to go ahead (maybe jointly with switching to `pd.Series`...

just a thought - wouldn't it make more sense to have this as a new function `IamDataFrame.merge(other, ...)`?

Thanks @znicholls for the cross-reference. This is similar to the recent improvements of [aggregate()](https://pyam-iamc.readthedocs.io/en/latest/api/iamdataframe.html#pyam.IamDataFrame.aggregate) (#305 & #312). This now supports a `method` arg (min, max, weighted sum) and doing "bulk"...

I'm not quite sure what you have in mind and whether it's worth the additional maintenance overhead if it's just a wrapper for two or three existing functions. Can you...

Yes, pushing features that be useful to many users "upstream" is definitely welcome in principle - maybe just too specific for the infilling use-case with factors. But let me reiterate...

Just keep in mind that the growth rate from 0 to any positive value is infinite. This is why I opted for the "safe" approach in the first implementation.

thanks @khaeru, this sounds reasonable. Indeed, pyam depends on ixmp (as an optional dependency), so doing a reverse-dependency (as suggested by @gidden) might cause problems.

For [pyam](https://github.com/IAMconsortium/pyam), we had a very good experience and even got a PR to improve the docs from a reviewer at JOSS, see https://github.com/openjournals/joss-reviews/issues/1095

Sounds like a good approach to me, @znicholls. I believe that `None` is as intuitive as any string like `unspecified` and provides easier handling internally.

Seeing that this is an ongoing unresolved discussion (and in light of recent `pyam` developments), I rescind my earlier comments and think that in an `ScmDataFrame`, the `model` should indeed...