- the initial version of MPI in boundary_correct_fluxes() works well,
but it needs some rewriting, since the amount of data send between
processors is definitely to large;
- implement subroutine flux_rk2() which calculates fluxes at time t and
t + dt and averages them; then the calculated flux is passed to
variable update;
- implement subroutine advance_solution() which advances an array of
conserved variables using fluxes provided as an argument;
- use advance_solution() in update_solution();
- subroutine boundary_correct_fluxes() sweeps over all leafs and if it
finds that a neighbor is at higher level, performs a correction of
the numerical flux of current block in this direction; this
subroutine does not support MPI yet!;
- subroutine correct_flux() performs the atual correction of the
numerical flux; only part belonging to domain is updated, since ghost
zones are updated anyway in the next step during the variable update;
- call boundary_correct_flux() from evolve();
- after calculating an integrals of fluxes with a given order we
performed one step updated of the conserved variables stored in data
blocks using corresponding numerical flux stored in the same data
block; the subroutine which performs update is called
update_solution();
- if the flag CONSERVATIVE is enable, we need to return the numerical
fluxes instead of their derivatives; the directional derivatives are
calculated after sunchronization of the flux;
- the purpose of a new allocatable array in the block structure is to
store the numerical fluxes, which need to be synchronized, and then
used to update conserved variables in a conservative way;
- CONSERVATIVE flag determines if the scheme must be fully
conservative; this works only when adaptive mesh is used; in such a
case instead of update variables at each block, we first calculate
high order integration of fluxes, then we synchronize them between
blocks at different levels, and finally we perform one-step update
for each block using updated fluxes; this might be also a first step
to implement Galerkin methods;
- the program now handles properly some of the termination signals,
which means that if the program receives a signal to terminate its
execution, it will finish the current loop, write restart files,
end then exit properly;
- a new file 'mesh.log' is created with the following colums: step,
time, the number of leafs, the number of meta blocks, the coverage
efficiency, which is the number of leafs divided by the number of top
level blocks covering the whole domain, the AMR efficiency which
shows the advantage of using adaptive mesh (with boundaries taken
into account), block distribution over levels and processors;
- the AMR efficiency is the number of leafs multiplied by the number of
cells in one block (with boundaries included) and divided by the
effective resolution with boundaries included; if this parameter is
smaller than 1.0 we should expect faster calculations due to the
adaptive mesh, if the parameter is larger than 1.0, we only slow down
the calculations by using the adaptive mesh;
- it seems that when we compare side derivatives for interpolated
states to zero, there are some problems with symmetry; using a small
value 'eps' instead of 0.0 solves this problem;
- change order of calculating terms; first perform the main update
of the conserved variables, then add forcing and source terms; in
this way we do not change time step which determines the stability of
scheme before the conserved variables enter Riemann solver; this is
especially important in highly supersonic simulations, when in the
presence of very low density, even small change of velocity can make
the scheme numerically unstable;
- the number of seeds and seed values must be stored in the restart
file in order to restart a job properly and guarantee unchanged
generation of random numbers after restart;
