[FLASH-USERS] MHD (8wave & USM): Refinement region boundaries - spurious waves when B field is oblique to jumps in refinement.

[Jonathan Thurgood]

Hi Klaus,

Thanks for the info on the call tree - I'll let you know how I get on!

Jonathan

-----Original Message-----
From: Klaus Weide [mailto:klaus at flash.uchicago.edu] 
Sent: 18 May 2016 19:37
To: Jonathan Thurgood
Cc: Sean Couch; John ZuHone; flash-users at flash.uchicago.edu
Subject: RE: [FLASH-USERS] MHD (8wave & USM): Refinement region boundaries - spurious waves when B field is oblique to jumps in refinement.

On Wed, 18 May 2016, Jonathan Thurgood wrote:

> The artefact is common to 8 wave and USM, so I think it is sensible to 
> start with going through the interpolation at boundaries used in the 8 
> wave setup since I won't have to worry about the staggering on face 
> variables.

> Could you please tell me which files / routines would be called to 
> handle the coarse-to-fine / fine-to-coarse interpolation at refinement 
> boundaries in the case of a simple 8wave setup so I can follow them 
> through? The code is so substantial that I'm finding it tricky to 
> navigate the source code at this stage.
> 

Jonathan,

You asked for it. :)

Here are parts of the call tree, relevant to grid interpolation for cell-centered variables. Directories (where given) are relative to source/Grid/GridMain/paramesh/paramesh4/Paramesh4dev/PM4_package/;
I give file names of routines (without suffix), subroutine names are the same, modulo a possible mpi_ prefix.

(Btw. you usually find the face-variable routines and variables that correspond to cell-centered ones by replacing _cc with _fc.)

A) This is for -gridinterpolation=native :

  Grid_fillGuardCells
         |
         V
  source/mpi_amr_guardcell
         |
         V
  mpi_source/mpi_amr_1blk_guardcell
         |
         +--------------------------------------------+
         |                                            |
         V                                            V
  mpi_source/mpi_amr_1blk_guardcell_c_to_f     source/amr_1blk_guardcell_srl
         |
         V
  source/amr_1blk_cc_prol_gen_unk_fun
         |
         +--------------------------------------------+---------------------+
         |                                            |                     |
         V                                            V                     V
  source/amr_1blk_cc_prol_inject source/amr_1blk_cc_prol_linear source/amr_1blk_cc_prol_genorder


For case A, note in particular how amr_1blk_cc_prol_gen_unk_fun dispatches based on interp_mask_unk(ivar); this could be used to apply different interpolation methoss on a variable-by-variable basis.
FLASH does not make use of this. The initialization seems to happen here by default:
  amr_initialize.F90:      interp_mask_unk(:)   = 1

This could be changed, perhaps in
source/Grid/GridMain/paramesh/paramesh4/Paramesh_init, see comments there.

The implementation routines (on the last line) depend crucially on coefficients that are initalized once at program start; see headers/prolong_arrays, source/amr_prolong_cc_fun_init, maybe others.


B) This is for -gridinterpolation=monotonic ;
   directories starting with "interpolation" are under
   source/Grid/GridMain/paramesh/ .

   
     (as above)
         |
         V
  mpi_source/mpi_amr_1blk_guardcell_c_to_f
         |
         V
  interpolation/Paramesh4/prolong/amr_1blk_cc_prol_gen_unk_fun
         |
         V
  interpolation/Paramesh4/prolong/amr_prolong_gen_unk1_fun
         |
         +---------------------+---------------------+
         |                     |                     |
         V                     V                     V
       umap3                 umap2                 umap1
  (these, and further called subroutines, in interpolation/prolong/umap.F)



For case B, note how amr_prolong_gen_unk1_fun passes gr_intpol (the value from runtime parameter interpol_order) on to the called implementation routines.


HTH,

Klaus