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 <[email protected]>님이 작성: > > > > > 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@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 . >
_______________________________________________ Users mailing list [email protected] http://lists.einsteintoolkit.org/mailman/listinfo/users
