Dear Klaus:

I am sorry I did not notice your email on 2009/5/27 until now. Oh,new version of gmail is rather complicated.  
As you mentioned
This appears to be a very reasonable approach for initializing face var
values on block boundaries.  But I think in order to do this correctly in
amr_1blk_fc_prol_user, the IF you mention above would have to be quite
complex, somethink like:
  IF( [We are being call from amr_prolong not amr_guardcell]
    .AND. [Neighbor has nodetype 1]
    .AND. [Neighbor is NOT a newchild]
    ...) THEN
     [Use neighbor's face var values at the surface instead of
      values from interpolation]
(Btw, you may not want the second condition.)
Implementation of the third condition  may not be easily possible, since
the newchild flag for a neighbor may not be available locally if the
neighbor is remote.

  According to my current understandings about paramesh's communication mechanism, tree info is also stored in send buffer and  communicated to  the local. But I am not sure if  it is right  to use newchild(remote_blk) directly,  since I  did use the third condition [Neighbor is NOT a newchild] in my codes. If  newchild flag is not available locally, I'm afraid  my codes was wrong. 

  However, anyway,so far, it has not  reported  any error or warnings.Besides, the result obtained seems to be acceptable ,although it is far from being  perfect.
So, could you and Kevin or any other developer please describe what happens  in mpi_amr_comm_setup.F90? 

Any contribution would be highly appreciated.  If anywhere in my letter is wrong,please correct it. 

Best wishes.