[Users] parsing bug for temperature_evolution_method

[Hee Il Kim]

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
>
> http://einsteintoolkit.org/thornguide/EinsteinBase/HydroBase/documentation.html#TBL-15-7-1)
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.einsteintoolkit.org/pipermail/users/attachments/20210312/6d80856d/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bns_pppoly80_2.par
Type: application/octet-stream
Size: 20836 bytes
Desc: not available
Url : http://lists.einsteintoolkit.org/pipermail/users/attachments/20210312/6d80856d/attachment-0002.obj 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: slurm-333.out
Type: application/octet-stream
Size: 7082 bytes
Desc: not available
Url : http://lists.einsteintoolkit.org/pipermail/users/attachments/20210312/6d80856d/attachment-0003.obj 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rhomax_comparison.jpg
Type: image/jpeg
Size: 26284 bytes
Desc: not available
Url : http://lists.einsteintoolkit.org/pipermail/users/attachments/20210312/6d80856d/attachment-0001.jpg