Numpy 2 comatibility - #87
Conversation
np.complex_ was removed in NumPy 2.0. np.complex128 is semantically identical and available in all supported NumPy versions. Also fixes a pre-existing bug in combine_split_comp.py where dtype=np.dtype (the class itself) was passed instead of the local variable dtype. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
NumPy 2.0 removed automatic coercion of 1-element arrays to Python scalars, so math.cos/sin/sqrt no longer accept numpy array inputs. Replace with np.cos/sin/sqrt which handle arrays natively. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
…enMDAO 3.43 Small numerical differences (~3e-6 relative) in surge_margin (N3) and battery SOC_final (HybridTwin) arise from library version changes and are not correctness regressions. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
During Newton solver warmup iterations, fltcond|Utrue can temporarily go negative, making Re negative and causing log(negative) = NaN which propagates through the Jacobian. Fix: compute Re = U*L/visc_kin and apply abs(Re) for real-valued arrays only, so complex-step derivative checking still propagates the imaginary part correctly (for complex arrays, negate Re where real(Re)<0). Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
|
Hi, thanks for working on this. We ran into the Tested at 10f644b on Python 3.12.13, with numpy 2.5.1, OpenMDAO 3.45.0 and AeroSandbox 4.2.10. Full suite from source, same result on three runs: 461 passed, 2 failed, 2 skipped, 48 errors. The 48 errors are all The 2 failures are That one might be worth your attention. The branch already carries "Loosen test tolerances for minor numerical shifts with NumPy 2.x / OpenMDAO 3.43", and that commit puts the drift at about 3e-6. What we see is an order of magnitude larger. Our guess is that numpy moved again after you calibrated it. The main thing we wanted to ask about is the history. These changes went into main on 2026-03-21 and were reverted the same day, by 9187a53 and 14b7176. Neither commit message says why, and there are no comments here. Did you hit something concrete, or was it backed out so it could land through this PR instead? We'd rather not pin an unmerged branch if you already know something is wrong with it. If it's the latter, happy to help. We can post the full test log, run other configurations, or send a PR for the tolerance calibration. |
2 participants
Purpose
Makes openconcept compatible with numpy 2.4+
Type of change
What types of change is it?
Select the appropriate type(s) that describe this PR
Testing
Explain the steps needed to test the new code to verify that it does indeed address the issue and produce the expected behavior.
Checklist
Put an
xin the boxes that apply.