Skip to content

Fix axi auxvargrad - #1192

Merged
FlorianDm merged 5 commits into
developfrom
fix_axi_auxvargrad
Feb 9, 2021
Merged

Fix axi auxvargrad#1192
FlorianDm merged 5 commits into
developfrom
fix_axi_auxvargrad

Conversation

@FlorianDm

Copy link
Copy Markdown
Member

This is a small fix of two bugs related to the viscous axisymmetric source terms.

  1. As I had suspected in Axisymmetric problems : Viscous source terms and generalised convective source terms and jacobian  #1106 it should be AxiAuxVar_Grad_i[2][0] instead of AxiAuxVar_Grad_i[2][1]. The book by Hoffman that was used as a reference actually contained an error. I am attaching a page from another edition of the book (thanks to @dbrezgin).

image

  1. The type for the auxvar and gradient fields should be a reference auto& not just auto. i found the bug after it was pointed out to me that it was always set to zero (thanks to @dbrezgin).

@pcarruscag pcarruscag left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you Florian, can you put the same fix in the NEMO numerics? (if @jtneedels agrees)

Comment on lines -2459 to +2460
const auto solution = base_nodes->GetAuxVar();
auto gradient = base_nodes->GetAuxVarGradient();
const auto& solution = base_nodes->GetAuxVar();
auto& gradient = base_nodes->GetAuxVarGradient();

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

indeed the not so auto thing about auto...

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there no regression for axisymmetric flow? One would think something like this could break something.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think there is but it did just set them to zero and we don't divide by them or anything so nothing broke just inaccurate results and perhaps not converging when it should in some cases. No compiler error or warning so i guess with auto one needs to be careful

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we have a regression that "exercises" this part of the implementation? Perhaps just modifying an existing case?

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@FlorianDm @pcarruscag believe there was another issue within NEMO axisymmetric that @jtneedels fixed. Maybe it would be a good time to merge that in as well?

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@FlorianDm Yes I agree with these changes, thanks for catching that! @pcarruscag Yes, as @WallyMaier mentioned I do have another small fix to pull in for axisymmetric in CNEMOEulerSolver, should I go ahead ad open a separate PR to merge that in?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I will try to create a test/regression case after adding the k-omega source terms (almost done) because I think it is more useful if it is a rans case

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants