Re: [Paramesh-users] Customized facevar prolongation (was Re: remarks...)

[tingxing d. <tin...@gm...>]

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 <kl...@fl...>

> 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
>