Chamel/equinox api

[cmhamel]

Attempt at "re-writing part of the interface as equinox modules. This buys us a few things

1. Allows for jittable containers for Functionspaces, Mechanics, etc.
2. Easier more python like coding style with class structures, methods, and inheritance
3. Reduces code bloat by removing a functional style that jax enforces
4. Probably some other things I haven't thought of yet.

I've mainly ported QuadratureRule, FunctionSpace, and Mechanics so far.

Also I created a new class called "Domain" which removes a good bit of boiler plate code to run an optimism problem.

[cmhamel]

The vast majority of file changes in this PR are handled in my other PR related to unit testing and code coverage. This was branched off of that branch

[codecov[bot]]

Codecov Report

Attention: Patch coverage is 79.11548% with 85 lines in your changes missing coverage. Please review.

Project coverage is 76.37%. Comparing base (6782079) to head (4454bac). Report is 69 commits behind head on main.

Files with missing lines	Patch %	Lines
optimism/Mechanics.py	83.03%	38 Missing :warning:
optimism/Problem.py	41.46%	24 Missing :warning:
optimism/Domain.py	63.93%	22 Missing :warning:
optimism/Mesh.py	96.15%	1 Missing :warning:

Additional details and impacted files

@@            Coverage Diff             @@
##             main      #87      +/-   ##
==========================================
- Coverage   76.40%   76.37%   -0.03%     
==========================================
  Files          61       64       +3     
  Lines        5051     5227     +176     
==========================================
+ Hits         3859     3992     +133     
- Misses       1192     1235      +43     

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

:rocket: New features to boost your workflow:

• :snowflake: Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[cmhamel]

This is a start. Mechanics.py could be cleaned up a bit more but the main question is should we make multiblock the standard rather than having two different implementations floating around.

[btalamini]

This is a start. Mechanics.py could be cleaned up a bit more but the main question is should we make multiblock the standard rather than having two different implementations floating around.

I’m looking forward to test driving this!

I’m also bugged about the code duplication with the multi-block stuff. I was considering going the other way and removing the multi-block version. There are usually only a few materials in our simulations. It might be easier to just have the user sum the contributions in their energy function.

[ralberd]

This is a start. Mechanics.py could be cleaned up a bit more but the main question is should we make multiblock the standard rather than having two different implementations floating around.

I’m looking forward to test driving this!

I’m also bugged about the code duplication with the multi-block stuff. I was considering going the other way and removing the multi-block version. There are usually only a few materials in our simulations. It might be easier to just have the user sum the contributions in their energy function.

I agree with Brandon, it may be cleaner to just have the single block mechanics functions and then the Domain class that you added can handle looping over blocks to compute energies, etc. I think it makes sense for Domain to contain the knowledge of blocks.

[ralberd]

@btalamini @tupek2. Once this gets merged in, what should be the plan to deal with the old functions? How important is backwards compatibility?