Trac

trac@lists.einsteintoolkit.org

8708 discussions

[Einstein Toolkit] #1737: upate CarpetHDF5 reader in VisIt
by Einstein Toolkit 15 Sep '15

15 Sep '15

#1737: upate CarpetHDF5 reader in VisIt ------------------------------+--------------------------------------------- Reporter: rhaas | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: Other | Version: development version Keywords: VisIt CarpetHDF5 | ------------------------------+--------------------------------------------- Since the CarpetHDF5 reader (https://svn.cactuscode.org/VizTools/CarpetHDF5) was included in VisIt's main source code repo, we have not attempted to update that copy to the most current version. The coding style in that branch matches the official code but the patches do not apply on top of the official code due to ordering issues as well as some minor new changes to code formatting in the current (2.8.0) VisIt codebase. Since then, I have collected a number of bugfixes/improvements that are collected in various branches at https://bitbucket.org/rhaas80/carpethdf5 . It would be good to eventually try and get the for_VisIt branch (https://bitbucket.org/rhaas80/carpethdf5/branch/for_VisIt) included in the main source code repo again. It contains some bug-fixes wrt how file metadata is cached, as well as number of fixes to reduce memory footprint, number of open files (required to work on large datasets on machines that limit the total number of open files), some improvements to error reporting and robustness when dealing with partially corrupted filesets as well as changes that allow a user to combine multiple HDF5 files into a single "virtual" VisIt database using .visit files. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1737> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 1

[Einstein Toolkit] #1813: Change mechanism for comparing data in test suites
by Einstein Toolkit 14 Sep '15

14 Sep '15

#1813: Change mechanism for comparing data in test suites -------------------------+-------------------------------------------------- Reporter: sbrandt | Owner: Type: enhancement | Status: new Priority: optional | Milestone: Component: Cactus | Version: development version Keywords: | -------------------------+-------------------------------------------------- This test changes the way test data is compared. Instead of comparing line by line, it forms a key of the (t,x,y,z) coordinates and compares the values at those coordinates. Consequently, I also disable the check that the required number of procs are used. This allows us to have one set of test files, generated on a single proc, and run the test suite with multiple procs. This should make the disk space occupied by tests smaller, and make the existing tests more flexible. Pull request: https://bitbucket.org/cactuscode/cactus/pull-requests/18 /modify-the-test-utilities-so-that-a-test/diff -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1813> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 1

[Einstein Toolkit] #1045: URL field should be optional
by Einstein Toolkit 01 Sep '15

01 Sep '15

#1045: URL field should be optional ---------------------------+------------------------------------------------ Reporter: hinder | Owner: eric9 Type: defect | Status: new Priority: minor | Milestone: Component: GetComponents | Version: Keywords: | ---------------------------+------------------------------------------------ In a CRL file, it should be possible to have only an AUTH_URL field and omit the URL field, since it might be that there is no unauthenticated way to access the repository (e.g. for private repositories). At the moment, when I omit the URL field for a Git repository, the error message is: {{{ Use of uninitialized value $git_repo in substitution (s///) at ./GetComponents line 589. Use of uninitialized value $git_repo in substitution (s///) at ./GetComponents line 590. Use of uninitialized value $rec{"GIT_REPO"} in substitution (s///) at ./GetComponents line 593. Use of uninitialized value $rec{"GIT_REPO"} in substitution (s///) at ./GetComponents line 594. ... }}} -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1045> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 1

[Einstein Toolkit] #1772: Simfactory: potentially serious problem with CACHE directory in the simulations directory
by Einstein Toolkit 31 Aug '15

31 Aug '15

#1772: Simfactory: potentially serious problem with CACHE directory in the simulations directory ------------------------+--------------------------------------------------- Reporter: bmundim | Owner: Type: defect | Status: new Priority: critical | Milestone: ET_2015_05 Component: SimFactory | Version: development version Keywords: CACHE | ------------------------+--------------------------------------------------- Is the directory CACHE in the simulation directory really necessary? We are talking about executables with at most 400MB of size, which is nothing compared to current HPC storage systems. I think I might have found a design flaw on simfactory use of CACHE directory which can go unnoticed until it is too late with potential loss of thousands of SUs. Suppose we have the following situation: 1) We build a configuration A and send a simulation A1 with with parameter file 1. So simfactory copies the executable from configuration A to simulation A1 simfactory directory and creates a symlink from /scratch/simulations/CACHE/exe/cactus_A to /scratch/simulations/A1/SIMFACTORY/exe/cactus_A. 2) We then create a new simulation A2 with a different parameter file 2. This time simfactory symlink the simulation executable /scratch/simulations/A2/SIMFACTORY/exe/cactus_A to the cached one /scratch/simulations/CACHE/exe/cactus_A. 3) After a few days (or restarts) of simulations A1 and A2, you come up with a better idea/fix/new parameter which requires to recompile your configuration A. Note that we don't want to build a new configuration from scratch since cactus configurations consume both a lot of time and space to build. So you rebuild your configuration A and its executable cactus_A is updated. 4) Let's say now we submit the updated configuration with the same parameter file 2 in order to test your new idea/fix/parameter and compare it with the simulation A2, which is still running and have a few extra restarts to completion. Call this simulation A2_updated. Simfactory then copy the new updated executable cactus_A from the Cactus/exe/cactus_A to the simulation directory /scratch/simulations/A2_updated/SIMFACTORY/exe/cactus_A *and* update the CACHE symlink to that new simulation directory, ie: $ cd /scratch/simulations/CACHE/exe $ ls -l cactus_A cactus_A -> ../../../../scratch/simulations/A2_updated/SIMFACTORY/exe/cactus_A 5) The problem: now my simulation A2 restarts are compromised with a new executable. Remember that that simulation executable is actually a symlink to the one in the CACHE directory, which has just been updated. I think this whole cache directory intermediate step introduces unnecessary complexity for the user to track; it is really unnecessary and in my opinion not a good design choice. I would vote to eliminate it from simfactory completely as soon as possible, ideally even for this release. Just use one copy of the executable from cactus/exe to simulation/SIMFACTORY/exe and that's it. This is all we need to have that simulation and future ones running consistently with the same executable. Thanks! PS: I have actually noticed this issue on Hershel release (there is no option pointing to Hershel release on trac). I am working on tests for development version to confirm this issue, but give simfactory commits I believe it is still there. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1772> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 25

[Einstein Toolkit] #1807: Download instructions do not let a new user compile
by Einstein Toolkit 31 Aug '15

31 Aug '15

#1807: Download instructions do not let a new user compile -------------------------------------+-------------------------------------- Reporter: rhaas | Owner: Type: enhancement | Status: new Priority: major | Milestone: Component: EinsteinToolkit website | Version: development version Keywords: | -------------------------------------+-------------------------------------- The [http://einsteintoolkit.org/download/ Download section] of our website does not give any hint on how to compile the code after a (possibly) successful download. It should contain some additional sections 1. required installed software, in particular that svn from OSX does not work 1. a "How to compile" section that links to the [https://docs.einsteintoolkit.org/et- docs/Simplified_Tutorial_for_New_Users simplified tutorial] (preferred) or the regular tutorial (not preferred since this one requires them to get an account on Queenbee where they would have to download once more) 1. ideally a link to a "first steps" type document which could be part of an ET user guide described in #1804 -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1807> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 6

[Einstein Toolkit] #1806: enovol operator in CarpetLib is broken
by Einstein Toolkit 29 Aug '15

29 Aug '15

#1806: enovol operator in CarpetLib is broken --------------------+------------------------------------------------------- Reporter: rhaas | Owner: rhaas Type: defect | Status: new Priority: minor | Milestone: Component: Carpet | Version: development version Keywords: | --------------------+------------------------------------------------------- The implementation of {{{eno_interpolation_type = averages}}}, which is not used by default, is broken and cannot be used since it does not allow restriction. Even when adding restriction the computation of the required source region is done incorrectly and leads to segfaults since data outside of the source region is accessed. The check for regbbox + stencil width to be included in srcbbox in the prolongation operator source file seems to be broken as well since it does not take the difference between coarse and fine grid spacing into account. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1806> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 1

[Einstein Toolkit] #1809: simplify CarpetLib's data.cc file
by Einstein Toolkit 24 Aug '15

24 Aug '15

#1809: simplify CarpetLib's data.cc file ----------------------+----------------------------------------------------- Reporter: rhaas | Owner: eschnett Type: task | Status: new Priority: optional | Milestone: Component: Carpet | Version: development version Keywords: | ----------------------+----------------------------------------------------- CarpetLib's data.cc file contains a number of very large and complex switch statements inside of its {{{transfer_prolongate}}} and {{{transfer_restrict}}} routines (the prolongate one is about 500 lines long and is only one half of an {{{#if CAPRET_DIM}}} preprocessor if statement). The two switch statements also have to be kept in sync with each other whenever a new transport operator is added. It may be good to instead define some type of "operator package" object that contains the list of prolongation, restrict, time interpolation operators that correspond to a particular choice of transport operator and refinement centering as chosen in the parameter file and interface.ccl. This way the complex logic could be collected in only a single place. This would be useful since we seem to plan to add more new transport operators to Carpet. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1809> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 1

[Einstein Toolkit] #1810: simplify CarpetLib's data.cc file
by Einstein Toolkit 24 Aug '15

24 Aug '15

#1810: simplify CarpetLib's data.cc file ----------------------+----------------------------------------------------- Reporter: rhaas | Owner: eschnett Type: task | Status: new Priority: optional | Milestone: Component: Carpet | Version: development version Keywords: | ----------------------+----------------------------------------------------- CarpetLib's data.cc file contains a number of very large and complex switch statements inside of its {{{transfer_prolongate}}} and {{{transfer_restrict}}} routines (the prolongate one is about 500 lines long and is only one half of an {{{#if CAPRET_DIM}}} preprocessor if statement). The two switch statements also have to be kept in sync with each other whenever a new transport operator is added. It may be good to instead define some type of "operator package" object that contains the list of prolongation, restrict, time interpolation operators that correspond to a particular choice of transport operator and refinement centering as chosen in the parameter file and interface.ccl. This way the complex logic could be collected in only a single place. This would be useful since we seem to plan to add more new transport operators to Carpet. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1810> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 1

[Einstein Toolkit] #1811: simplify CarpetLib's data.cc file
by Einstein Toolkit 24 Aug '15

24 Aug '15

#1811: simplify CarpetLib's data.cc file ----------------------+----------------------------------------------------- Reporter: rhaas | Owner: eschnett Type: task | Status: new Priority: optional | Milestone: Component: Carpet | Version: development version Keywords: | ----------------------+----------------------------------------------------- CarpetLib's data.cc file contains a number of very large and complex switch statements inside of its {{{transfer_prolongate}}} and {{{transfer_restrict}}} routines (the prolongate one is about 500 lines long and is only one half of an {{{#if CAPRET_DIM}}} preprocessor if statement). The two switch statements also have to be kept in sync with each other whenever a new transport operator is added. It may be good to instead define some type of "operator package" object that contains the list of prolongation, restrict, time interpolation operators that correspond to a particular choice of transport operator and refinement centering as chosen in the parameter file and interface.ccl. This way the complex logic could be collected in only a single place. This would be useful since we seem to plan to add more new transport operators to Carpet. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1811> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 1

[Einstein Toolkit] #1808: simplify CarpetLib's data.cc file
by Einstein Toolkit 24 Aug '15

24 Aug '15

#1808: simplify CarpetLib's data.cc file ----------------------+----------------------------------------------------- Reporter: rhaas | Owner: eschnett Type: task | Status: new Priority: optional | Milestone: Component: Carpet | Version: development version Keywords: | ----------------------+----------------------------------------------------- CarpetLib's data.cc file contains a number of very large and complex switch statements inside of its {{{transfer_prolongate}}} and {{{transfer_restrict}}} routines (the prolongate one is about 500 lines long and is only one half of an {{{#if CAPRET_DIM}}} preprocessor if statement). The two switch statements also have to be kept in sync with each other whenever a new transport operator is added. It may be good to instead define some type of "operator package" object that contains the list of prolongation, restrict, time interpolation operators that correspond to a particular choice of transport operator and refinement centering as chosen in the parameter file and interface.ccl. This way the complex logic could be collected in only a single place. This would be useful since we seem to plan to add more new transport operators to Carpet. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1808> 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