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

Add compressibility to heat transfer #1051

Merged
merged 3 commits into from
Mar 2, 2024

Conversation

AmishgaAlphonius
Copy link
Collaborator

@AmishgaAlphonius AmishgaAlphonius commented Feb 29, 2024

Description of the problem

  • The previously implemented weak compressibility () was not working with heat transfer physic.

Description of the solution

  • Missing pressure field was added to scratch data.

How Has This Been Tested?

  • The new feature has been tested on an impinging jet case.
  • Two application tests were added to test this feature :
    • applications_tests/lethe-fluid/heat_transfer_weakly_compressible_flow.prm (.output)
    • applications_tests/lethe-fluid/heat_transfer_vof_weakly_compressible_flow.prm (.output)

Future changes

  • Pressure field should be added to other scratch data using the density. To generalize, all fields should be checked if required in all scratch data that calculates physical properties.

Comments

  • Other small typo corrections were made.

Copy link
Collaborator

@voferreira voferreira left a comment

Choose a reason for hiding this comment

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

Very nice! The only thing I would change is the name of the dof handler. Maybe just use "fluid_dynamics_cell"?

@@ -454,8 +454,10 @@ HeatTransfer<dim>::assemble_local_system_matrix(
const DoFHandler<dim> *dof_handler_fluid =
multiphysics->get_dof_handler(PhysicsID::fluid_dynamics);

typename DoFHandler<dim>::active_cell_iterator velocity_cell(
&(*triangulation), cell->level(), cell->index(), dof_handler_fluid);
typename DoFHandler<dim>::active_cell_iterator fd_cell(&(*triangulation),
Copy link
Collaborator

Choose a reason for hiding this comment

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

Is fd meant to mean "fluid dynamics"? Maybe I would use a more meaningful name here.

Copy link
Contributor

Choose a reason for hiding this comment

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

I don't mind the fd here to be honest. All the fluid dynamics functions have fd, heat transfers have ht, etc. Right now this is a standard nomenclature in the code, so I would not change that unless we change it everywhere and that owuld be another PR in itself.

Copy link
Contributor

@blaisb blaisb left a comment

Choose a reason for hiding this comment

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

I don't think making a second reinit function is a good pattern here. It would be a better idea to reinit everything related to a single physics in a single function. Otherwise you will have multiple calls to fe_values.reinit and that's expensive.

Comment on lines 359 to 369
* components and pressure values.
*/
template <typename VectorType>
void
reinit_pressure(const typename DoFHandler<dim>::active_cell_iterator &cell,
const VectorType &current_solution)
{
this->fe_values_fd.reinit(cell);
this->fe_values_fd[pressure].get_function_values(current_solution,
pressure_values);
}
Copy link
Contributor

Choose a reason for hiding this comment

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

Wait why is this a second FE_values reinit? This is very expensive as a call. It would be better to gather pressure when we gather the fluid dynamics instead of calling reinit when we need both...

Comment on lines 512 to 513
scratch_data.reinit_pressure(fd_cell,
*multiphysics->get_block_solution(
Copy link
Contributor

Choose a reason for hiding this comment

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

It's better to move all the reinits to a single reinit which would be reinit_fluid_dynamics,. Otherwise the call to fe_values reinit will get prohibitively expensive..

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

You're right, I'll do so tomorrow!
I'll also check if it is more costly to add an if inside to get the pressure values or if the get_function_values() is not to bad. If it is not too bad (which I don't think is the case), I'll leave it without the if is that okay ?

Copy link
Contributor

Choose a reason for hiding this comment

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

Yup sounds good

Co-authored-by: Bruno Blais <blais.bruno@gmail.com>
@blaisb
Copy link
Contributor

blaisb commented Mar 1, 2024

Will merge after CI @AmishgaAlphonius

Copy link
Collaborator

@mivaia mivaia left a comment

Choose a reason for hiding this comment

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

Nice job Amish! Everything fine on my side.

@blaisb blaisb merged commit 1b47e0e into master Mar 2, 2024
8 checks passed
@blaisb blaisb deleted the add_compressibility_to_heat_transfert branch March 2, 2024 22:39
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.

None yet

4 participants