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@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/EinsteinBa... ) 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