[FLASH-USERS] Guardcells filling with PARAMESH4 data/grid structure

[Marco Mazzuoli]

    Dear 
Anshu, Dear Mark,
thank you very much. You have answered exactly what I need.Actually, I supposed that information on the guard cell would have been lost when the pointer had beed relesed.Is it possible in such a way to make the changes on the guard cells effective in the interior cells of neighbouring blocks?
Thank you again.
Greetings,    Marco

Ing. Marco Mazzuoli
Dipartimento di Ingegneria
delle Costruzioni, dell'Ambiente e
del Territorio (DICAT)
via Montallegro 1
16145 GENOVA-ITALY
tel.  +39 010 353 2497
cell. +39 338 7142904
e-mail marco.mazzuoli at unige.it
       marco.mazzuoli84 at gmail.com






From: mlricha4 at asu.edu
Date: Tue, 21 Feb 2012 09:21:59 -0700
Subject: Re: [FLASH-USERS] Guardcells filling with PARAMESH4 data/grid structure
To: dubey at flash.uchicago.edu
CC: marco.mazzuoli at unige.it; flash-users at flash.uchicago.edu



Just an add on to Anshu's email. The fillGuardCells call only fills the guard cells of active blocks (children and their parents). It's extremely unlikely you would need to fill beyond the active region, but in case you do, I have a routine that does this. 


   -Mark
Sent from my iPhone
On 2012-02-21, at 5:09 AM, Anshu Dubey <dubey at flash.uchicago.edu> wrote:


Dear Marco,

Grid_fillGuardCells is a global operation which replaces the current values in the guard cells of
all blocks with values from interior cells of the neighboring blocks. When you get a pointer to a block 


you get access to all the variables in the block. In general, you should only be changing the 
interior cells in the block because the next call to guard cell fill will destroy the values you 
might have put in the guard cells. Any time you get a block through Grid_getBlkPtr, you


should explicitly release it using Grid_releaseBlkPtr when you are done with it. 

The one exception to the above scenario is in the use of active particles where mass of the
particles is mapped to their surrounding cells and some of those cells may be guard cells. 


A part of the routine Grid_mapParticlesToMesh makes sure that the values in guard cells
are communicated back to appropriate blocks, in what we call the reverse guard cell fill.

I hope that answers your basic question, please send me more details if you have a specific


problem/approach in mind.

Anshu

On Fri, Feb 17, 2012 at 11:12 AM, Marco Mazzuoli <marco.mazzuoli at unige.it> wrote:







    Dear all,

I am working on the FLASH code implementing the PARAMESH4 data/grid structure.
Could you clarify me some questions concerning the GuardCells (GC) filling?

I explain the problem:


In order to work on such a local block (with for example 4 GC) I get the pointer to that block with the subroutine "Grid_getBlkPtr".
Then I could assign a new value to some GC variables.
Finally I call the subroutine "Grid_fillGuardCells".



My questions are:
I)  What happens to GC values I had changed?
II) Can I only read GC variables (like boundary conditions) or also write permanently a new value?

In other words:
i)   Which variable I'm really pointing with "Grid_getBlkPtr"? 


ii)  What I change indeed when I work on the GC of that pointer?
iii) Do GC communicate straightforwardly to the adjacent block?

Thank you to everybody.

Sincerely,
    Marco Mazzuoli




Ing. Marco Mazzuoli
Dipartimento di Ingegneria


delle Costruzioni, dell'Ambiente e
del Territorio (DICAT)


via Montallegro 1
16145 GENOVA-ITALY


tel.  +39 010 353 2497


cell. +39 338 7142904
e-mail marco.mazzuoli at unige.it


       marco.mazzuoli84 at gmail.com






 		 	   		   		 	   		  


-- 
**********************************************************************************************************
Anshu Dubey
Associate Director and CS/Applications Group Leader          5747 S. Ellis Avenue 3rd Flr.


Flash Center for Computational Science                                773 834 2999 (office)
Fellow, Computation Institute                                                  312 420 0033 (mobile)
University of Chicago and Argonne National Laboratory        773 834 3230 (fax)


**********************************************************************************************************


 		 	   		   		 	   		   		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://flash.rochester.edu/pipermail/flash-users/attachments/20120221/f5449212/attachment-0001.htm>