[Mesa-users] sound speed and mesa eos

[Michael Zingale]

nice hunting Bill!

On Sat, Jun 2, 2018 at 2:16 PM, Bill Paxton <paxton at kitp.ucsb.edu> wrote:

> Hi Phil,
>
> Turns out the problem comes from using bicubic splines in a region where
> they go nuts and throw big oscillations.  The wiggles are then used for
> getting a numerical value for the partials, so those partials can be
> crazy.  The solution is “don’t do that” — i.e. don’t push the use of the
> splines into parts of (logRho,logT) where they encounter problems like
> this.  One of the bad areas is where SCVH and OPAL are blended at the
> highest logRho values.   For the particular problem you’ve hit, the
> solution is to back off and cut off using the splines at a lower logRho (=
> 3.1 instead of 3.6 or so).  That change will go out in the next release.
> But for now, as a temporary work around you can get rid of the negative
> chiT’s etc just by turning off DT2
>
>          info = 0
>          call eos_ptr(handle,rq,info)
>          if (info /= 0) stop 'failed call eos_ptr'
>          rq% use_eosDT2 = .false.
>
> Make a note to remove this when you next upgrade to a newer mesa.
>
> For Z > 0.04, the code will use PTEH instead of DT2.  But that is ok since
> it doesn’t depend on OPAL/SCVH.
>
> If you’d like to skip doing this, i’m happy to provide you with a
> pre-release revision with the fix.
>
> cheers
> bill
>
>
>
>
> On May 30, 2018, at 12:34 PM, Philip Chang <chang65 at uwm.edu> wrote:
> >
> > Dear Mesa users,
> >
> > I am using mesa for a rather specialized purpose.  I have integrated the
> mesa eos into a hydrodynamics code (moving-mesh voronoi tessellation) and
> am using it for dynamically stellar problems.  Right now I have been
> simulating a 15 solar mass ZAMS star both in SPH and moving mesh mode.  SPH
> works great.  But the moving-mesh stuff crashes.
> >
> > The reason is that I need the sound speed or some estimate for the
> Riemann solve. In doing so, I get P, rho and gamma_1 from the mesa eos.
> However, I have found that the return values of gamma_1 are sometimes < 1
> -- bad -- and sometimes < 0 -- really bad.  As the sound speed is
> \sqrt{\gamma_1 P/rho}, this gives NaN's everywhere.  Negative gamma_1's are
> occuring around that appears to be ionization zones for H or He and are
> fairly strongly negative like -2 or -3.
> >
> > I'm trying to see what the best way of dealing with this is.  As MESA
> has a HLLC solver in it, it also relies on the sound speed to get an
> estimate for the signal velocities and contact wave pressure.  As far as I
> can tell, it would be vulnerable to the same issues that I am encountering.
> >
> > So my question is two fold.
> >
> > 1. Is the negative gamma_1 physical? I believe it is, as it occurs near
> ionization zones.
> >
> > 2. What is the proper way of computing sound speed in this circumstances?
> >
> > Thanks in advance for any help.
> >
> > Cheers,
> >
> > Phil
> >
> > _______________________________________________
> > mesa-users at lists.mesastar.org
> > https://lists.mesastar.org/mailman/listinfo/mesa-users
> >
>
> _______________________________________________
> mesa-users at lists.mesastar.org
> https://lists.mesastar.org/mailman/listinfo/mesa-users
>
>


-- 
Michael Zingale
Associate Professor

Dept. of Physics & Astronomy • Stony Brook University • Stony Brook, NY
11794-3800
*phone*:  631-632-8225
*e-mail*: Michael.Zingale at stonybrook.edu
*web*: http://www.astro.sunysb.edu/mzingale
github: http://github.com/zingale
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.mesastar.org/pipermail/mesa-users/attachments/20180602/7dff05b7/attachment.html>