<div dir="ltr"><div dir="ltr"><div dir="ltr">Hi Roland,<div><br></div><div>I'm very sorry for the confusion and taking up so much of your time. </div></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
You should still set:<br>
<br>
EOS_Omni::poly_gamma = 2.0<br>
EOS_Omni::poly_K = 123.613314525753<br></blockquote><div><br></div><div>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. <br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
since GRHydro uses the polytropic EOS for "atmosphere" (low density) regions, irrespective of the EOS used for the non-atmosphere parts.<br>
<br>
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?<br></blockquote><div><br></div><div>You're right.</div><div><br></div><div>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.</div><div><br></div><div>Thank you.</div><div><br></div><div>Hee Il</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
If there is no backtrace and no core file then this makes things a bit harder.<br>
<br>
However you can use gdb to try and get a line number from the backtrace shown in your out file. Eg the line <br>
<br>
[node14:39016] [ 2] ./SIMFACTORY/cactus_bns_ompi3.nofp(grhydro_initialatmospherereset_+0xc2b)[0x163c4f3]<br>
<br>
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).<br>
<br>
In any case you can get some idea of the line number by doing the following:<br>
<br>
gdb ./SIMFACTORY/cactus_bns_ompi3.nofp<br>
<br>
ie loading the very same executable that failed into gdb (on the login<br>
node of the cluster where it failed), then in gdb<br>
<br>
info line *(grhydro_initialatmospherereset_+0xc2b)<br>
<br>
Unfortunately this being Fortran code there are basically two versions<br>
of line numbers you can get (depends on how you compiled). I the number<br>
is very large then you should look at the preprocessed file in<br>
<br>
Cactus/configs/sim/build/GRHydro/...<br>
<br>
which is probably the file that gdb points to. If the line number is<br>
small (or otherwise obviously not in the GRHydro_InitialAtmosphereReset<br>
function in the file) then instead you should look at the original<br>
source file in arrangements/EinsteinEvolve/GRHydro/src/ (you hope for<br>
the latter but expect the former).<br>
<br>
My guess would be that it's the line:<br>
<br>
y_e_con(i,j,k) = dens(i,j,k) * y_e(i,j,k)<br>
<br>
which assumes that if you are evolving temperature you must also evolve<br>
neutrinos (that being the typical application for tabulated<br>
microphysical EOS vs some hybrid EOS).<br>
<br>
Yours,<br>
Roland<br>
<br>
> Thanks Roland,<br>
> <br>
> 2021년 3월 12일 (금) 오전 12:03, Roland Haas <<a href="mailto:rhaas@illinois.edu" target="_blank">rhaas@illinois.edu</a>>님이 작성:<br>
> <br>
> > Hello Hee Il,<br>
> ><br>
> > > I have encountered a bug in using<br>
> > HydroBase::temperature_evolution_method.<br>
> > > If it is given explicitly by taking its default value "GRHydro", my<br>
> > > runs crashed while reading a Lorene data. But if it's not given in the<br>
> > > parameter file, it run smoothly but the results are the same with the<br>
> > case<br>
> > > of taking "none".<br>
> > The default value for HydroBase::temperature_evolution_method is "none"<br>
> > (see<br>
> ><br>
> > <a href="https://urldefense.com/v3/__http://einsteintoolkit.org/thornguide/EinsteinBase/HydroBase/documentation.html*TBL-15-7-1__;Iw!!DZ3fjg!tucQWQHP14O6616GC9hbcfiTuJnh7M7ZnmtO2Xg4OCz170x4pdRBiU2aDznE6Uek$" rel="noreferrer" target="_blank">https://urldefense.com/v3/__http://einsteintoolkit.org/thornguide/EinsteinBase/HydroBase/documentation.html*TBL-15-7-1__;Iw!!DZ3fjg!tucQWQHP14O6616GC9hbcfiTuJnh7M7ZnmtO2Xg4OCz170x4pdRBiU2aDznE6Uek$</a> )<br>
> > so not setting it explicitly is identical to setting it to "none".<br>
> ><br>
> <br>
> Yes, I was mistaken. I confirmed that "none" is the default value.<br>
> [khi@hygra GRHydro]$ ~/ET/Turing/exe/cactus_bns_turing -o<br>
> HydroBase::temperature_evolution_method<br>
> Parameter: HydroBase::temperature_evolution_method,<br>
> HydroBase::temperature_evolution_method<br>
> Description: "Evolution method for temperature"<br>
> Type: KEYWORD<br>
> Default: none<br>
> <br>
> <br>
> > > I found this bug when I was testing Hybrid EOS. I've tried to realize<br>
> > pure<br>
> > > Polytrope (or Ideal_Fluid) by using the piecewise Hybrid EOS interface.<br>
> > But<br>
> > > the results are showing around 10% more variations in rhomax compared to<br>
> > > the pure Polytrope/Ideal_Fluid cases.<br>
> > Can you provide the full log output (and ideally a parfile to reproduce<br>
> > the issue) for stdout and stderr as well as any backtract.X.txt files<br>
> > created?<br>
> ><br>
> <br>
> I attached the log file and the parfile. No backtrace.X.txt files were<br>
> created and the core dump contains no infos other than "No Stack".<br>
> <br>
> <br>
> > If it crashes with a SEGFAULT or similar that would indeed be a bug.<br>
> > Note that most of the LORENE data has been used with equations of<br>
> > state that do not use temperature (usually tabulated ones only) so if<br>
> > you are using one of LORENE's sample data sets and set this parameter<br>
> > then even if the code apparently succeeds the evolution may not be<br>
> > correct or what you expect.<br>
> <br>
> <br>
> I agree. My main issue might not be related to the crash. Due to the<br>
> confusion mentioned above, I've tried to turn off keytemp in order to see<br>
> if I get better results having no extra pulsations. Actually there's no<br>
> difference but it only increased the chance of crashes. What I get at the<br>
> moment is extra >10% pulsations if I use Hybrid EOS (green line) compared<br>
> with the redline (Ideal_Fluid). Similar pulsations were found for the case<br>
> of SLy as well. I've used both Lorene and Lorene2 IDs (by using either<br>
> table and piecewised poly eos). Would you check the parfile to see if I'm<br>
> making a simple mistake?<br>
> <br>
> Yours,<br>
> <br>
> Hee Il<br>
<br>
<br>
-- <br>
My email is as private as my paper mail. I therefore support encrypting<br>
and signing email messages. Get my PGP key from <a href="http://pgp.mit.edu" rel="noreferrer" target="_blank">http://pgp.mit.edu</a> .<br>
</blockquote></div></div></div>