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)

[g-braeunlich]

Suggested change

	xi_nodes = np.array([-1, 1, 1, -1, -1, 1, 1, -1], dtype=float)
	et_nodes = np.array([-1, -1, 1, 1, -1, -1, 1, 1], dtype=float)
	ze_nodes = np.array([-1, -1, -1, -1, 1, 1, 1, 1], dtype=float)
	xi_nodes = np.array([-1, 1, 1, -1, -1, 1, 1, -1])
	et_nodes = np.array([-1, -1, 1, 1, -1, -1, 1, 1])
	ze_nodes = np.array([-1, -1, -1, -1, 1, 1, 1, 1])

np.float64 / float is default

[g-braeunlich]

Suggested change

	def fe_melthm_3d(nu: float, e: float, k: float, alpha: float) -> tuple[np.ndarray, np.ndarray, np.ndarray]:
	def fe_melthm_3d(nu: float, e: float, k: float, alpha: float) -> tuple[NDArray[np.float64], NDArray[np.float64], NDArray[np.float64]]:

This requires:

from numpy.typing import NDArray

Similarly below

[g-braeunlich]

Suggested change

	def __init__(self, *, plot: bool = False, eval_only: bool | None = False) -> None:
	def __init__(self, *, plot: bool = False, eval_only: bool = False) -> None:

[g-braeunlich]

Suggested change

from __future__ import annotations

Already requiring python >= 3.10. So this is no longer needed.
Also, this is in conflict with our constraint api which relies on the types in signatures, which __future__.annotations will convert into strings.

[g-braeunlich]

Suggested change

	def __init__(self, seed: int = 0) -> None:
	"""Initializes the thermoelastic3D problem.
	Args:
	seed (int): The random seed for the problem.
	"""
	super().__init__(seed=seed)
	def reset(self, seed: int | None = None) -> None:
	"""Resets the simulator and numpy random to a given seed.
	Args:
	seed (int, optional): The seed to reset to. If None, a random seed is used.
	"""
	super().reset(seed)

Redundant