Average velocity as initial condition #1215

mivaia · 2024-07-30T18:22:24Z

The average velocity profile of an old simulation can now be used as an initial condition to a new simulation. The base mesh needs to stay the same, but auxiliary physics can now be added a posteriori without setting them as true in the initial simulation. The time stepping scheme can also be modified.

Description

The refactored restart mechanism had some problems:

The auxiliary physics needed to be set as true while the average velocity profile was calculated. The matrix for the auxiliary physic was therefore assembled and could lead to useless memory and simulation time usage.
The user could not choose to add an auxiliary physics to an already calculated average velocity profile if it was not specified in the initial simulation. This is because the restart mechanism would always search for a solution to the auxiliary physic in the checkpoint files even if it was non existent.
In my opinion, the location of the "use average velocity profile = true" in the multiphysics subsection was somewhat awkward as the average velocity profile is not really an auxiliary physic.

To solve these problems, the already implemented checkpoint mechanism is used. The simulation solving for the average velocity profile therefore needs to have checkpointing activated as well as the set calculate average velocities set to true (as before). Parameters in the initial condition section have been added as well as some conditions in the read_checkpoint() function.

Conditions like:

Do not search for a solution to the auxiliary physics if the average velocity is used as an initial condition.
Do search for a solution to the auxiliary physics if the restart is normally used.
Use the checkpoint file specified by the user in the appropriate initial condition section and not the simulation control section if the average velocity profile initial condition is used.

Testing

A test using the average velocity profile was modified.

Documentation

Documentation will be added in a subsequent PR if all the modifications are accepted.

Miscellaneous (will be removed when merged)

An initial condition using the VTU files was attempted, but it is way easier to use the already existing checkpoint mechanism. No known function to retrieve the triangulation information from the vtu have been found in deal.II. The read_vtu() function is only oriented towards reading vtu meshes generated with deal.II.

Checklist (will be removed when merged)

See this page for more information about the pull request process.

Code related list:

All in-code documentation related to this PR is up to date (Doxygen format)
Lethe documentation is up to date
The branch is rebased onto master
Code is indented with indent-all and .prm files (examples and tests) with prm-indent
If parameters are modified, the tests and the documentation of examples are up to date
Changelog (CHANGELOG.md) is up to date if the refactor affects the user experience or the codebase

Pull request related list:

No other PR is open related to this refactoring
Labels are applied
There are at least 2 reviewers (or 1 if small feature) excluding the responsible for the merge
If this PR closes an issue or is related to a project, it is linked in the "Projects" or "Development" section
If any future works is planed, an issue is opened
The PR description is cleaned and ready for merge

…t. ->added initial condition parameter file, erased multiphysics use average velocity profile, modified the read_checkpoint to take into account, set simulation time to 0 and erased precedent pvd info

…was not being solved. Changed some conditions to take this into account

…y as an initial condition has a bdf time stepping scheme

blaisb

Here's a first batch of comments. I think it would be wise to add the documentation within this PR. Good job btw

Testing/Temporary/CTestCostData.txt

Testing/Temporary/LastTest.log

applications_tests/lethe-fluid/cavity_ht_average_velocity_as_initial_condition.mpirun=1.output

applications_tests/lethe-fluid/cavity_ht_average_velocity_as_initial_condition.prm

include/core/simulation_control.h

source/solvers/heat_transfer.cc

source/solvers/heat_transfer_assemblers.cc

source/solvers/navier_stokes_base.cc

blaisb · 2024-07-31T15:33:17Z

source/solvers/navier_stokes_base.cc

+         Parameters::InitialConditionType::average_velocity_profile &&
+       this->simulation_parameters.restart_parameters.restart))
+    {
+      // std::cout << "Entering normally" << std::endl;


Suggested change

// std::cout << "Entering normally" << std::endl;

source/solvers/navier_stokes_base.cc

…estart with the initial condition. Scaling bug in average velocity

oguevremont

Very nice feature!

source/solvers/cahn_hilliard.cc

source/solvers/gls_navier_stokes.cc

source/solvers/navier_stokes_base.cc

oguevremont · 2024-08-05T15:05:39Z

So now if I understand correctly, we can run simulation that solve FD only while checkpointing, then run subsequent simulations where auxiliary physics are activated by using the proper type of initial condition?

…on for restart and initial condition

…have number of initial refinements set to 0. This generates an error message in debug mode. This has not been tested using pointwise meshes.

blaisb

One last comment, but this is very good. There's just this "setting the time" that I am not sure about. Can you explain why you need to have the simulation control start at the new time? :)

blaisb · 2024-08-08T12:43:57Z

source/core/simulation_control.cc

+  // Fix the current time as final checkpointed time
+  simulation_control_info[0] = last_checkpointed_time;
+
+  // Fix time step to be the last time_step that was used
+  simulation_control_info[1] = time_steps[0];


You really want to have the new simulation start at the time the previous one finished? why not restart it from zero? does that really pose a problem? I'm not sure what's the goal her (to me this is not intuitive, because if you set the initial condition, shouldnt the time be at zero still ? )

This is only to get end time for the average velocity calculation! The simulation time will be restarted from zero in the second simulation. This is necessary because of the way we calculate the average velocity.

The average velocity profile of an old simulation can now be used as an initial condition to a new simulation. The base mesh needs to stay the same, but auxiliary physics can now be added a posteriori without setting them as true in the initial simulation. The time stepping scheme can also be modified. Description The refactored restart mechanism had some problems: The auxiliary physics needed to be set as true while the average velocity profile was calculated. The matrix for the auxiliary physic was therefore assembled and could lead to useless memory and simulation time usage. The user could not choose to add an auxiliary physics to an already calculated average velocity profile if it was not specified in the initial simulation. This is because the restart mechanism would always search for a solution to the auxiliary physic in the checkpoint files even if it was non existent. In my opinion, the location of the "use average velocity profile = true" in the multiphysics subsection was somewhat awkward as the average velocity profile is not really an auxiliary physic. To solve these problems, the already implemented checkpoint mechanism is used. The simulation solving for the average velocity profile therefore needs to have checkpointing activated as well as the set calculate average velocities set to true (as before). Parameters in the initial condition section have been added as well as some conditions in the read_checkpoint() function. Conditions like: Do not search for a solution to the auxiliary physics if the average velocity is used as an initial condition. Do search for a solution to the auxiliary physics if the restart is normally used. Use the checkpoint file specified by the user in the appropriate initial condition section and not the simulation control section if the average velocity profile initial condition is used. Former-commit-id: d711d1f

mivaia added 7 commits July 24, 2024 11:35

Grid_out data_out modif for vtu gridin

ec43b84

average velocity profile as initial condition done, code cleaning lef…

452584e

…t. ->added initial condition parameter file, erased multiphysics use average velocity profile, modified the read_checkpoint to take into account, set simulation time to 0 and erased precedent pvd info

cleaned code and deleted the part to save the mesh and read it back

148913e

more cleaning

b75101b

testing

354483c

Modified restart test

c9fb95f

Indent

63079e3

mivaia added Ready for review Refactoring This PR is only refactoring or clean up labels Jul 30, 2024

mivaia requested review from blaisb and oguevremont July 30, 2024 18:22

mivaia added 3 commits July 30, 2024 16:15

calculate velocity profile needed to be set as true even if velocity …

a697919

…was not being solved. Changed some conditions to take this into account

Time step was not reseted if the simulation using the average velocit…

4fb8834

…y as an initial condition has a bdf time stepping scheme

Modified dcdd to run steady state sims in cluster

7ae0ec2

blaisb requested changes Jul 31, 2024

View reviewed changes

added set_solution_from_checkpoint function to clean the use of the r…

fbe5727

…estart with the initial condition. Scaling bug in average velocity

oguevremont reviewed Aug 5, 2024

View reviewed changes

source/solvers/cahn_hilliard.cc Show resolved Hide resolved

source/solvers/gls_navier_stokes.cc Outdated Show resolved Hide resolved

source/solvers/navier_stokes_base.cc Outdated Show resolved Hide resolved

mivaia added 3 commits August 6, 2024 11:45

Adressed comments and finalized the addition of a new conjoint functi…

91e5ff5

…on for restart and initial condition

Updated documentation

934f89c

Added comments for the post-processors using the average condition

da0e70e

mivaia requested a review from blaisb August 6, 2024 20:38

When using dealii meshes, the mesh in the second simulation needs to …

f205bb5

…have number of initial refinements set to 0. This generates an error message in debug mode. This has not been tested using pointwise meshes.

blaisb requested a review from oguevremont August 8, 2024 12:41

blaisb reviewed Aug 8, 2024

View reviewed changes

blaisb approved these changes Aug 9, 2024

View reviewed changes

blaisb merged commit d711d1f into master Aug 9, 2024
8 checks passed

blaisb deleted the average_velocity_as_initial_condition branch August 9, 2024 13:01

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Average velocity as initial condition #1215

Average velocity as initial condition #1215

mivaia commented Jul 30, 2024 •

edited

Loading

blaisb left a comment

blaisb Jul 31, 2024

oguevremont left a comment

oguevremont commented Aug 5, 2024

blaisb left a comment

blaisb Aug 8, 2024

mivaia Aug 8, 2024

blaisb Aug 9, 2024

Average velocity as initial condition #1215

Average velocity as initial condition #1215

Conversation

mivaia commented Jul 30, 2024 • edited Loading

Description

Testing

Documentation

Miscellaneous (will be removed when merged)

Checklist (will be removed when merged)

blaisb left a comment

Choose a reason for hiding this comment

blaisb Jul 31, 2024

Choose a reason for hiding this comment

oguevremont left a comment

Choose a reason for hiding this comment

oguevremont commented Aug 5, 2024

blaisb left a comment

Choose a reason for hiding this comment

blaisb Aug 8, 2024

Choose a reason for hiding this comment

mivaia Aug 8, 2024

Choose a reason for hiding this comment

blaisb Aug 9, 2024

Choose a reason for hiding this comment

mivaia commented Jul 30, 2024 •

edited

Loading