[Users] parsing bug for temperature_evolution_method

[Hee Il Kim]

Hi Roland,

I'm very sorry for the confusion and taking up so much of your time.

>
> You should still set:
>
> EOS_Omni::poly_gamma = 2.0
> EOS_Omni::poly_K = 123.613314525753
>

My issue solely came from not assigning poly EOS in the atmosphere as you
mentioned above. From some point on, I didn't assign them.


>
> 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?
>

You're right.

Thanks for the kind explanation below. I was not going to take temperature
evolution seriously, so I think I have no more issues left. The debugging
tips below would be very helpful in my future studies.

Thank you.

Hee Il



> 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 --------------
An HTML attachment was scrubbed...
URL: http://lists.einsteintoolkit.org/pipermail/users/attachments/20210312/f03fa2b6/attachment-0001.html