[FLASH-USERS] Error in timestep calculation for 8 Wave MHD solver

[Sean Couch]

Hi Michael,

I don’t think the 8wave solver is compatible with spherical coordinates.  We have added limited support for curvilinear geometry in the unsplit staggered mesh MHD solver, but I don’t think even that works in 3D spherical.  

Sean


-----------------------------------------------------------
Sean M. Couch
Theoretical Astrophysics Including Relativity
California Institute of Technology
Mail Code 350-17
Pasadena, CA  91125
(626) 395-4282
www.tapir.caltech.edu/~smc <http://www.tapir.caltech.edu/~smc>
> On Mar 14, 2015, at 2:56 PM, Michael Schlenker <mjs538 at drexel.edu> wrote:
> 
>  Hi everyone,
> 
> I'm working on a simulation for the solar wind using 3D spherical coordinates.  When I included effects from MHD, however, I found that my dt hydro value became extremely small, on the order of 1e-9. This is far too small a time step to be correct (or practical) for a system that spans several solar radii.
> 
> I've spent time combing through my simulation for possible errors but nothing seemed to stand out. So, I followed the FLASH code to where the timestep is calculated in physics/Hydro/HydroMain/split/MHD_8Wave. I looked at line 474 of hy_8wv_sweep.F90. At that line, the timestep is being evaluated for the theta direction of the cells. But in the call to setTimestep, I see that dt is being evaluated by (amongst several other factors):
> 
> min(dy(j)/max(speed(j),speed(j+1),vj)
> 
> This seems to be the source of my problem. While the above line is fine for *Cartesian* coordinates, it does not work for spherical coordinates. The dy is the cell spacing along theta *in radians*. The conversion was never made to a distance. So this calculation is not producing something in seconds; rather, it's giving something in rad*s/cm.
> 
> To check my hunch, I ran my simulation using the standard Hydro split PPM solver, with no magnetic effects. The time step in that run was at the correct order of magnitude and, looking at how it computes the timestep, I do indeed see separate cases for curvlinear geometries that correctly convert the dy and dz of spherical geometry from angular measure to an actual distance. I don't see any mention of geometry in the 8Wave package to do this.
> 
> I tried to fix this problem myself but simply converting dy and dz in the 8Wave solver reveals another issue: the cells of my simulation lose information. It's as if 8Wave is taking my spherical coordinate values but treating them as if they were on a Cartesian grid. 
> 
> Does anyone have some recommendation on how this can be fixed?
> 
> Thanks for the help,
> Michael S

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://flash.rochester.edu/pipermail/flash-users/attachments/20150315/93bb55e6/attachment.htm>