Side effect of notch_approximation_law.stress

[maierbn]

Describe the bug
After call to notch_approximation_law.stress(value), the value object is sometimes changed. This is an unwanted side effect of this function.

To Reproduce
Hard to reproduce, it was observed in _compute_hcm_RAM where we have:

extended_neuber = pylife.materiallaws.notch_approximation_law.ExtendedNeuber(E, K_prime, n_prime, K_p)
extended_neuber_binned = pylife.materiallaws.notch_approximation_law.Binned(
        extended_neuber, maximum_absolute_load, 100)

This calls materiallaws.notch_approximation_law.Binned._create_bins_single_assessment_point where self._lut_primary_branch.load is changed during

self._lut_primary_branch.stress \
            = self._notch_approximation_law.stress(self._lut_primary_branch.load)

Expected result
self._notch_approximation_law.stress does not change the argument, self._lut_primary_branch.load in this case.

Environment (please complete the following information):

• OS: Windows 11
• How installed: pip
• Version: develop branch

Additional context
The problem was tracked back and it seems scipy.optimize.newton(func, x0) changes x0 if it is an object like a pd.Series.

[maierbn]

The issue arises with numpy>=2, even when using Python 3.12 (it is not specific to Python 3.13).

If you have a Python project that uses numpy version 2 and you import the released pylife (which is only tested with numpy 1), certain results—specifically those utilizing the HCM algorithm—will be incorrect. There won’t be any runtime errors, but the computed values will be wrong.

[maierbn]

Using the fix with copy(x0) will make it work also for numpy 2 (at least in the cases in my setup)

[johannes-mueller]

Closed as of #139

[maierbn]

I can confirm that the issue is now fixed with #139 (using np.asarray instead of copy(x0))