OmltVar abstraction classes

[jezsadler]

Introducing OmltVar class, which will enable interconnectivity between OMLT and various modeling languages. As of this check-in, only Pyomo is supported. I've started work on variants using JuMP, but as yet they do not work with Expressions.

Legal Acknowledgement
By contributing to this software project, I agree my contributions are submitted under the BSD license.
I represent I am authorized to make the contributions and grant the license.
If my employer has rights to intellectual property that includes these contributions,
I represent that I have received permission to make contributions and grant the required license on behalf of that employer.

[jalving]

It looks like github actions is failing because the environment is too big. I'll look into switching to tensorflow-cpu and torch-cpu unless you want to take a stab at it @jezsadler.

[jezsadler]

From Torch's website, it looks like torch-cpu is what we're getting already by not specifying a CUDA version. I have switched to tensorflow-cpu, also set keras==2.9.0 because later version of Keras require models to be stored in .keras files, which our tests do not. I'd guess the better solution to this is to update the test models rather than pinning a Keras version, but I needed to unblock. I think hit an issue uploading code coverage - it says that the upload token isn't matching. I am a little concerned about future disk space requirements if I add Julia and additional tests to the build, but I suppose I'll deal with that when I get there.

…

On Sat, 20 Apr 2024 at 09:46, Jordan Jalving ***@***.***> wrote: It looks like github actions is failing because the environment is too big. I'll look into switching to tensorflow-cpu and torch-cpu unless you want to take a stab at it @jezsadler <https://github.com/jezsadler>. — Reply to this email directly, view it on GitHub <#141 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AM33VWGMLWSAJVD77KAVF5TY6KLXRAVCNFSM6AAAAABGP6JU4KVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANRXG4ZDMNBYGY> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[jalving]

I'll take a look at the coverage issue this week. I was going to make a manual run on main to test it out, but it looks like the CI workflow got deleted in a recent PR? I think we should get the disk space and coverage issues sorted out on main and then merge back to this PR. If we do run into more space issues, we can always create more workflows. I bet we could even put Julia tests in the lean environment.

I would also like to advocate getting the whole end-to-end JuMP-based formulation working before we consider merging. Is that the plan? If so, can we convert this to a draft PR? I am quite interested in what you have done with OmltVar as a generic interface, but I have questions about how the Pyomo model ultimately translates to a JuMP model. For instance, could we potentially come from JuMP and call out to OMLT to build formulations? Seeing the progress here, this would be a good topic for the next dev call.

[jezsadler]

Yes, absolutely, draft PR for my work makes sense - I'm not currently enabling any new scenarios, but I wanted to make sure that at this point it's not breaking anything either. And yes, enabling someone working in JuMP and using OMLT to build a formulation for a JuMP model is what I'm aiming for. It is possible at the moment through a script I wrote in Julia, which parses the OMLT/Pyomo constraints and adds them, but that is limited in scope, a bit clumsy, and doesn't really handle indexed variables/constraints well.

…

On Sun, Apr 21, 2024, 8:45 PM Jordan Jalving ***@***.***> wrote: I'll take a look at the coverage issue this week. I was going to make a manual run on main to test it out, but it looks like the CI workflow got deleted in a recent PR? I think we should get the disk space and coverage issues sorted out on main and then merge back to this PR. If we do run into more space issues, we can always create more workflows. I bet we could even put Julia tests in the lean environment. I would also like to advocate getting the whole end-to-end JuMP-based formulation working before we consider merging. Is that the plan? If so, can we convert this to a draft PR? I am quite interested in what you have done with OmltVar as a generic interface, but I have questions about how the Pyomo model ultimately translates to a JuMP model. For instance, could we potentially come from JuMP and call out to OMLT to build formulations? Seeing the progress here, this would be a good topic for the next dev call. — Reply to this email directly, view it on GitHub <#141 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AM33VWFX5NOKMAR3FHG2T7LY6SBUTAVCNFSM6AAAAABGP6JU4KVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANRYGQZTEMBVGM> . You are receiving this because you were mentioned.Message ID: ***@***.***>