Thermoelastic3d

[gapaza]

Description

This is the second version of this pull request, as the first didn't pass the mypy or ruff checks. I think mypy still fails because of a line in heatcondiction3d, but I didn't want to be both adding this problem and fixing the heatconduction3d one.

This pull request contains the entire codebase for the thermoelastic3d problem. It is quite similar to the thermoelastic2d problem with some minor additions. Two new dependencies were added to the pyproject.toml file. One outstanding issue to be resolved is the render function. I am using napari to visualize the 3d designs, so I am returning the napari np.ndarray in this function as I couldn't find a figure class like matplotlib. Besides this, everything seems ok for the time being.

Fixes # (issue)

Type of change

Please delete options that are not relevant.

• New feature (non-breaking change which adds functionality)

Checklist:

• I have run the pre-commit checks with pre-commit run --all-files
• I have run ruff check . and ruff format
• I have run mypy .
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes

Reviewer Checklist:

• The content of this PR brings value to the community. It is not too specific to a particular use case.
• The tests and checks pass (linting, formatting, type checking). For a new problem, double check the github actions workflow to ensure the problem is being tested.
• The documentation is updated.
• The code is understandable and commented. No large code blocks are left unexplained, no huge file. Can I read and understand the code easily?
• There is no merge conflict.
• The changes are not breaking the existing results (datasets, training curves, etc.). If they do, is there a good reason for it? And is the associated problem version bumped?
• For a new problem, has the dataset been generated with our slurm script so we can re-generate it if needed? (This also ensures that the problem is running on the HPC.)
• For bugfixes, it is a robust fix and not a hacky workaround.

[g-braeunlich]

The docs seem to be missing (see docs/README.md)

[SoheylM]

In summary:

• Fix the TODO comment or document the reason
• Correct the docstring in shape_fun_and_derivs
• Add error handling for solver failures
• Add shape validation for boundary condition arrays
• Consider extracting magic numbers to named constants
• Verify render() return type matches annotation
• Add unit tests for the elasticity matrix construction

[SoheylM]

fem_setup does large matrix operations without explicit memory management. Could we use sparse matrix operations to optimize a bit?

[gapaza]

For assembling the global stiffness matrices I am using coo_matrix for speed (these are sparse). For solving the linear system, I am using an iterative solver to massively reduce the memory requirement. Is there an additional area in particular where I should be using sparse matrices?

[gapaza]

The docs seem to be missing (see docs/README.md)

Added README.md file with problem information.

[gapaza]

So I fixed all the mypy related errors for the thermoelastic3d problem, however mypy still fails because other problems are triggering mypy errors (specifically airfoil and thermoelastic2d). When I merged in thermoelastic2d last year, there were no issues with mypy. As such, I believe that the git action verifying mypy errors may have changed (specifically I think it is using a newer python version and thus a newer mypy version). Below is the mypy error message from the git action:

engibench/problems/airfoil/utils.py:265: error: Argument 5 to "_order_segments" has incompatible type "ndarray[tuple[int], dtype[signedinteger[_32Bit | _64Bit]]]"; expected "ndarray[tuple[Any, ...], dtype[signedinteger[_32Bit]]]" [arg-type]
engibench/problems/airfoil/utils.py:269: error: Argument 3 to "_reorder_coordinates" has incompatible type "ndarray[tuple[int], dtype[signedinteger[_32Bit | _64Bit]]]"; expected "ndarray[tuple[Any, ...], dtype[signedinteger[_32Bit]]]" [arg-type]
engibench/problems/thermoelastic2d/model/fem_setup.py:152: error: Incompatible types in assignment (expression has type "ndarray[tuple[int], dtype[signedinteger[_32Bit | _64Bit]]]", variable has type "ndarray[tuple[int, int], dtype[signedinteger[_32Bit | _64Bit]]]") [assignment]
engibench/problems/thermoelastic2d/model/fem_setup.py:153: error: Incompatible types in assignment (expression has type "ndarray[tuple[int], dtype[signedinteger[_32Bit | _64Bit]]]", variable has type "ndarray[tuple[int, int], dtype[signedinteger[_32Bit | _64Bit]]]") [assignment]
engibench/problems/thermoelastic2d/model/fem_setup.py:156: error: Incompatible types in assignment (expression has type "ndarray[tuple[Any, ...], dtype[signedinteger[Any]]]", variable has type "int") [assignment]
engibench/problems/thermoelastic2d/model/fem_setup.py:157: error: Incompatible types in assignment (expression has type "ndarray[tuple[Any, ...], dtype[signedinteger[Any]]]", variable has type "int") [assignment]

One solution is to decide on a specific version of mypy to use, and use this for all future git actions. Curious to hear other opinions on this.

[g-braeunlich]

The philosphy so far was to always use the lates mypy / ruff, so we gradually improve our codebase with every improvement in the tools.

[gapaza]

The philosphy so far was to always use the lates mypy / ruff, so we gradually improve our codebase with every improvement in the tools.

That sounds good to me. For the pull request then, I would need to make the fixes on the airfoil and thermoelastic2d problems as well. I authored the thermoelastic2d problem so this is no problem, but are you alright if I make the changes for the airfoil problem as well? Let me know and I will commit the new changes.

[g-braeunlich]

As you like. You also can push what you have and hand over your PR to @cashend which authored the airfoil problem. I also would offer to take over. But if you already have fixes, then also push those and let @cashend review.

[g-braeunlich]

I fixed the typing issue in a separate PR which @markfuge approved. This PR has been rebased now on the merged PR. Tests should pass now

[markfuge]

@gapaza I think we can merge this now that @g-braeunlich has merged in the mypy fixes for the unrelated problems. Is this correct?

@g-braeunlich are there other changes you need or can we approve this?

I'll note that the one check that didn't pass was the windows test due to a timeout. We can discuss in the next EngiBench meeting how to handle this, but I don't think this is a problem with this particular PR.

[g-braeunlich]

Just left a minor suggestion, which should be ready to accept by a click

[markfuge]

Okay @g-braeunlich I accepted the suggestion. If you can go ahead and approve your review of the PR to unblock the merge, then @gapaza can merge it in when he is ready.