[Mesa-users] sound speed and mesa eos

[Philip Chang]

Thanks Bill,

I'll try it and see what this does.

Cheers,

Phil


On 06/02/2018 01:16 PM, Bill Paxton 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
>>