<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=utf-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    Hello flash-users,<br>
    <br>
    sorry to ask that stupidly, but it seems more people are having some
    sort of issues with 3D spherical coordinates even now; in my case
    this is mostly down to lack of experience with Flash, but even for
    more acquainted users this doesn't seem altogether straightforward.<br>
    <br>
    The question is simply: is there any example available of how to get
    the code running correctly in 3D spherical, for some HD or ideally
    MHD application? Just to have a reference on what to watch out for,
    what not to do (like the problem below: periodical boundary
    conditions for the theta coordinate), and a rough orientation as to
    how the results should be used.<br>
    <br>
    Any pointers on how to start out would be appreciated. In the long
    run of course, most helpful might be to have a documented test case
    shipped with the code... e.g. the SodSpherical problem actually
    allows 3d in its setup parameters, but even then it doesn't actually
    use the phi coordinate but specifies a "null set" range of zmin=0.0;
    zmax=1.0 in degrees.<br>
    <br>
    Thanks,<br>
    Justus<br>
    <br>
    <pre>On Jul 6, 2014, at 12:06 PM, Luke Zoltan Kelley <<a href="http://flash.uchicago.edu/mailman/listinfo/flash-users">lkelley at cfa.harvard.edu</a>> wrote:

><i> Hello flash-users!
</i>><i> 
</i>><i> I'm new to FLASH and trying to convert a simulation from cartesian to (3D) spherical, but I'm running into some errors.  If anyone has had recent success using 3D spherical, I would be very appreciative of any tips they had, or issues they overcame.  In particular, I'm getting a warning from source/Grid/GridMain/paramesh/paramesh4/gr_sanitizeDataAfterInterp.F90 that my guard-cells aren't being set correctly:
</i>><i> 
</i>><i> 
</i>><i> WARNING after gc filling: min. unk(DENS_VAR)=0.000000000000000000000          PE=0     block=1                         type=2                               
</i>><i> 16   0.0      0.0      0.0      0.0      0.0      0.0      0.0      0.0      0.0      0.0      0.0      0.0      0.0   0.0      0.0      0.0    
</i>><i> 15   0.0      0.0      0.0      0.0      0.0      0.0      0.0      0.0      0.0      0.0      0.0      0.0      0.0   0.0      0.0      0.0    
</i>><i> 14   0.0      0.0      0.0      0.0      0.0      0.0      0.0      0.0      0.0      0.0      0.0      0.0      0.0   0.0      0.0      0.0    
</i>><i> 13   0.0      0.0      0.0      0.0      0.0      0.0      0.0      0.0      0.0      0.0      0.0      0.0      0.0   0.0      0.0      0.0    
</i>><i> 12  0.10E-18 0.63E-01 0.63E-01 0.62E-01 0.62E-01 0.63E-01 0.63E-01 0.10E-18 0.10E-18 0.10E-18 0.10E-18 0.10E-18 0.10E-18 0.10E-18 0.10E-18 0.10E-18
</i>><i> 11  0.10E-18 0.63E-01 0.62E-01 0.63E-01 0.63E-01 0.62E-01 0.63E-01 0.10E-18 0.10E-18 0.10E-18 0.10E-18 0.10E-18 0.10E-18 0.10E-18 0.10E-18 0.10E-18
</i>><i> 10  0.10E-18 0.62E-01 0.62E-01 0.63E-01 0.63E-01 0.62E-01 0.62E-01 0.10E-18 0.10E-18 0.10E-18 0.10E-18 0.10E-18 0.10E-18 0.10E-18 0.10E-18 0.10E-18
</i>><i> 9  0.10E-18 0.63E-01 0.63E-01 0.62E-01 0.62E-01 0.63E-01 0.63E-01 0.10E-18 0.10E-18 0.10E-18 0.10E-18 0.10E-18 0.10E-18 0.10E-18 0.10E-18 0.10E-18
</i>><i> 8  0.10E-18 0.62E-01 0.63E-01 0.63E-01 0.63E-01 0.63E-01 0.62E-01 0.10E-18 0.10E-18 0.10E-18 0.10E-18 0.10E-18 0.10E-18 0.10E-18 0.10E-18 0.10E-18
</i>><i> 7  0.10E-18 0.63E-01 0.62E-01 0.62E-01 0.62E-01 0.62E-01 0.63E-01 0.10E-18 0.10E-18 0.10E-18 0.10E-18 0.10E-18 0.10E-18 0.10E-18 0.10E-18 0.10E-18
</i>><i> 6  0.10E-18 0.62E-01 0.63E-01 0.62E-01 0.62E-01 0.63E-01 0.62E-01 0.10E-18 0.10E-18 0.10E-18 0.10E-18 0.10E-18 0.10E-18 0.10E-18 0.10E-18 0.10E-18
</i>><i> 5  0.10E-18 0.62E-01 0.63E-01 0.63E-01 0.63E-01 0.63E-01 0.62E-01 0.10E-18 0.10E-18 0.10E-18 0.10E-18 0.10E-18 0.10E-18 0.10E-18 0.10E-18 0.10E-18
</i>><i> 4   0.0      0.0      0.0      0.0      0.0      0.0      0.0      0.0      0.0      0.0      0.0      0.0      0.0   0.0      0.0      0.0    
</i>><i> 3   0.0      0.0      0.0      0.0      0.0      0.0      0.0      0.0      0.0      0.0      0.0      0.0      0.0   0.0      0.0      0.0    
</i>><i> 2   0.0      0.0      0.0      0.0      0.0      0.0      0.0      0.0      0.0      0.0      0.0      0.0      0.0   0.0      0.0      0.0    
</i>><i> 1   0.0      0.0      0.0      0.0      0.0      0.0      0.0      0.0      0.0      0.0      0.0      0.0      0.0   0.0      0.0      0.0    
</i>><i> 
</i>><i> 
</i>><i> These warnings are given for DENS_VAR, ENER_VAR, EINT_VAR and all blocks.
</i>><i> (presumably) for this reason I'm getting arithmetic exceptions when source/physics/Eos/EosMain/Gamma/eos_idealGamma.F90 tries to divide by the (zero) densities, the backtrace I get is:
</i>><i> 
</i>><i> 
</i>><i> Program received signal EXC_ARITHMETIC, Arithmetic exception.
</i>><i> 0x000000010024cf6e in eos_idealgamma_ (mode=103, veclen=8, eosdata=(), vecbegin=Cannot access memory at address 0x0
</i>><i> ) at eos_idealGamma.F90:341
</i>><i> 341                                        eosData(dens+ilo:dens+ihi)
</i>><i> (gdb) bt
</i>><i> #0  0x000000010024cf6e in eos_idealgamma_ (mode=103, veclen=8, eosdata=(), vecbegin=Cannot access memory at address 0x0
</i>><i> ) at eos_idealGamma.F90:341
</i>><i> #1  0x000000010001149b in eos_ (mode=103, veclen=8, eosdata=(), massfrac=(), mask=(.FALSE., .FALSE., .FALSE., .FALSE., .FALSE., .FALSE., .FALSE., .FALSE., .FALSE., .FALSE., .FALSE., .FALSE., .FALSE.), vecbegin=Cannot access memory at address 0x0
</i>><i> ) at Eos.F90:265
</i>><i> #2  0x000000010001edea in eos_wrapped_ (mode=103, range=(( 5, 12) ( 1, 4) ( 1, 1) ), blockid=1, griddatastruct=Cannot access memory at address 0x0
</i>><i> ) at Eos_wrapped.F90:220
</i>><i> #3  0x0000000100019b15 in complexskipping.1886 () at Eos_guardCells.F90:43
</i>><i> #4  0x000000010001afd8 in eos_guardcells_ (corners=.TRUE., layers=(4, 4, 4), skipsrl=.TRUE.) at Eos_guardCells.F90:120
</i>><i> #5  0x00000001000322d7 in grid_fillguardcells_ (griddatastruct=380, idir=-1, minlayers=Cannot access memory at address 0x0
</i>><i> ) at Grid_fillGuardCells.F90:482
</i>><i> #6  0x000000010006340e in grid_markrefinederefine_ () at Grid_markRefineDerefine.F90:98
</i>><i> #7  0x000000010029eec2 in gr_expanddomain_ (particlesinitialized=.FALSE.) at gr_expandDomain.F90:212
</i>><i> #8  0x0000000100061385 in grid_initdomain_ (restart=.FALSE., particlesinitialized=.FALSE.) at Grid_initDomain.F90:98
</i>><i> #9  0x000000010000d405 in driver_initflash_ () at Driver_initFlash.F90:156
</i>><i> #10 0x000000010001f19c in flash () at Flash.F90:49
</i>><i> #11 0x000000010001f20e in main (argc=1, argv=0x7fff5fbff870 '/Users/lzkelley/Applications/flash/flash4.2.2/object_starwind/flash4\000') at Flash.F90:43
</i>><i> 
</i>><i> 
</i>><i> In my Simulation_initBlock.F90, I am looping over the guard-cells and setting all densities to non-zero values --- if I print out the densities during the initialization loop I get the appropriate densities from i,j,k = {1,1,1} up to {16,16,16} --- so it seems like the guard-cells are being overwritten to zero...
</i>><i> This does not occur in 3D cartesian, and also does *not* occur when I run SodSpherical (which seems to work properly, strangely enough).
</i>><i> 
</i>><i> I believe I've also found a bug in source/physics/Hydro/HydroMain/split/PPM/PPMKernel/avisco.F90:416, when sweeping along "y" (theta) in 3D spherical the denominator [ 'sin(xl(i))' ] is allowed to be zero and causes arithmetic exceptions.
</i>><i> 
</i>><i> Any help on this particular problem, or on getting spherical running in general would be greatly appreciated!
</i>><i> Thanks,
</i>><i> Luke</i></pre>
    <br>
  </body>
</html>