[FLASH-USERS] Using guard cell corners... bad?

[Dean Townsley]

Hi again Klaus,

So we have done some more testing, and it appears that we have found two 
problems, one which is fairly straightforward to fix, and the other 
which is more slippery.

First we found that the eos is being called an extra time on the 
guardcells in hydro.  For ideal EOS this is fine, but for an iterating 
EOS, like the Helmholtz EOS, this causes the data in the guardcells to 
differ (by a very small amount) from the data in the neighboring block.  
This introduces a slight irregularity in the flow at all block faces, 
which is most pronounced at the edges and corners.  This can be fixed by 
a simple addition during the initial newton update in Eos.F90 (around 
line 395 in the version included with Helmholtz in flash 3.3):

         error(k) = abs((tnew(k) - tempRow(k)) / tempRow(k))
 
         ! Store the new temperature
-        tempRow(k) = tnew(k)
+        ! but not if the guess was already good enough
+        ! this prevents values from shifting if the EOS is called more 
than once
+        ! without any changes in between (e.g. in guard cells)
+        if ( .not. (error(k)< eos_tol) ) then
+           tempRow(k) = tnew(k)
+        endif
 
      enddo

I know that the double-calling is done in case the guard cells have been 
filled from a neighbor at a different refinement level.  This is the 
right thing to do, but the above fix restores the block boundaries as 
being invisible to the numerics if the adjacent blocks are at the same 
refinement level.



So that fixes one issue.  But we have also found a similar issue 
persists at what appear to be processor boundaries.  But this behavior 
is compiler dependent.  Aaron sees problems with intel 11.1 compilers, 
but I don't see it with a gnu-based stack, both on intel dual quad-core 
machines, and Aaron does not see it on the BG/P, which is ibm compilers.

So at this point any help you can provide, Klaus, would be great.  You 
have a bit more access to compiler versions and such.  I will send you a 
URL to check out our code (which is flash 3.3 plus stuff for our 
problem) and give you the test problem we are having trouble with.

We are happy to hear from anyone who has seen something like this before.

Cheers,
Dean



Klaus Weide wrote:
> On Thu, 3 Mar 2011, Aaron Jackson wrote:
>
>   
>> Hi Kevin,
>>
>> Thanks for the help... Currently, though diagonals are set to true, as far as
>> I can tell. In the amr_runtime_parameters.dump file from my simulation,
>> diagonals is set to true. The issue isn't that the corner cells aren't being
>> filled, it just seems that they're being filled from extrapolating information
>> in the edge-adjacent neighbors rather than being copied/prolonged/restricted
>> with data from the diagonally-adjacent neighbor. So the data is there, it's
>> just not correct. [...]
>>     
>
> Aaron,
>
> I just want to confirm that, in FLASH, 'diagonals' is always left to 
> the default value of .TRUE.
>
> Filling of corner cells by 'extrapolating information in the edge-adjacent 
> neighbors' should never happen in the interior of the domain.
>
> If you can construct a simple test case that demonstrates wrong behavior,
> we will want to look into this as a bug.
>
> Klaus
>
>