-
Notifications
You must be signed in to change notification settings - Fork 235
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
[Core] response function interface #6594
Conversation
|
||
class ResponseFunctionBase(object): | ||
"""The base class for response functions. Each response function | ||
class ResponseFunctionInterface(object): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is the new file in the core - Github shows it as moved...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just out of curiosity: Is there a reason, why you called it "Interface" rather than "Base" or just "ResponseFunction"?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
could you explain the relation btw this class and the AdjointResponseFunction?
This should help with the naming
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The AdjointResponseFunction provides some of the necessary components for an adjoint sensitivity analysis:
- gradient w.r.t to the primal variables (and their derivatives)
- partial gradient w.r.t to the design variable
However it does not calculate the total gradient of the response function w.r.t the design variables.
This can only be obtained using the whole framework of adjoint_solver, adjoint_response_function and sensitivity_builder.
Besides the adjoint approach to calculate the gradient, there are several other ways - fore some e.g. geometrical response functions, the adjoint approach does not even make sense.
This response function interface provides a unique interface for all possible ways to calculate the value and gradients of a response.
This is necessary because e.g. in optimization i do not care about the implementation details (e.g. how the adjoint sensitivity analysis uses the adjoint_response_function.h ...) but i am just interested in the value and gradient of the response.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
cool thx for the explanation
Could you please add sth like this to the docstring of the class?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am fine with the suggested modifications. Especially I appreciate the more general get gradient functions. As written I would also add something like GetConditionalGradient
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would approve it as it looks good to me. Just some minor comments. It's good to see a unified interface of the response functions in the core. Thanks for the effort. Before merging though, it would be good to have somebody from the core guys to quickly double-check the PR @philbucher .
...ns/ShapeOptimizationApplication/python_scripts/response_functions/packaging_response_base.py
Show resolved
Hide resolved
|
||
class ResponseFunctionBase(object): | ||
"""The base class for response functions. Each response function | ||
class ResponseFunctionInterface(object): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just out of curiosity: Is there a reason, why you called it "Interface" rather than "Base" or just "ResponseFunction"?
You might also remove the trailing whitespace as suggested by codacy |
I would like to review this but I need a few days, I would appreciate if you wait :) |
No worries =) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
some comments
Just to be clear, this should also be used in Fluids?
kratos_utilities.DeleteFileIfExisting("perturbed_part.post.bin") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would disable writing this in a test
It only takes time and is not used in 99% of times this test is run
and if you want to look at the output then you wouldn't delete it ;)
...ns/ShapeOptimizationApplication/python_scripts/response_functions/packaging_response_base.py
Show resolved
Hide resolved
|
||
class ResponseFunctionBase(object): | ||
"""The base class for response functions. Each response function | ||
class ResponseFunctionInterface(object): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
could you explain the relation btw this class and the AdjointResponseFunction?
This should help with the naming
kratos_utilities.DeleteFileIfExisting("structure.post.bin") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
idem
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see the point, however this would be something for a new MR, as this is just a whitespace change here and not related.
Idk why but my comments are inline with the comments of @dbaumgaertner |
It can, but i have no plans currently. The Fluid/Structural/ConvDiff use the same workflow and base classes for their adjoint sensitivity analysis - so it should be possible. One point that is worth mentioning is that in for structures there is sensitivity analysis only for steady state sensitivities, while for fluid it is only (?) available for transient cases. |
@marcnunezc This is essentially the interface i gave you some time ago to test optimization with the CompressiblePotentialFlowApplication. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@marcnunezc This is essentially the interface i gave you some time ago to test optimization with the CompressiblePotentialFlowApplication.
Yes! I have been using that as a custom script ever since, thanks for the effort!
I am OK with the general response interface, I only have a question regarding the reporting of the gradient.
applications/ShapeOptimizationApplication/python_scripts/analyzer_internal.py
Show resolved
Hide resolved
so from my side this is ready to go in if the involved ppl are ok with it thanks for the efforts! |
This happens when editing files using the github online file editor =) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok!
This adds a top level interface for any kind of response functions. This allows to use them easily on python level e.g. for Optimization.
This interface was previously used in individual applications e.g. StructMech and ShapeOpt and would also be added to ConvectionDiffusion in #6584.
Suggested here: #6584 (comment)