Flow rates postprocessing #1092
Conversation
source/solvers/navier_stokes_base.cc
Outdated
| @@ -1424,13 +1437,13 @@ NavierStokesBase<dim, VectorType, DofsType>::postprocess_fd(bool firstIter) | |||
| simulation_parameters.post_processing.flow_rate_output_name + | |||
| ".dat"; | |||
| std::ofstream output(filename.c_str()); | |||
| flow_rate_table.set_precision("time", 12); | |||
| flow_rate_table.set_precision("time", 4); | |||
There was a problem hiding this comment.
I'm not sure this is a good idea. For the other variables we use 12 significant digits. Since this is always written to a data file, I think it's a much better idea to keep as many digits as possible. Using scientific notation is a good idea however.
There was a problem hiding this comment.
I think I misunderstood. Here is it the one you are printing on the screen or the one your are printing on the data file? For the screen on e I think 4 digit scientific is ok. For the data file one, I think it's not a good idea to print just 4 digits.
There was a problem hiding this comment.
For log outputted to the terminal you can also youse simulation_control->get_log_precision() which is meant exactly for that.
There was a problem hiding this comment.
Agreed, will keep the scientific notation but with 12 digits for the data file. For the screen display I'll keep the way it is coded now which uses the get_log_precision() method
source/solvers/navier_stokes_base.cc
Outdated
| @@ -1424,13 +1437,13 @@ NavierStokesBase<dim, VectorType, DofsType>::postprocess_fd(bool firstIter) | |||
| simulation_parameters.post_processing.flow_rate_output_name + | |||
| ".dat"; | |||
| std::ofstream output(filename.c_str()); | |||
| flow_rate_table.set_precision("time", 12); | |||
| flow_rate_table.set_precision("time", 4); | |||
| for (unsigned int boundary_id = 0; | |||
| boundary_id < simulation_parameters.boundary_conditions.size; | |||
| ++boundary_id) | |||
| flow_rate_table.set_precision("flow-rate-" + | |||
| std::to_string(boundary_id), | |||
There was a problem hiding this comment.
Use Utilities::int_to_string instead
and set the padding manually to 2, because we will never have more than 99 boundary conditions (it makes no sense)
|
@PierreLaurentinCS please also suggest two other reviewers |
PierreLaurentinCS
force-pushed
the
flow_rates_postprocessing
branch
from
22d153f to
8373fff
Compare
PierreLaurentinCS
added
Bug
|
@PierreLaurentinCS Can you rebase for the changelog? Then I will be able to merge |
PierreLaurentinCS
force-pushed
the
flow_rates_postprocessing
branch
from
4fd57ea to
ea65307
Compare
PierreLaurentinCS
added
Reviewed and ready to merge
and removed
Needs more reviewers
Description of the problem The previous flow rate post processing tool would add a line to the .dat file for each defined boundary (in the boundary condition subsection of the .prm file) for every time iteration. This is not the expected output as one would expect a single line to be added for each time step with the flow rates of every boundary. Also, the values of the flow rates were added with a 12 digits precision. Instead, a 4 digits precision in scientific notation was chosen, which seems like a reasonable precision. Description of the solution The value of time is now added outside of the loop on the boundary conditions. Comments At the moment there is no unified output format : with/without scientific notation, different numbers of digits. This could be the work of a future PR. Former-commit-id: 79f3d07
Description of the problem The previous flow rate post processing tool would add a line to the .dat file for each defined boundary (in the boundary condition subsection of the .prm file) for every time iteration. This is not the expected output as one would expect a single line to be added for each time step with the flow rates of every boundary. Also, the values of the flow rates were added with a 12 digits precision. Instead, a 4 digits precision in scientific notation was chosen, which seems like a reasonable precision. Description of the solution The value of time is now added outside of the loop on the boundary conditions. Comments At the moment there is no unified output format : with/without scientific notation, different numbers of digits. This could be the work of a future PR. Former-commit-id: 79f3d07
Description of the problem
.datfile for each defined boundary (in the boundary condition subsection of the.prmfile) for every time iteration. This is not the expected output as one would expect a single line to be added for each time step with the flow rates of every boundary.Description of the solution
Comments