#430: Convert all parameter files, examples, and test cases to EOS_Omni
-----------------------------------+----------------------------------------
Reporter: eschnett | Owner:
Type: defect | Status: new
Priority: minor | Milestone:
Component: EinsteinToolkit thorn | Version:
Keywords: |
-----------------------------------+----------------------------------------
Now that EOS_Omni is standard, we should convert all parameter files.
At the moment, these parameter files still reference EOS_Base:
EinsteinInitialData/TOVSolver/test/test_one_boost_max/test_one_boost_max.par
EinsteinInitialData/TOVSolver/test/test_one_static_max/test_one_static_max.par
EinsteinInitialData/TOVSolver/test/test_tov_carpet/test_tov_carpet.par
EinsteinInitialData/TOVSolver/test/test_two_av/test_two_av.par
EinsteinInitialData/TOVSolver/test/test_two_max/test_two_max.par
LSUDevelopment/Refluxing/par/GRHydro_Carpet_Shocktube_base_works_with_gitCarpet.par
The Refluxing parameter file is for reference only and should be remove
now that hg Carpet is the default.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/430>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#358: FAQ entry
----------------------------+-----------------------------------------------
Reporter: knarf | Owner:
Type: enhancement | Status: new
Priority: minor | Milestone:
Component: Cactus website | Version:
Keywords: |
----------------------------+-----------------------------------------------
For a new FAQ:
Q: I get errors like "/usr/include/H5Dpublic.h:145: error: too many
arguments to function ‘hid_t H5Dopen1(hid_t, const char*)’"
A: The HDF5 library you use is either version 1.6 or defaults to it. If it
is version 1.6.x, update to 1.8.x. If it is 1.8.x and it defaults to the
1.6 API version, you might be out of luck, especially on Debian Squeeze
systems, see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=537414. What
you can then do is to remove (comment) out the macro H5_USE_16_API_DEFAULT
in /usr/include/H5pubconf.h. This isn't pretty, but is really a bug in the
package and has to be fixed there. There is no way to switch to the new
API on those systems, other than specifying the API version of each symbol
separately, which would be even messier.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/358>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#221: Simfactory should complain about unused arguments
------------------------+---------------------------------------------------
Reporter: eschnett | Owner: mthomas
Type: defect | Status: new
Priority: major | Milestone:
Component: SimFactory | Version:
Keywords: |
------------------------+---------------------------------------------------
When more arguments are given to simfactory that it uses, it should
complain with an error message.
For example, "sim stop sim1 sim2" stops simulation sim1 and ignores the
argument sim2. Instead, it should output an error message if the argument
sim2 is ignored.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/221>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#120: Improve built-in help system
-------------------------+--------------------------------------------------
Reporter: hinder | Owner: mthomas
Type: enhancement | Status: new
Priority: major | Milestone:
Component: SimFactory | Version:
Keywords: |
-------------------------+--------------------------------------------------
SimFactory currently provides a single help screen when you type "sim
help". I would like to be able to do "sim help <command>" and get help
which is relevant for that command. This help should say briefly what the
command does, and give a comprehensive list of the options specific to
that command. The top-level "sim help" command should then give a list of
the commands, and a list of the simfactory options which apply to all
commands. This first help page should be kept as brief as possible so
that it is easy to see at a glance what commands are available. The most
common commands should be listed first, and maybe separated from the less
common commands.
I think this is important as it is the first port-of-call when someone
wants to know how to use a particular feature, especially when the syntax
is similar but not quite the same as in SimFactory 1.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/120>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#66: IOHDF5::out3D_ghosts and friends doesn't work and corrupts 2D data slices
----------------------------------+-----------------------------------------
Reporter: bcmsma@… | Owner: eschnett
Type: defect | Status: new
Priority: minor | Milestone:
Component: Carpet | Version:
Keywords: |
----------------------------------+-----------------------------------------
While the assigned values for the parameters
IOASCII::output_symmetry_points = "no"
IOASCII::out3D_ghosts = "no"
IOASCII::out3D_outer_ghosts = "no"
work as intended when CarpetIOASCII is active, it doesn't work for
CarpetIOHDF5:
IOHDF5::out3D_ghosts = "no"
IOHDF5::out3D_outer_ghosts = "no"
IOHDF5::output_symmetry_points = "no"
It doesn't do anything to the 3D data but it corrupts the 2D data slices
while
chopping out those regions. It would be nice to have them working for
IOHDF5
method, specially when visualising Pi symmetric data.
Note also that this report is for git version of Carpet. These parameters
seem to become deprecated for the hg version. Does anyone use them
regularly? Any
substitute in mind?
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/66>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#223: Make declaration of CCTK_ARGUMENTS safer
-------------------------+--------------------------------------------------
Reporter: eschnett | Owner:
Type: enhancement | Status: new
Priority: minor | Milestone:
Component: Cactus | Version:
Keywords: |
-------------------------+--------------------------------------------------
I suggest to change the declaration of CCTK_ARGUMENTS in C from
cGH * cctkGH
to
cGH const * CCTK_RESTRICT const cctkGH
which should lead to safer code and may even enable some optimisations.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/223>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#425: Case sensitivity GSL_DIR=BUILD
----------------------------------------+-----------------------------------
Reporter: reisswig@… | Type: enhancement
Status: new | Priority: minor
Milestone: | Component: Cactus
Version: | Keywords: GSL_DIR BUILD
----------------------------------------+-----------------------------------
The thorn GSL would not compile if "GSL_DIR=build" in the option list. In
order to work, it requires "GSL_DIR=BUILD", i.e. it is really case
sensitive
although I think, this is not required and should be case insensitive.
Possibly, HDF5_DIR=build may also not work for the same reason (have not
checked; should be checked as well).
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/425>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#234: Carpet mailing list is not functioning
--------------------+-------------------------------------------------------
Reporter: hinder | Owner: eschnett
Type: defect | Status: new
Priority: major | Milestone:
Component: Carpet | Version:
Keywords: |
--------------------+-------------------------------------------------------
The Carpet mailing list has been unavailable since 22-Mar-2010. This list
provides a forum for discussion of Carpet features and issues, and would
be the first port-of-call for new users. As such I think it would be good
to resurrect the mailing list.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/234>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#145: EOS_Omni requires HDF5 library. What about if it only uses HDF5 instead?
---------------------------+------------------------------------------------
Reporter: bmundim | Owner:
Type: enhancement | Status: new
Priority: major | Milestone:
Component: Other | Version:
Keywords: EOS_Omni HDF5 |
---------------------------+------------------------------------------------
At the moment EOS_Omni requires the HDF5 library to read
the nuclear EOS values from a table. Since not all distros have
fortran support for the HDF5 library as a default, I propose
to change this requirement and provide a fall back in case this
support is not present. Perhaps not using the nuclear EOS, or
reading from an ASCII file instead. This could be just a temporary
solution until the HDF5 library build script becomes more robust.
Opinions?
Thanks,
Bruno.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/145>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#365: ADMBase: evolving with evolution_method="static" does not apply boundary
conditions
----------------------+-----------------------------------------------------
Reporter: eschnett | Owner:
Type: defect | Status: new
Priority: major | Milestone:
Component: Cactus | Version:
Keywords: |
----------------------+-----------------------------------------------------
When one uses the evolution method ADMBASE::evolution_method = "static"
(which is very tempting e.g. for Cowling), then no boundary conditions are
applied. This means that the ADMBase variables remain unset on the
boundaries after regridding, leading to all sorts of (rather unexpected)
problems.
The easy solution is to use thorn Exact instead, which applies an exact
solution at each time step, including on the boundary.
I suggest to remove the ADMBase functionality to provide a "static"
evolution method, since this evolution method does not know which boundary
condition to apply, and hence is bound to fail in non-trivial situations.
Alternatively, ADMBase needs to synchronise in postregrid (and probably a
few other bins as well). ADMBase should then also offer to apply an outer
boundary condition, in this case probably a Minkowski Dirichlet boundary
condition or a von Neumann condition.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/365>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit