Migration of if-plugins to builtins

[mouhamadalmounayar]

@jmcook1186
Hello I am working on the IF integration in Amadeus,

Now that the if-plugins GitHub repository is deprecated and is not compatible with version 0.7.1, we need to migrate our existing pipeline to be compatible with this new version, we have been using the following plugins from the repository:

• e_mem: we noticed this should actually be renamed to p-mem since it computes power rather than energy. We plan to replace it with the built-in Multiply function or use inline arithmetic, which is now supported.
• sci: we intend to replace this with a sum and then use the new built-in sci to divide by the functional unit R (or simply use the divide plugin).
• sci-e: we plan to replace this with built-in sum.
• sci-m: we will replace this with the new built-in sci-m.
• sci-o: we plan to replace this with the built-in multiply.
• teads-curve: we will either use the teads curve pipeline in the documentation that incorporates sum, multiply, and interpolate, or we may rewrite a custom plugin using PluginFactory to ensure compatibility with the new version.

We have a couple of questions:

• Are you planning to convert any of the plugins on this list to built-ins in the future?
• Are you planning on having a built-in plugin to compute the energy consumption of the storage?
• Do you need assistance with this process? If so,
• Do you recommend we proceed with our replacements or do we create custom plugins (with PluginFactory) to publish on the IF Explorer for the community to use?

Thank you for your help!

[jmcook1186]

HI @mouhamadalmounayar

• we are not directly migrating any of these plugins to builtins. Each of these can be replicated using our existing builtins. The suggested replacements in your message are appropriate - let us know if anything needs clarifying.
• we do not have any plans right now to add a builtin for storage energy. I'd expect this is going to be a coefficient in kWh/GBh or similar? If so we'd just use the coefficient builtin, passing the coefficient value as an argument. We borrowed the CCF value for this in some of our recent manifests (1.2 Wh/Tbh).

If you have an alternative approach to estimating storage energy, I'd love to hear it - so far the CCF coefficient is the one I've been defaulting to.

In general, I think the most helpful thing you can do is to share your pipelines with some explanatory notes so others can copy/modify, especially if you use all builtins. One way you could do this is to push a simplified manifest (maybe for just one server, or even a hypothetical system) that uses your pipeline to this repo aproximating the format I've been using for notes, manifest and output files.

Let me know what you think, we can refine the plan so we have something that works well for you and us!

[mouhamadalmounayar]

Thank you for your response, @jmcook1186. We decided to convert everything to built-ins, but we're running into an issue with the Interpolation plugin, which errors out on zero values and is blocking our progress. I saw that this was addressed recently in #1050. Do you know when this fix will be available in the npm package?

[jmcook1186]

ah, yes that fix is available on main but not yet in the release. We can aim to cut a release tomorrow so it's available for you.