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

[Klaus Weide]

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 seems
that 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 initialization
loop 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