`getValues` with `allowSens=True` does not work without specifying `names`.
Nobody has claimed this yet.
- Dominant language
- Python
- Stars
- 270
- Forks
- 123
- Avg merge
- 1d 18h
- Merged PRs (30d)
- 3
Description
Description
History.getValues() does not work when we call it with allowSens=True and default values for the other inputs.
To make it work, users have to specify appropriate callCounters and names.
The docstrings say it is up to the user to ensure that the callCounters specified contain the information requested, so this behavior is expected, but not very user-friendly.
Steps to reproduce issue
- Run one of the test problems.
- Read the history file and call
hist.getValues(allowSense=True).
Current behavior
It tries to parse obj/con/funcs from the sensitivity evaluation, even though we don't have that info. Then it fails with KeyError.
Expected behavior
It should raise a pyOptSparse Warning or Error when allowSens=True and the (default or user-specified) callCounters and names are not valid.
It'd be better if we can overwrite callCounters and names internally.
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with History.getValues and trace how allowSens uses the default or supplied callCounters and names when reading a history file. Reproduce the failure with one of the test problems and hist.getValues(allowSens=True); done means invalid sensitivity requests produce the specified pyOptSparse warning or error instead of a KeyError.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python
- Domain
- api
- Issue type
- Bug
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 30/100