rjfarmer / pymesa Goto Github PK

My build process on mesa version 11701 failed at:

MAKEDEPF90
FC ../src/eos_correction.f
LDFLAGS = -Wl,-rpath=make:../lib
make: LDFLAGS: Command not found
makefile_base:69: recipe for target 'eos_correction.o' failed
make: *** [eos_correction.o] Error 127

/home/alfred/StarWare/Mesa/mesa/sample
FAILED

pyMESA building fail

Versions in use:
GNU Fortran (GCC) 8.3.0
gfort2py: 1.1.3
pyMesa: 1.0.3

Is there any quick fix for that?

Thanks and regards,
Alfred

pyMESA build fails using the ./mesa-build.sh

************************************************
************************************************
************************************************

MESA installation was successful

************************************************
************************************************
************************************************


****************************************************************
pyMESA building fail
****************************************************************

becuase $MESA_DIR/lib contains only .a libraries, not shared .so libraries. I tried creating the .so from .a, but couldn't. Probably becuase the objects in the libraries weren't complied with the -fPIC tag. I'm not sure, I'm not experienced with fortran...

Is there some quick way around this? Can I provide any further information?

Used versions:
MESA version r22.11.1
pyMESA 1.0.3
gfortran 12.1.0

Need to add a switch to build with -dynamiclib not -shared when on macs

Reported by Stephen Ro

When trying to get opacities of type 2 it is required that I specify the Zbase variable,

must supply Zbase for Type2 opacities   -1.0000000000000000D+00
File: ../private/kap_eval.f90, Line:  525
ERROR STOP 1

but in fortran that is always accessed via a pointer, for instance here

      program sample_kap
      use kap_lib
      use kap_def
      ...
      implicit none
      ...
      type (Kap_General_Info), pointer :: rq1, rq2
      ...
      call kap_ptr(handle1, rq1, ierr)
      ...
      rq1% Zbase = Z_init
      ...

Is there a way to resolve this and access Zbase from pyMesa?

Example eos.py of mesa models needs to updated for the recent version of mesa and gfort2py

I'm trying to call the EOS, and I've run into an index offset problem that wasn't around last time I used pyMesa (fall 2017 with version 10000).

As shown in eos.py, one has to subtract 1 from that you get from eos_def to make sure you get the right element of the "res" array. E.g.
i_lnE = eos_def.i_lnE.get() - 1
E = np.exp(res[i_lnE])
The README mentions this and notes that numpy indexes from 0 while fortran indexes from 1. So far, no big deal.

BUT, with my most recent installation of pyMesa (yesterday), somehow the EOS quantities are shifted even further in the "res" array, so that now I have to subtract 2 to get the right quantity. So the above example has to become
i_lnE = eos_def.i_lnE.get() - 2
E = np.exp(res[i_lnE])
Even worse, lnPgas should be the first element of the "res" array, but seems to have been shifted out of the array altogether, while the last entry of the array is never filled with anything. So I can't ask the EOS what the pressure is!

Could this be caused by some change in gfort2py? Is there maybe a version of pyMesa and/or gfort2py that I can install to run with 10398 that won't have this bug?

I am trying to read the const module of MESA to access the values defined in public/const_def.f90. Some of the values in const_def.<variable>.value appear to be wrong, e.g., Boltzmann's constant.

After installing pyMESA (fresh checkout of the repo), I tried:

import pyMesaUtils as pym

print(pym.MESA_DIR) #  correct path
print(pym.MESA_VERSION) # correct

const_lib, const_def = pym.loadMod("const")

print("Msun="+f"{const_def.Msun.value:.2e}")
print("Lsun="+f"{const_def.Lsun.value:.2e}")
print("kerg="+f"{const_def.kerg.value:.2e}")
print("boltzm="+f"{const_def.boltzm.value:.2e}")
print("secyer="+f"{const_def.secyer.value:.2e}", )
  
> Msun=1.99e+33
> Lsun=3.83e+33
> kerg=9.95e+00
> boltzm=9.95e+00
> secyer=3.16e+07

where Msun, Lsun, and secyer seem correct, but both values of Boltzmann's constant are not the expected value in erg/K.