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

Enhance UO dependency of aux kernels #14664

Closed
YaqiWang opened this issue Jan 29, 2020 · 1 comment · Fixed by #14672
Closed

Enhance UO dependency of aux kernels #14664

YaqiWang opened this issue Jan 29, 2020 · 1 comment · Fixed by #14672
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
Copy link
Contributor

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 the PRE_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 the PRE_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 into PRE_AUX. Since the dependency information is not kept currently by Warehouse, I will attempt another simpler solution: overload getUserObjectTempl in UserObject, so that UO itself can know what UOs it depends on. This information can be used in the overloaded function AuxKernel::getUserObjectTempl.

Impact

Make the dependency resolution more complete on the framework side.

@YaqiWang 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
@YaqiWang
Copy link
Contributor Author

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
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.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants