Trac January 2011

trac@lists.einsteintoolkit.org

1 participants
147 discussions

[Einstein Toolkit] #176: Test parameter files without running them
by Einstein Toolkit 23 Oct '12

23 Oct '12

#176: Test parameter files without running them -------------------------+-------------------------------------------------- Reporter: hinder | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: Cactus | Version: Keywords: | -------------------------+-------------------------------------------------- It would be useful to be able to check that the parameters of a run are OK before running it. Since there can be long queue times on supercomputers, it would be good to do this on a local machine which might not have as much memory as is required for the full run. Currently, running the job would cause memory exhaustion on the smaller machine. One solution would be an additional command-line argument to Cactus --exit-after-paramcheck which stops the run cleanly after the PARAMCHECK Cactus bin. This is preferable to a new Cactus parameter, as it would not require the parameter file to be modified. One could imagine this also being potentially used by simfactory automatically when submitting a job (though this would only work if you could run MPI executables on the head node). -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/176> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 12

[Einstein Toolkit] #177: EXC_BAD_ACCESS in CarpetIOASCII
by Einstein Toolkit 06 Aug '12

06 Aug '12

#177: EXC_BAD_ACCESS in CarpetIOASCII --------------------+------------------------------------------------------- Reporter: hinder | Owner: eschnett Type: defect | Status: new Priority: major | Milestone: Component: Carpet | Version: Keywords: | --------------------+------------------------------------------------------- I am trying to run a minimal parameter file for testing purposes (attached). Cactus gets as far as printing the iteration 0 info line and then appears to hang. When I run in a debugger, it reports: Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: 13 at address: 0x0000000000000000 0x0000000100b858b7 in CarpetIOASCII::WriteASCII<0> (os=@0x7fff5fbfc5e0, gfdatas={<std::_Vector_base<const gdata *, std::allocator<const gdata *> >> = {_M_impl = {<allocator<const gdata *>> = {<__gnu_cxx::new_allocator<const gdata *>> = {<No data fields>}, <No data fields>}, _M_start = 0x109f0ea10, _M_finish = 0x109f0eab8, _M_end_of_storage = 0x109f0eab8}}, <No data fields>}, gfext=@0x7fff5fbfc960, vi=0, time=0, org=@0x7fff5fbfcafc, dirs=@0x7fff5fbfd150, rl=0, ml=0, m=0, c=0, tl=0, coord_time=0, coord_lower=@0x7fff5fbfc9d8, coord_upper=@0x7fff5fbfc9f0) at ioascii.cc:1378 1378 switch (vartype) { (gdb) bt #0 0x0000000100b858b7 in CarpetIOASCII::WriteASCII<0> (os=@0x7fff5fbfc5e0, gfdatas={<std::_Vector_base<const gdata *, std::allocator<const gdata *> >> = {_M_impl = {<allocator<const gdata *>> = {<__gnu_cxx::new_allocator<const gdata *>> = {<No data fields>}, <No data fields>}, _M_start = 0x109f0ea10, _M_finish = 0x109f0eab8, _M_end_of_storage = 0x109f0eab8}}, <No data fields>}, gfext=@0x7fff5fbfc960, vi=0, time=0, org=@0x7fff5fbfcafc, dirs=@0x7fff5fbfd150, rl=0, ml=0, m=0, c=0, tl=0, coord_time=0, coord_lower=@0x7fff5fbfc9d8, coord_upper=@0x7fff5fbfc9f0) at ioascii.cc:1378 #1 0x0000000100b5b7ee in CarpetIOASCII::IOASCII<0>::OutputDirection (cctkGH=0x109f073f0, vindex=0, alias={_M_dataplus = {<allocator<char>> = {<__gnu_cxx::new_allocator<char>> = {<No data fields>}, <No data fields>}, _M_p = 0x10a06c1c8 "carpet::timing"}}, basefilename={_M_dataplus = {<allocator<char>> = {<__gnu_cxx::new_allocator<char>> = {<No data fields>}, <No data fields>}, _M_p = 0x10a06ba68 "minimal/carpet::timing"}}, dirs=@0x7fff5fbfd150, is_new_file=true, truncate_file=true) at ioascii.cc:610 #2 0x0000000100b554c4 in CarpetIOASCII::IOASCII<0>::OutputVarAs (cctkGH=0x109f073f0, varname=0x10a06c170 "CARPET::physical_time_per_hour", alias=0x10a06be00 "carpet::timing") at ioascii.cc:480 #3 0x0000000100b57370 in CarpetIOASCII::IOASCII<0>::TriggerOutput (cctkGH=0x109f073f0, vindex=0) at ioascii.cc:359 #4 0x0000000100b542b7 in CarpetIOASCII::IOASCII<0>::OutputGH (cctkGH=0x109f073f0) at ioascii.cc:239 #5 0x000000010329a006 in Carpet::OutputGH (cctkGH=0x109f073f0) at OutputGH.cc:55 #6 0x0000000103293b25 in Carpet::OutputGH (where=0x104c70f3c "Initialise::CallAnalysis", cctkGH=0x109f073f0) at Initialise.cc:1382 #7 0x000000010328d432 in Carpet::CallAnalysis (cctkGH=0x109f073f0) at Initialise.cc:530 #8 0x00000001032892d4 in Carpet::Initialise (fc=0x7fff5fbfe2b0) at Initialise.cc:118 #9 0x000000010005806a in main (argc=4, argv=0x7fff5fbfe318) at flesh.cc:80 I do not see how this line "switch(vartype)" where vartype is declared on the stack, could lead to this error. This configuration has been rebuilt with -O0 (Intel compiler) and debugging enabled. This is with the current production (Git) version of Carpet running on Mac OS 10.6.5. The code is compiled as 64 bit. This parameter file has worked in the past, though with 32 bit on Mac OS 10.5. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/177> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 6

[Einstein Toolkit] #215: Driscoll&Healy integration for Multipole
by Einstein Toolkit 16 Jun '12

16 Jun '12

#215: Driscoll&Healy integration for Multipole -------------------------+-------------------------------------------------- Reporter: eschnett | Owner: Type: enhancement | Status: new Priority: major | Milestone: Component: Cactus | Version: Keywords: | -------------------------+-------------------------------------------------- The attached patch implements a more accurate integration over the sphere, using an algorithm by Driscoll & Healy. This algorithm uses Gaussian integration weights, leading (almost) to exponential convergence. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/215> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 7

[Einstein Toolkit] #221: Simfactory should complain about unused arguments
by Einstein Toolkit 20 Mar '12

20 Mar '12

#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

1 8

[Einstein Toolkit] #120: Improve built-in help system
by Einstein Toolkit 08 Feb '12

08 Feb '12

#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

1 8

[Einstein Toolkit] #66: IOHDF5::out3D_ghosts and friends doesn't work and corrupts 2D data slices
by Einstein Toolkit 20 Dec '11

20 Dec '11

#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

1 4

[Einstein Toolkit] #223: Make declaration of CCTK_ARGUMENTS safer
by Einstein Toolkit 01 Dec '11

01 Dec '11

#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

1 8

[Einstein Toolkit] #234: Carpet mailing list is not functioning
by Einstein Toolkit 21 Nov '11

21 Nov '11

#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

1 6

[Einstein Toolkit] #145: EOS_Omni requires HDF5 library. What about if it only uses HDF5 instead?
by Einstein Toolkit 13 Nov '11

13 Nov '11

#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

1 7

[Einstein Toolkit] #136: Don't rebuild external libraries so often
by Einstein Toolkit 08 Nov '11

08 Nov '11

#136: Don't rebuild external libraries so often -------------------------+-------------------------------------------------- Reporter: eschnett | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: Cactus | Version: Keywords: | -------------------------+-------------------------------------------------- One way to keep the external libraries that have been built would be the following. Create a dummy configuration "ext" where all external libraries are built. When another configuration is built, it should be easy to specify to look there for the external libraries, or maybe this should even be the default. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/136> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 27

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac January 2011