How decoupled can a cost model for a given technology be from a performance model?

[johnjasa]

In our new framework, users select performance, cost, and other models at the config level. How decoupled should these models be from each other? Sould we support using heterogeneous performance and cost models? E.g. should we allow pySAM performance and a non-pySAM cost model for use with wind?

If we can make the assumption that we are using the same types of performance and cost models for a given technology, it might simplify the generality necessary for passing data between the models. My understanding is that we don't want to make any assumptions about the types of models used within a given technology, though. Because of this, I believe we'll need to intelligently make sure the performance models are passing all necessary information to the cost/LCA/etc models. Will this necessary info be more than just the resources used or generated by that technology?

[jaredthomas68]

This is a tough one, but I think generally the performance and cost models should be fully independent. The dependency between them is part of our current struggle in HOPP. However, in some cases they may be in a tool where they cannot be decoupled, it which case we may just pull cost outputs from the performance model and pass them to the cost model for storage. In other cases they will both just need basic information, like system rating, and will not need to communicate at all between performance and cost models.

As for what is passed between them, I think that will depend on what performance and cost models are being used. Some models, like the pysam financial takes an enormous number of inputs, so we will just need to decide what information we are going to provide and use defaults for everything else. I think generally though that performance will just need to pass the actual production amount (total for all time steps or on a per-time-step basis) to the cost model. The physical design model may also need to pass information like transportation distance to the cost model.

I'm not sure this comment is super helpful, but I think what I'm really getting at is that we may need to be highly flexible in what information we pass between models inside a given technology, perhaps akin to the **kwargs syntax in python.

[bayc]

Yea, I think to achieve the modularity we want, we will want to be able to use different models. As such, I think we need to define a base API for each technology type, and then specific models can require additional parameters as needed (supported through either attrs or **kwargs as Jared suggested above.