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
Enhance UO dependency of aux kernels #14664
Labels
C: Framework
P: normal
A defect affecting operation with a low possibility of significantly affects.
T: task
An enhancement to the software.
Comments
YaqiWang
added
P: normal
A defect affecting operation with a low possibility of significantly affects.
T: task
An enhancement to the software.
labels
Jan 29, 2020
The late binding of postprocessors makes things complicated. But I guess it is still doable. |
YaqiWang
added a commit
to YaqiWang/moose
that referenced
this issue
Jan 30, 2020
…own to the base class (note: this enabled vector postprocessor interface for few derived user object classes missing before) idaholab#14664
YaqiWang
added a commit
to YaqiWang/moose
that referenced
this issue
Jan 30, 2020
YaqiWang
added a commit
to YaqiWang/moose
that referenced
this issue
Jan 30, 2020
YaqiWang
added a commit
to YaqiWang/moose
that referenced
this issue
Jan 30, 2020
lindsayad
added a commit
to lindsayad/moose
that referenced
this issue
Jul 10, 2020
In debug mode, check and see whether the function evaluation used for the perturbation base for approximating the Jacobian action actually matches the function evaluation corresponding to the nonlinear residual. Additionally, add `-snes_converged_reason` and `-ksp_converged_reason` to every simulation Closes idaholab#14664
lindsayad
added a commit
to lindsayad/moose
that referenced
this issue
Jul 11, 2020
lindsayad
added a commit
to lindsayad/moose
that referenced
this issue
Jul 13, 2020
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
C: Framework
P: normal
A defect affecting operation with a low possibility of significantly affects.
T: task
An enhancement to the software.
Reason
When a user object (UO) name is in the parameter list of an aux kernel, the aux kernel will push the UO into a dependency list (with a overloaded function
getUserObjectTempl
) and later on all the UOs in the list will be put into thePRE_AUX
for evaluation. However this resolution mechanism is not ideal because the directly dependent UO may depend on other UOs, which will not be pushed into the list and thus later on will not be put into thePRE_AUX
. Users can of cause add a dummy parameter for the aux kernel which accepts all the indirectly dependent UOs. This is however pretty counter-intuitive and users can often forget and consequently see some strange behavior in the calculation.Design
After talk with @permcody , we believe the solution is in
Warehouse
, which has the dependency information that can be used when the code put UOs intoPRE_AUX
. Since the dependency information is not kept currently byWarehouse
, I will attempt another simpler solution: overloadgetUserObjectTempl
inUserObject
, so that UO itself can know what UOs it depends on. This information can be used in the overloaded functionAuxKernel::getUserObjectTempl
.Impact
Make the dependency resolution more complete on the framework side.
The text was updated successfully, but these errors were encountered: