Trac

trac@lists.einsteintoolkit.org

8708 discussions

[Einstein Toolkit] #910: Cactus does not detect circular schedule items
by Einstein Toolkit 11 Jun '12

11 Jun '12

#910: Cactus does not detect circular schedule items --------------------+------------------------------------------------------- Reporter: rhaas | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: Cactus | Version: Keywords: | --------------------+------------------------------------------------------- Right now none of the three schedule items below (which should all be flagged as faulty I think), triggers any warning during compile or run time: {{{ schedule group ordertest at initial { } "test schedule sorter" schedule ADMBase_CartesianMinkowski in ordertest after ADMBase_LapseOne { LANG: C } "Set the metric and extrinsic curvature to cartesian minkowski values" schedule ADMBase_LapseOne in ordertest after ADMBase_CartesianMinkowski { LANG: C } "Set the lapse to 1 at all points" SCHEDULE ADMBase_SetShiftStateOn in ordertest after ADMBase_SetShiftStateOn { LANG: C } "Set the shift_state variable to 1" }}} I attach: * a patch against ADMBase/schedule.ccl to demonstrate the output * stdout when one runs Exact/Schwarzschild_EF with the faulty schedule.ccl * a patch against src/schedule/ScheduleSorter.c and Creator that adds error checks for this situation (the part inside of TEST_SCHEDULECREATOR is for the stand-alone test inside to compile) -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/910> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 5

[Einstein Toolkit] #909: abort IOUtil_TruncateOutputFiles if called too early
by Einstein Toolkit 11 Jun '12

11 Jun '12

#909: abort IOUtil_TruncateOutputFiles if called too early -----------------------------------+---------------------------------------- Reporter: rhaas | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: Keywords: IOUtil | -----------------------------------+---------------------------------------- currently when called before the grid extension for IOUtil has been registered (which is when IOUtils learns if the is a checkpoint recovery run or not), the routine returns -1. However the documentation in the thorn guide states that {{{ Thorn IOUtil provides an aliased function for other I/O thorns to call: CCTK_INT FUNCTION IO_TruncateOutputFiles (CCTK_POINTER_TO_CONST IN cctkGH) This function simply returns 1 or 0 if output files should or should not be truncated. }}} Since there are thorns out there that take this to heart and test for IO_TruncateOutputFiles() being true (ie non-zero) these thorns always overwrite data during a recovery when calling IOUtils too early. This happened to Carpet in ticket #908. The attached patch makes IOUtil abort instead which seems better than silently returning the wrong (since undocumented) answer. No actual user thorn should be affected. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/909> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

[Einstein Toolkit] #908: do not output grid structure to files in SetupGH
by Einstein Toolkit 11 Jun '12

11 Jun '12

#908: do not output grid structure to files in SetupGH --------------------+------------------------------------------------------- Reporter: rhaas | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: Other | Version: Keywords: | --------------------+------------------------------------------------------- instead wait until WRAGH at which point IOUtils has had time to initialize itself and we can query IO_TruncateOutputFiles with confidence. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/908> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

[Einstein Toolkit] #949: RotatingSymmetry90: abort when evaluating tensor type for Weyl scalars
by Einstein Toolkit 07 Jun '12

07 Jun '12

#949: RotatingSymmetry90: abort when evaluating tensor type for Weyl scalars ---------------------------------------------+------------------------------ Reporter: bmundim | Owner: Type: defect | Status: new Priority: major | Milestone: Component: EinsteinToolkit thorn | Version: Keywords: RotatingSymmetry90 Weyl scalars | ---------------------------------------------+------------------------------ RotatingSymmetry90 is aborting when evaluating tensor type for Weyl scalars. It doesn't take into account the ManualCartesian type for example. The attached patch avoids that. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/949> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 7

[Einstein Toolkit] #884: RotatingSymmetry90 lacks ManualCartesian tensor type support
by Einstein Toolkit 07 Jun '12

07 Jun '12

#884: RotatingSymmetry90 lacks ManualCartesian tensor type support --------------------+------------------------------------------------------- Reporter: tbode | Owner: tbode Type: defect | Status: new Priority: major | Milestone: ET_2012_05 Component: Cactus | Version: development version Keywords: | --------------------+------------------------------------------------------- RotatingSymmetry90 currently doesn't process the ManualCartesian tensor type. Since WeylScal4 now has more than Psi4, this means WeylScal4 and RotatingSymmetry90 can't both be active. Does anyone have a patch lying around adding ManualCartesian support to RotatingSymmetry90 they wish to contribute? If not, I'll see to writing a patch. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/884> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

[Einstein Toolkit] #948: Do not use bare "except:"
by Einstein Toolkit 06 Jun '12

06 Jun '12

#948: Do not use bare "except:" ------------------------+--------------------------------------------------- Reporter: eschnett | Owner: eschnett Type: defect | Status: new Priority: minor | Milestone: Component: SimFactory | Version: Keywords: | ------------------------+--------------------------------------------------- A bare "except:" (without listing an exception class) will intercept all exceptions, including the user typing control-C to abort. This should therefore not be used, except if (a) the code will abort anyway with an appropriate user-visible error message, or (b) the code will re-raise the exception via "raise". In particular, Simfactory catches filesystem errors with bare excepts; this should be cleaned up. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/948> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 0

[Einstein Toolkit] #900: GRHydro: do not use the Slopelimiter function
by Einstein Toolkit 05 Jun '12

05 Jun '12

#900: GRHydro: do not use the Slopelimiter function -----------------------------------+---------------------------------------- Reporter: bmundim | Owner: Type: defect | Status: new Priority: minor | Milestone: ET_2012_05 Component: EinsteinToolkit thorn | Version: Keywords: GRHydro slopelimiter | -----------------------------------+---------------------------------------- This patch was generated by Josh Faber in response to the discussion at http://lists.einsteintoolkit.org/pipermail/users/2012-January/001710.html but it wasn't ever applied. It essentially deprecates the use of slopelimiter function. In the future it should be completely removed from the code. At the moment it is only commented out. Ok to apply? it is a bug fix... -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/900> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 9

[Einstein Toolkit] #937: CCTK_RegexMatch does not return a distinguishable error condition when the regular expression is invalid
by Einstein Toolkit 04 Jun '12

04 Jun '12

#937: CCTK_RegexMatch does not return a distinguishable error condition when the regular expression is invalid --------------------+------------------------------------------------------- Reporter: rhaas | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: Cactus | Version: Keywords: | --------------------+------------------------------------------------------- CCTK_RegexMatch right now returns 1 if the pattern matches the string and 0 if either the pattern does not match or could not be compiled via regcomp. It would be useful if user code could distinguish between these two cases. The attached patch changes the return value in the "does not compile" case to -1 and updates all source files that I could find that use it. Note that this patch changes behaviour of a routine. It used to return 0 for non-compiling patterns so thorns that test for C-like true would interpret invalid patterns as does-not-match, but will interpret the -1 return value as does-match. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/937> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 7

[Einstein Toolkit] #821: avoid allocting temp memory twice in EOS Omni
by Einstein Toolkit 04 Jun '12

04 Jun '12

#821: avoid allocting temp memory twice in EOS Omni -------------------+-------------------------------------------------------- Reporter: rhaas | Type: enhancement Status: new | Priority: minor Milestone: | Component: Other Version: | Keywords: -------------------+-------------------------------------------------------- instead of storing a copy of the data in the Fortran module store Fortran pointers. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/821> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 6

[Einstein Toolkit] #943: Redesign ADMBase
by Einstein Toolkit 02 Jun '12

02 Jun '12

#943: Redesign ADMBase -----------------------------------+---------------------------------------- Reporter: eschnett | Owner: Type: enhancement | Status: new Priority: major | Milestone: Component: EinsteinToolkit thorn | Version: Keywords: | -----------------------------------+---------------------------------------- I believe it is time to redesign ADMBase. The interface it offers has accumulated certain features that are all but unused today. Thorns such as ADMCoupling, ADMMacros, CoordGauge, StaticConformal should be removed. The scheduling interaction with the prestep and analysis bins and with MoL should be cleaned up. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/943> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 0

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac