Dear Kevin and Klaus:

Thanks for your suggestions and explanations.

According to my understanding of the codes,force_consistency flag in paramesh indicates  temporary storage of solution( storing in gt_facevarXX,etc) of face variables before prolongation.Although, it's aim is to eliminate round-off errors ,which is exactly the same with my objective ,it is still intended to help guardcell filings,because temporary copy gt_facevarXX are ultimately used in amr_1blk_fc_cp_remote.F90.
But in my codes, get_remote_block serves as a complement of  divergence-free reconstruction after amr_refine_derefine.  

My motivation of using get_remote_block is based on two papers-1) Divergence-Free Adaptive Mesh Refinement for Magnetohydrodynamics and, 2) “A novel approach of divergence-free reconstruction for adaptive mesh refinement", where in the section  2.1 a few lines read: "Note that if the coarse cell shares edges with cells already refined meshes,then the field component values on those refined meshed would be copied to the new finer mesh rather than using the interpolation". 

As I am from China mainland, Flash codes are inaccessible to me.Thus I am not quite clear about its details except several glimpses of its user-guide . But I believe divergence-free must has been addressed  effectively. 

Hope it helps.








2009/5/27 Klaus Weide <klaus@flash.uchicago.edu>
On Tue, 26 May 2009, Kevin Olson wrote:

> Dear Tingxing,
>
> In order to ensure that the face variables are the same are the same at the
> interfaces of different blocks, you should be using the 'force_consistency'
> flag.  You should not need to use the get_remote_block routine as you
> described.  It probably will not work (Klaus gave a good description of why it
> will not work).

Kevin,

Actually I am not sure it will not work, maybe it happens to be the case
that (for this specific use) all required face var values are present in
the receive-buffer after the communication for prolongation has been done?

It seems that force_consistency doesn't exactly do what's desired here:
- It replaces local_value with 0.5 * ( local_value + remote_value), always
 when guard cell filling
- Desired behavior: replace local_value with remote_value, *sometimes*
 (i.e., only when filling in new children in amr_prolong)

Also, in the past Dongwook Lee and I have observed some effects of using
force_consistency that made us a bit suspicious of this mode, including
slight differences in results depending on the number of processors.
(IIRC the differences were very small, and we never traced exactly were
they came from.)

With force_consistency turned on, guard cell filling for face variables
acts in an unusual manner.  This is the ony case I know of where execution
of amr_guardcell may change values in "interior" cells (namely, face
variables at the block boundaries) in addition to changing values in the
guard cell layers. Maybe this explains what we saw.  Normally we (and the
FLASH code) don't expect any modification of "interior" values as a side
effect of guard cell filling.

(Btw I am assuming no_permanent_guardcells is off.)

Klaus