Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature multi-objective #292

Merged
merged 31 commits into from
Aug 6, 2016
Merged

Conversation

hlkline
Copy link
Member

@hlkline hlkline commented Jul 12, 2016

This pull requests adds a capability for multi-objective adjoint evaluation.
In order to use this capability, a matching number of objectives and surface markers on which to evaluate those objectives, as well as weighting values for each objective must be set. This also works with the python optimization tools, where a flag (COMBINE_OBJECTIVE) determines whether the gradients will be evaluated with a single combined adjoint evaluation or with separate, sequential evaluations.

Option Syntax:
For use with shape_optimization.py:
OPT_OBJECTIVE = DRAG1.0; LIFT2.0
COMBINE_OBJECTIVE = YES
For use with continuous_adjoint, SU2_CFD, etc, or automatically set by the shape_optimization script:
OBJECTIVE = DRAG, LIFT
OBJECTIVE_WEIGHT = 1.0, -2.0
(Note: opt_objective is still effected by automatically-applied signs - that is, whatever scale is applied to lift will be *-1 to make it a maximization problem. User can now reverse that sign if desired.)
In either case, MARKER_MONITORING =( drag_surface, lift_surface)
If only one surface is specified, it will automatically be the surface for all objectives listed. Different objectives on different surfaces can also be applied, using lists of the same length.

This change required moving some scaling terms - which means that in one of the test cases the values changed because a scaling factor is moved within the boundary conditions rather than applied after the fact (the final gradient result is the same). In addition to allowing the adjoint for a weighted sum of objectives, this may theoretically allow for applying a numerically convenient scaling factor in the future - ie, in cases where the boundary terms are either too large or too small and cause numerical cancellation errors.

Currently limited to finite difference and continuous adjoint - discrete adjoint coming soon in a separate pull request.
Also coming soon: an additional test case to add this capability to the regressions.

hlkline added 20 commits April 14, 2016 13:30
…ective2

Conflicts:
	SU2_CFD/include/solver_structure.inl
	SU2_CFD/src/iteration_structure.cpp
	SU2_CFD/src/solver_direct_mean.cpp
…s (previously used whether isothermal wall existed - which caused issues if isothermal marker was not on the head node in parallel computations)
…longer needs to be the first in the list of objectives
…p branch restart files, may update later on for more reasonable residiual values
@economon
Copy link
Member

As we spoke about yesterday, just let me know when you've finished adding things to this PR, Heather. Code looks good to me otherwise.

@hlkline
Copy link
Member Author

hlkline commented Jul 29, 2016

Thanks Tom, will do.
Looks like I have some conflicts after the recent merge of Fix Periodic, I'll get those resolved and let you know once it's finalized.

@economon
Copy link
Member

economon commented Aug 6, 2016

Aok. Looks good to me. Merging this in now before the pyWrapper PR.

@economon economon merged commit 1b6c804 into su2code:develop Aug 6, 2016
@hlkline hlkline deleted the feature_MultiObjAdj branch April 1, 2018 00:22
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants