You should still set:

EOS_Omni::poly_gamma = 2.0
EOS_Omni::poly_K = 123.613314525753

since GRHydro uses the polytropic EOS for "atmosphere" (low density) regions, irrespective of the EOS used for the non-atmosphere parts.

THe issue you re reporting causing a SEGFAULT seems different, given that with a SEGFAULT in grhydro_initialatmospherereset you should be unable to evolve at all past t=0. Is that correct?

If there is no backtrace and no core file then this makes things a bit harder.

However you can use gdb to try and get a line number from the backtrace shown in your out file. Eg the line

[node14:39016] [ 2] ./SIMFACTORY/cactus_bns_ompi3.nofp(grhydro_initialatmospherereset_+0xc2b)[0x163c4f3]

indicates the address grhydro_initialatmospherereset_+0xc2b as the location of the code causing the segfault (the relative to function mode of addressing may help with address space randomization done by the kernel I guess).

In any case you can get some idea of the line number by doing the following:

gdb ./SIMFACTORY/cactus_bns_ompi3.nofp

ie loading the very same executable that failed into gdb (on the login
node of the cluster where it failed), then in gdb

info line *(grhydro_initialatmospherereset_+0xc2b)

Unfortunately this being Fortran code there are basically two versions
of line numbers you can get (depends on how you compiled). I the number
is very large then you should look at the preprocessed file in

Cactus/configs/sim/build/GRHydro/...

which is probably the file that gdb points to. If the line number is
small (or otherwise obviously not in the GRHydro_InitialAtmosphereReset
function in the file) then instead you should look at the original
source file in arrangements/EinsteinEvolve/GRHydro/src/ (you hope for
the latter but expect the former).

My guess would be that it's the line:

            y_e_con(i,j,k) = dens(i,j,k) * y_e(i,j,k)

which assumes that if you are evolving temperature you must also evolve
neutrinos (that being the typical application for tabulated
microphysical EOS vs some hybrid EOS).

Yours,
Roland

> Thanks Roland,
>
> 2021년 3월 12일 (금) 오전 12:03, Roland Haas <rhaas@illinois.edu>님이 작성:
>
> > Hello Hee Il,
> >
> > > I have encountered a bug in using
> > HydroBase::temperature_evolution_method.
> > > If it is given explicitly by taking its default value "GRHydro", my
> > > runs crashed while reading a Lorene data. But if it's not given in the
> > > parameter file, it run smoothly but the results are the same with the
> > case
> > > of taking "none".
> > The default value for HydroBase::temperature_evolution_method is "none"
> > (see
> >
> > https://urldefense.com/v3/__http://einsteintoolkit.org/thornguide/EinsteinBase/HydroBase/documentation.html*TBL-15-7-1__;Iw!!DZ3fjg!tucQWQHP14O6616GC9hbcfiTuJnh7M7ZnmtO2Xg4OCz170x4pdRBiU2aDznE6Uek$ )
> > so not setting it explicitly is identical to setting it to "none".
> >
>
>  Yes, I was mistaken. I confirmed that "none" is the default value.
>  [khi@hygra GRHydro]$ ~/ET/Turing/exe/cactus_bns_turing -o
> HydroBase::temperature_evolution_method
> Parameter:   HydroBase::temperature_evolution_method,
> HydroBase::temperature_evolution_method
> Description: "Evolution method for temperature"
> Type:        KEYWORD
> Default:     none
>
>
> > > I found this bug when I was testing Hybrid EOS. I've tried to realize
> > pure
> > > Polytrope (or Ideal_Fluid) by using the piecewise Hybrid EOS interface.
> > But
> > > the results are showing around 10% more variations in rhomax compared to
> > > the pure Polytrope/Ideal_Fluid cases.
> > Can you provide the full log output (and ideally a parfile to reproduce
> > the issue) for stdout and stderr as well as any backtract.X.txt files
> > created?
> >
>
>  I attached the log file and the parfile. No backtrace.X.txt files were
> created and the core dump contains no infos other than "No Stack".
>
>
> > If it crashes with a SEGFAULT or similar that would indeed be a bug.
> > Note that most of the LORENE data has been used with equations of
> > state that do not use temperature (usually tabulated ones only) so if
> > you are using one of LORENE's sample data sets and set this parameter
> > then even if the code apparently succeeds the evolution may not be
> > correct or what you expect.
>
>
>  I agree. My main issue might not be related to the crash. Due to the
> confusion mentioned above, I've tried to turn off keytemp  in order to see
> if I get better results having no extra pulsations. Actually there's no
> difference but it only increased the chance of crashes. What I get at the
> moment is extra  >10% pulsations if I use Hybrid EOS (green line) compared
> with the redline (Ideal_Fluid). Similar pulsations were found for the case
> of SLy as well. I've used both Lorene and Lorene2 IDs (by using either
> table and piecewised poly eos). Would you check the parfile to see if I'm
> making a simple mistake?
>
> Yours,
>
> Hee Il


--
My email is as private as my paper mail. I therefore support encrypting
and signing email messages. Get my PGP key from http://pgp.mit.edu .