Dear All,
you can give the new EOS for GRHydro a try by recompiling with -DUSE_EOS_OMNI in CPPFLAGS and FPPFLAGS. This makes GRHydro _independent_ of EOS_Base and all EOS thorns except EOS_Omni (dependence via aliased functions).
Let's say you want to evolve a Gamma=2 polytrope with K=100 with a gamma-law. For this, you would set:
ActiveThorns = "EOS_Omni"
grhydro::grhydro_poly_eoskey = 1 grhydro::grhydro_eoskey = 2 eos_omni::gl_gamma = 2.0 eos_omni::gl_k = 100.0d0 eos_omni::poly_gamma = 2.0 eos_omni::poly_gamma_ini = 2.0 eos_omni::poly_k = 100.0d0
Note that gl_ controls the gamma-law settings and that poly settings are still needed (for fallback purposes in GRHydro if c2p fails).
Without the preprocessor defines, the code behaves as usual and is wedded to EOS_Base and EOS_Polytrope. All test suites pass. A test suite using EOS_Omni has been added. If EOS_Omni is activated and EOS_Omni parameters are added, all standard testsuites pass. This confirms that EOS_Omni produces the same results as EOS_Base + EOS_Polytrope/EOS_Ideal_Fluid/EOS_Hybrid.
Currently, finite-temperature EOS support is lacking. This requires messing with various routines in GRHydro to include temperature in calls etc. This will be the next step in the EOS_Omni development.
Since EOS_Omni already provides the entire functionality of the EOS_Base interface, I would suggest to remove this old interface from the code soon (once people have tried out and are happy with EOS_Omni).
Please report any problems you may find with EOS_Omni.
Best,
- Christian
RE: GRHydro
All,
I would like to remove a bunch of NaN checks in Eigenproblem, Marquina, Roe, Prim2Con, and Con2Prim that somebody put in for debugging purposes (to track down a problem) and that are detrimental to performance (I ran tests with and without them active).
If a NaN appears, the code will still fail and standard debugging techniques can be applied to track it down. No need to have these permanently in the source code.
Any objections?
Thanks.
- Christian
On Sun, Jul 18, 2010 at 1:38 PM, Christian D. Ott cott@tapir.caltech.edu wrote:
RE: GRHydro
All,
I would like to remove a bunch of NaN checks in Eigenproblem, Marquina, Roe, Prim2Con, and Con2Prim that somebody put in for debugging purposes (to track down a problem) and that are detrimental to performance (I ran tests with and without them active).
If a NaN appears, the code will still fail and standard debugging techniques can be applied to track it down. No need to have these permanently in the source code.
Any objections?
If these checks are useful for debugging, can we keep them conditionally? Ideally there would be a parameter that enables them; if this is still too slow, then an #ifdef GRHYDRO_DEBUG would be an option.
-erik
Hi,
On Sun, Jul 18, 2010 at 01:51:59PM -0500, Erik Schnetter wrote:
Any objections?
If these checks are useful for debugging, can we keep them conditionally? Ideally there would be a parameter that enables them; if this is still too slow, then an #ifdef GRHYDRO_DEBUG would be an option.
performance aside, these statements also clutter the code. They are trivial to put in if needed and I see no advantage in keeping them.
- Christian
Hi,
On Sun, Jul 18, 2010 at 01:51:59PM -0500, Erik Schnetter wrote:
If these checks are useful for debugging, can we keep them conditionally? Ideally there would be a parameter that enables them; if this is still too slow, then an #ifdef GRHYDRO_DEBUG would be an option.
On Sun, Jul 18, 2010 at 11:56:22AM -0700, Christian D. Ott wrote:
performance aside, these statements also clutter the code. They are trivial to put in if needed and I see no advantage in keeping them.
I agree with Erik that if they affect performance that much we should protect them with #defines, but leave them in the code - even if this clutters it. They are much easier to put back in by setting a #define than by putting them all in back by hand. They can help quite a bit when you know that there are NaNs produces somewhere in GRHydro and you want to know quickly where and why.
I don't object to make the default omitting them from the built.
Frank
Hi,
On Mon, Jul 19, 2010 at 08:43:00AM -0500, Frank Loeffler wrote:
I agree with Erik that if they affect performance that much we should protect them with #defines, but leave them in the code - even if this clutters it. They are much easier to put back in by setting a #define than by putting them all in back by hand. They can help quite a bit when you know that there are NaNs produces somewhere in GRHydro and you want to know quickly where and why.
they don't do that.
(a) They are not general -- i.e., in Prim2Con, there is a check on the lorentz factor and on dens, but that's it (it's even redunant!). This test won't tell you if there is a nan in another var.
(b) They are only in some parts of the code (i.e., the parts that the person who needed them was using).
(c) They don't tell you 'quickly where and why'. If you get an error message like:
call CCTK_WARN(GRHydro_NaN_verbose, "c2p failed and being told not to reset the pressure")
Do you have any clue what happened? You are not even being told where (what physical location; what reflevel).
Of course, one could spend one's life making these messages better. But we are paid for doing science, not for writing foolproof code.
I maintain that there is no point in having such messages. They don't help -- if you catch yourself a NaN (like I did yesterday!), you still have to go in and do old-fashioned debugging to see what is going on.
Since we are not reaching a conclusion via e-mail, I would like to discuss this in today's call.
- Christian
On Mon, Jul 19, 2010 at 9:04 AM, Christian D. Ott cott@tapir.caltech.edu wrote:
Hi,
On Mon, Jul 19, 2010 at 08:43:00AM -0500, Frank Loeffler wrote:
I agree with Erik that if they affect performance that much we should protect them with #defines, but leave them in the code - even if this clutters it. They are much easier to put back in by setting a #define than by putting them all in back by hand. They can help quite a bit when you know that there are NaNs produces somewhere in GRHydro and you want to know quickly where and why.
they don't do that.
(a) They are not general -- i.e., in Prim2Con, there is a check on the lorentz factor and on dens, but that's it (it's even redunant!). This test won't tell you if there is a nan in another var.
(b) They are only in some parts of the code (i.e., the parts that the person who needed them was using).
(c) They don't tell you 'quickly where and why'. If you get an error message like:
call CCTK_WARN(GRHydro_NaN_verbose, "c2p failed and being told not to reset the pressure")
Do you have any clue what happened? You are not even being told where (what physical location; what reflevel).
Of course, one could spend one's life making these messages better. But we are paid for doing science, not for writing foolproof code.
I maintain that there is no point in having such messages. They don't help -- if you catch yourself a NaN (like I did yesterday!), you still have to go in and do old-fashioned debugging to see what is going on.
Since we are not reaching a conclusion via e-mail, I would like to discuss this in today's call.
For the record I would like to mention some of the possibilities mentioned during todays' phone call:
(1) There could be a macro CCTK_NANCHECK that checks a scalar variable for nan, outputting a warning message. This would be easy to disable, and would be much cleaner than the current multi-line code for each variable.
(2) The NaNChecker thorn could be used to generate a nanmask, either automatically after each scheduled function (e.g. via Carpet's CallFunction), or manually after each 3D loop.
(3) The thorn NaNCatcher can enable floating point exceptions as soon as any nan is encountered, aborting the job (or starting a debugger).
These approaches do not work well at the moment, because there are coarse grid points which do not contribute to the overall solution, but it is not obvious which coarse grid points these are. Carpet needs to provide a mask describing which grid points remain "unused" after restriction.
-erik
Hi,
On Monday, July 19, 2010 12:47:32 pm Erik Schnetter wrote:
On Mon, Jul 19, 2010 at 9:04 AM, Christian D. Ott
cott@tapir.caltech.edu wrote:
Hi,
On Mon, Jul 19, 2010 at 08:43:00AM -0500, Frank Loeffler wrote:
I agree with Erik that if they affect performance that much we should protect them with #defines, but leave them in the code - even if this clutters it. They are much easier to put back in by setting a #define than by putting them all in back by hand. They can help quite a bit when you know that there are NaNs produces somewhere in GRHydro and you want to know quickly where and why.
they don't do that.
(a) They are not general -- i.e., in Prim2Con, there is a check on the lorentz factor and on dens, but that's it (it's even redunant!). This test won't tell you if there is a nan in another var.
(b) They are only in some parts of the code (i.e., the parts that the person who needed them was using).
(c) They don't tell you 'quickly where and why'. If you get an error message like:
call CCTK_WARN(GRHydro_NaN_verbose, "c2p failed and being told not to reset the pressure")
Do you have any clue what happened? You are not even being told where (what physical location; what reflevel).
Of course, one could spend one's life making these messages better. But we are paid for doing science, not for writing foolproof code.
I maintain that there is no point in having such messages. They don't help -- if you catch yourself a NaN (like I did yesterday!), you still have to go in and do old-fashioned debugging to see what is going on.
Since we are not reaching a conclusion via e-mail, I would like to discuss this in today's call.
For the record I would like to mention some of the possibilities mentioned during todays' phone call:
(1) There could be a macro CCTK_NANCHECK that checks a scalar variable for nan, outputting a warning message. This would be easy to disable, and would be much cleaner than the current multi-line code for each variable.
(2) The NaNChecker thorn could be used to generate a nanmask, either automatically after each scheduled function (e.g. via Carpet's CallFunction), or manually after each 3D loop.
just some maybe trivial comment from my side: please use double or int numbers for the mask and not some fancy memory saving bitmask. This makes visualization much easier because readers won't have to distinguish between weird number formats.
cheers, Christian
(3) The thorn NaNCatcher can enable floating point exceptions as soon as any nan is encountered, aborting the job (or starting a debugger).
These approaches do not work well at the moment, because there are coarse grid points which do not contribute to the overall solution, but it is not obvious which coarse grid points these are. Carpet needs to provide a mask describing which grid points remain "unused" after restriction.
-erik
On Mon, Jul 19, 2010 at 4:11 PM, Christian Reisswig reisswig@tapir.caltech.edu wrote:
just some maybe trivial comment from my side: please use double or int numbers for the mask and not some fancy memory saving bitmask. This makes visualization much easier because readers won't have to distinguish between weird number formats.
Here is another maybe trivial comment: If the density has been output as HDF5 file, please add functionality to display it as nanmask, so that we don't have to convert the numbers and write a second file. Often, nans are displayed as black or red or zero, and that isn't always good to look at.
-erik
Hi Christian,
I think it is important to set up a nan mask first to help visualizing where c2p is failing for example. Once we have that set up then we could erase these nan checks or let them there only when compiler debugging flags are passed. In any case, maybe you could post here the performance difference results you found and the patch you are proposing.
Cheers... Bruno.
Christian D. Ott wrote:
RE: GRHydro
All,
I would like to remove a bunch of NaN checks in Eigenproblem, Marquina, Roe, Prim2Con, and Con2Prim that somebody put in for debugging purposes (to track down a problem) and that are detrimental to performance (I ran tests with and without them active).
If a NaN appears, the code will still fail and standard debugging techniques can be applied to track it down. No need to have these permanently in the source code.
Any objections?
Thanks.
- Christian
Users mailing list Users@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users
Hi Bruno,
On Sun, Jul 18, 2010 at 02:56:49PM -0400, Bruno C. Mundim wrote:
I think it is important to set up a nan mask first to help visualizing where c2p is failing for example. Once we have that set up then we could erase these nan checks or let them there only when compiler debugging flags are passed. In any case, maybe you could post here the performance difference results you found and the patch you are proposing.
the GF GRHydro_C2P_failed does precisely (I think) what you describe. This is unrelated to the NaN checks that I would like to remove.
- Christian
users@lists.einsteintoolkit.org
-
Bruno C. Mundim -
Christian D. Ott -
Christian Reisswig -
Erik Schnetter -
Frank Loeffler