[FLASH-USERS] double rarefraction question
Robert Fisher
rfisher1 at umassd.edu
Tue Mar 15 14:13:32 EDT 2011
Hi Dean :
My recollection of this problem is that the rarefaction waves are
supersonic, and consequently the exact solution is a vacuum in the
interior. As a result, virtually any Godunov scheme, even one which is
based on an exact solver, can produce negative states when attempting
to obtain the correct solution.
Most commonly, approximate solvers like the one used in FLASH have
floors applied to the density, pressure, and internal energy to the
Riemann problem solution in the interior. My first suggestion would be
to begin looking at the floors applied in rieman.F90 (eg, hy_smlrho,
hy_smallp), as they are almost certainly triggered here. How are the
floors being set currently?
Best wishes,
Bob
On Tue, Mar 15, 2011 at 1:53 PM, Dean Townsley <Dean.M.Townsley at ua.edu> wrote:
> Hi flash users and developers,
>
> I am working with an undergraduate (cc'd here) on some Riemann solver and
> verification stuff and we got something a bit strange when we tried a
> double-rarefraction wave with flash. So I thought I would ask around about
> it.
>
> We are just doing the standard double-rarefraction case out of Toro's
> textbook. I've attached our flash.par for the Sod problem, but basically it
> is:
> sim_rhoLeft = 1.
> sim_rhoRight = 1.
> sim_pLeft = 0.4
> sim_pRight = 0.4
> sim_uLeft = -2.
> sim_uRight = 2.
>
> Broxton has implemented the solver out of Toro to make some comparison
> plots, and they look fine compared to the text solutions. But I tried it
> with flash and it did something really funky in the internal energy. I've
> attached a plot that compares the energy I get out of flash (blue) to that
> from the explicit riemann solver (red) at a time of 0.15.
>
> This is effectively with flash 3.2, but I tried it with 3.3 and I get a
> slightly weirder structure of similar magnitude. I attached a plot of that
> too. I was quite surprised to see this change from one version to another.
>
> So my question to anyone who might know: Is this a known issue with PPM?
> Perhaps I'm just unfamiliar with it. I tried turning off the steepening,
> just to try something, and it didn't seem to do anything. Am I doing
> something else dumb?
>
> Any insight would be much appreciated!
>
> (hopefully the attachments will come through, otherwise I'll send links)
>
> Thanks,
> Dean
>
> # Runtime parameters for the Sod shock-tube problem.
>
> # Parameters for initial model
>
> # Density, pressure, and velocity on either side of interface
>
> sim_rhoLeft = 1.
> sim_rhoRight = 1.
> sim_pLeft = 0.4
> sim_pRight = 0.4
> sim_uLeft = -2.
> sim_uRight = 2.
>
> # Angle and position of interface relative to x and y axes
>
> # These settings are better for testing 3-d problem, they are little
> # less symmetric.
>
> #sim_xangle = 45.
> #sim_yangle = 45.
> #sim_posn = 1.0
>
> # To get a simpler test problem which shows the 1-D Profile
> # use the following values.
> sim_xangle = 0
> sim_yangle = 90.
> sim_posn = 0.5
>
> # Gas ratio of specific heats
>
> gamma = 1.4
>
> # Computational volume parameters
>
> # Grid dimensionality and geometry
>
> geometry = cartesian
>
> # Size of computational volume
>
> xmin = 0.
> xmax = 1.
> ymin = 0.
> ymax = 1.
>
> # Boundary conditions
>
> xl_boundary_type = "outflow"
> xr_boundary_type = "outflow"
>
> yl_boundary_type = "outflow"
> yr_boundary_type = "outflow"
>
>
> # Simulation (grid, time, I/O) parameters
>
> cfl = 0.8
> basenm = "sod_"
> restart = .false.
>
> # checkpoint file output parameters
> checkpointFileIntervalTime = 0.01
> checkpointFileIntervalStep = 0
> checkpointFileNumber = 0
>
> # plotfile output parameters
> plotfileIntervalTime = 0.
> plotfileIntervalStep = 0
> plotfileNumber = 0
>
> nend = 1000
> tmax = .15
>
> run_comment = "Sod problem, diagonal direction"
> log_file = "sod.log"
> eintSwitch = 1.e-4
>
>
> plot_var_1 = "dens"
> plot_var_2 = "pres"
> plot_var_3 = "temp"
>
> # AMR refinement parameters
> lrefine_max = 8
> lrefine_min = 8
> refine_var_1 = "dens"
>
> # These parameters are used only for the uniform grid
>
>
> #iGridSize = 8 #defined as nxb * iprocs
> #jGridSize = 8
> #kGridSize = 1
> iProcs = 1 #number or procs in the i direction
> jProcs = 1
> kProcs = 1
>
> # When using UG, iProcs, jProcs and kProcs must be specified.
> # These are the processors along each of the dimensions
> #FIXEDBLOCKSIZE mode ::
> # When using fixed blocksize, iGridSize etc are redundant in
> # runtime parameters. These quantities are calculated as
> # iGridSize = NXB*iprocs
> # jGridSize = NYB*jprocs
> # kGridSize = NZB*kprocs
> #NONFIXEDBLOCKSIZE mode ::
> # iGridSize etc must be specified. They constitute the global
> # number of grid points in the physical domain without taking
> # the guard cell into account. The local blocksize is calculated
> # as iGridSize/iprocs etc.
>
>
> ## -------------------------------------------------------------##
> ## SWITCHES SPECIFIC TO THE UNSPLIT HYDRO SOLVER ##
> # I. INTERPOLATION SCHEME:
> order = 2 # Interpolation order (First/Second order)
> slopeLimiter = "mc" # Slope limiters (minmod, mc, vanLeer, hybrid,
> limited)
> LimitedSlopeBeta= 1. # Slope parameter for the "limited" slope by Toro
> charLimiting = .true. # Characteristic limiting vs. Primitive limiting
>
>
> # II. RIEMANN SOLVERS:
> RiemannSolver = "Roe" # LLF, HLL, HLLC, hybrid, Marquina, Roe
> shockInstabilityFix = .false. # Carbuncle instability fix for the Roe solver
>
>
> # III. STRONG SHOCK HANDELING SCHEME:
> shockDetect = .false. # Shock Detect for numerical stability
> ## -------------------------------------------------------------##
>
>
--
Dr. Robert Fisher
Assistant Professor
University of Massachusetts/Dartmouth
Department of Physics
285 Old Westport Road
North Dartmouth, Massachusetts 02747
robert.fisher at umassd.edu
http://www.novastella.org
More information about the flash-users
mailing list