search

OpenMDAO / dymos

Open Source Optimization of Dynamic Multidisciplinary Systems
Apache License 2.0
210 stars 67 forks source link

Unexpected behavior when OPENMDAO_REPORTS=0 #1092

Closed swryan closed 3 months ago

swryan commented 3 months ago

Description

I noticed test_ex_two_burn_orbit_raise_bokeh_plots.py was failing when I had the env var OPENMDAO_REPORTS=0.

Interestingly the similar matplotlib version of the test (nor any other test in the full test suite) is sensitive to this variable (see below).

This test should probably have a with set_env_vars_context(OPENMDAO_REPORTS=1):, but on the surface it's curious that the other test(s) don't have the same behavior...

Example

[16:06:39](dymos) swryan@Chimaera:~/dev/dymos/dymos/examples/finite_burn_orbit_raise/test$ testflo -v test_ex_two_burn_orbit_raise_bokeh_plots.py
test_ex_two_burn_orbit_raise_bokeh_plots.py:TestExampleTwoBurnOrbitRaise.test_mpl_plots ... OK (00:00:14.94, 404 MB)
test_ex_two_burn_orbit_raise_bokeh_plots.py:TestExampleTwoBurnOrbitRaise.test_bokeh_plots ... OK (00:00:15.84, 395 MB)

OK

Passed:  2
Failed:  0
Skipped: 0

Ran 2 tests using 12 processes
Wall clock time:   00:00:24.64

[16:07:34](dymos) swryan@Chimaera:~/dev/dymos/dymos/examples/finite_burn_orbit_raise/test$ export OPENMDAO_REPORTS=0

[16:07:47](dymos) swryan@Chimaera:~/dev/dymos/dymos/examples/finite_burn_orbit_raise/test$ testflo -v test_ex_two_burn_orbit_raise_bokeh_plots.py
test_ex_two_burn_orbit_raise_bokeh_plots.py:TestExampleTwoBurnOrbitRaise.test_bokeh_plots  ... FAIL (00:00:13.49, 397 MB)
/home/swryan/miniconda3/envs/dymos/lib/python3.12/site-packages/openmdao/core/group.py:1101: DerivativesWarning:Constraints or objectives [ode_eval.control_interp.control_rates:u1_rate2] cannot be impacted by the design variables of the problem because no partials were defined for them in their parent component(s).
/home/swryan/miniconda3/envs/dymos/lib/python3.12/site-packages/openmdao/core/group.py:1101: DerivativesWarning:Constraints or objectives [ode_eval.control_interp.control_rates:u1_rate2] cannot be impacted by the design variables of the problem because no partials were defined for them in their parent component(s).

Traceback (most recent call last):
  File "/home/swryan/dev/dymos/dymos/examples/finite_burn_orbit_raise/test/test_ex_two_burn_orbit_raise_bokeh_plots.py", line 51, in test_bokeh_plots
    self.assertTrue(html_file.exists(), msg=f'{html_file} does not exist!')
AssertionError: False is not true : reports/testflo/traj_results_report.html does not exist!

test_ex_two_burn_orbit_raise_bokeh_plots.py:TestExampleTwoBurnOrbitRaise.test_mpl_plots ... OK (00:00:13.91, 401 MB)

The following tests failed:
test_ex_two_burn_orbit_raise_bokeh_plots.py:TestExampleTwoBurnOrbitRaise.test_bokeh_plots

Passed:  1
Failed:  1
Skipped: 0

Ran 2 tests using 12 processes
Wall clock time:   00:00:21.15

(dymos) swryan@Chimaera:~/dev/dymos/dymos/examples/finite_burn_orbit_raise/test$

Dymos Version

1.11.0

Relevant environment information

No response

robfalck commented 3 months ago

I think the mpl plots were made before reports existed, and the bokeh report code is sort of weird in that it's not really triggered as a normal report. I'll put a quick fix in for this.

It's tricky to make the trajectory results report a true report because it involves plotting the simulated results for verification. And those are generated by running a whole other problem.