[FLASH-USERS] WARNING after gc filling: min. unk(DENS_VAR)=0

[Gary F Forjan]

Hi Klaus

Thanks for the quick response.  I tried running this on 1 processor with adaptive mesh refinement and I do get the same error. 

I also get the same error condition when I change the boundary conditions to 
xl = reflect
xr = reflect

When I change the boundary condition to 
xl = user 
xr = user, 

I get the error message 'Simulation WindTunnel does not support USER_DEFINED boundary on Upper Face'.  This is implemented in the WindTunnel Grid_applyBCEdge.F90 which I adapted for use in my experiment and never changed.  Perhaps this is a clue to the problem though I don't know why it wouldn't also affect running on a uniform grid.

I have attached the my simulation setup files Grid_applyBCEdge and Simulation_initBlock.  I modified some gravity files to simulate the gravity along a loop but I don't think this would have an effect on the problem.  Please note that the Grid_applyBCEdge routine is basically the same as in the WindTunnel except that I substituted my variables.  Also attached are the logfile from a run using 1 processor and the original boundary conditions (xl = user and xr = reflect):

flashout - file with standard output
benchmark.log - logfile for the run
  
Hope this helps. 

Gary

Dr. Gary Forjan
Department of Computational and Data Sciences
George Mason University, Fairfax, Va
gforjan at gmu.edu

----- Original Message -----
From: Klaus Weide <klaus at flash.uchicago.edu>
Date: Tuesday, May 11, 2010 5:46 pm
Subject: Re: [FLASH-USERS] WARNING after gc filling: min. unk(DENS_VAR)=0

> On Tue, 11 May 2010, Gary F Forjan wrote:
> 
> > This is an old problem I never managed to solve but had to leave to
> > work on something else.  I'm back to it now and would appreciate
> > some help.  I am simulating a solar coronal loop structure with
> > heating, radiative cooling, and semi-circular gravity in FLASH 3.2.
> > The simulation is one-dimensional with a user-defined xl boundary
> > condition and a reflecting xr boundary condition.  I have set up the
> > user-defined boundary condition by modifying the
> > Grid_applyBCEdge.F90 routine very much like the WindTunnel example.
> > I know that when Grid_applyBCEdge is called, it is seeing the
> > correct negative integer value (-38) for a user-defined boundary
> > condition from the constants.h file.  The simulation runs when I set
> > lrefine_min = lrefine_max for a uniform grid and appears to give a
> > correct physical solution.  But when I try to run with adaptive mesh
> > refinement, say lrefine_min = 1 and lrefine_max = 6, I get the error
> > shown below that my density and internal enery are zero after the
> > call to Eos.  I believe this is occurring in the call to
> > Eos_wrapped in gr_expandDomain.F90.
> 
> Hi Gary,
> 
> Yes, it looks like the errors are occurring during the initial 
> grid 
> construction loop in gr_expandDomain.  From the WARNING lines, it 
> seemsthat the problem is introduced during guard cell filling, in 
> the form
> or zero velues in the guard cells.  those rows with 16 real numbers
> after the WARNINGs actually give the contents of the offending 
> block's cells, so you can see that one block seems to have zeros
> in all the right guard cells, and another block has zeros in all the
> left guard cells.  If these these two blocks are the leaf blocks
> at the two domain boundaries, then something has gone wrong with
> the boundary condition implementation.
> 
> If you sent me your Grid_applyBCEdge.F90 I could have a look at it,
> maybe I can spot some error there.  Looking at Simulation_initBlock
> might also be useful.  Are there other files that you have 
> modified? 
> 
> I note that this error happens very early during the initial grid
> construction, when there are only 6 leaf blocks in existence, fewer
> than the number of processors you are running on.  If you try to 
> run this
> on fewer processors, maybe just 1, do you get the same behavior?
> (I realize that your problem may not be able to run on 1 proc, but
> it should be able to execute the initial iterations of the 
> initializationloop without problem.)
> 
> Does the code fail in the same way if you change
> 
>   xl_boundary_type = "user"
>   xr_boundary_type = "reflect"
> 
> to a)
>   xl_boundary_type = "reflect"
>   xr_boundary_type = "reflect"
> 
> or b)
>   xl_boundary_type = "user"
>   xr_boundary_type = "user"
> 
> ?
> 
> Finally, full logfile output and standard output would be useful
> for analyzing the problem.
> 
> Klaus
> 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: Grid_applyBCEdge.F90
URL: <http://flash.rochester.edu/pipermail/flash-users/attachments/20100512/2de6bf44/attachment.ksh>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: Simulation_initBlock.F90
URL: <http://flash.rochester.edu/pipermail/flash-users/attachments/20100512/2de6bf44/attachment-0001.ksh>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: benchmark.log
Type: application/octet-stream
Size: 21362 bytes
Desc: not available
URL: <http://flash.rochester.edu/pipermail/flash-users/attachments/20100512/2de6bf44/attachment.obj>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: flashout
URL: <http://flash.rochester.edu/pipermail/flash-users/attachments/20100512/2de6bf44/attachment-0002.ksh>