[Users] parsing bug for temperature_evolution_method

Thu Mar 11 12:46:49 CST 2021

Hello Hee Il,

nothing immediately strikes me as off, other than:

HydroBase::temperature_evolution_method = "GRHydro" #"GRHydro"

which should be set to "none" since temperature_evolution_method does
not refer to whether the fluid is cold or not, but instead refers to
whether GRHydro uses temperature or specific internal energy as one of
the primitive variables. This is mostly controlled by the EOS and
tabulated EOS from nuclear physics will use "temperature" since this is
the proper variable for the thermodynamical ensemble used when deriving
them, but no other (as far as I know) EOS in EOS_Omni uses those.

Please also see a bit the discussion in the minutes for today's ET
call. 

You are currently reading in file G2_I14vs14_D5R33_80km which is a
Gamma=2 dataset. Setting 

EOS_Omni::hybrid_gamma_th = 1.00

in that case may or may not be a good idea. 

To be sure: the only change between the red and green lines in the
parfile is changing

GRHydro::GRHydro_eos_table          = "Hybrid"

to

GRHydro::GRHydro_eos_table          = "Ideal_Fluid"

?

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 at 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 at 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 .
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
Url : http://lists.einsteintoolkit.org/pipermail/users/attachments/20210311/4490e554/attachment.bin 