Trac

trac@lists.einsteintoolkit.org

8708 discussions

[Einstein Toolkit] #1375: Slab does not fille in outmost layer of points in mesh refinement levels
by Einstein Toolkit 01 Jun '13

01 Jun '13

#1375: Slab does not fille in outmost layer of points in mesh refinement levels -----------------------------------+---------------------------------------- Reporter: rhaas | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: development version Keywords: Slab | -----------------------------------+---------------------------------------- This happens only for mesh refined runs and on reflevel>0 ie in the buffer zones. This happens only if the "useghosts" option is not set (it is unset by default). This behaviour is technically allowed by the docs since Slab only claims to fill in ghost zones and the outermost points are not ghosts but buffer zones (though Carpet disagrees somewhat on that in that it does not count them in buffer_width). Anyhow, this does not to my knowledge actually affect RotatingSymmetryXX which are the most prominent users, at least their poison_boundaries option does not seem to pick this up. To test, run the attached modified slabtest.par test file whcih fails in the identity test for level 1 unless useghosts=1 is used in slabtest.c (and fails int the skip-every-second point test if it is used). -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1375> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 4

[Einstein Toolkit] #1353: GRHydro updates
by Einstein Toolkit 29 May '13

29 May '13

#1353: GRHydro updates -----------------------------------+---------------------------------------- Reporter: rhaas | Owner: Type: enhancement | Status: new Priority: major | Milestone: Component: EinsteinToolkit thorn | Version: Keywords: GRHydro | -----------------------------------+---------------------------------------- this set of patches is need (or at least the MHD ones are) to be able to actually run the runs of the ET MHD paper. So even this late in the game, I'd like to get them into the release if at all possible. There are also a number of bugfixes mostly for the hot eos code. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1353> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 10

[Einstein Toolkit] #1347: simfactory doesn't support --runscript and --submitscript for setup-silent.
by Einstein Toolkit 26 May '13

26 May '13

#1347: simfactory doesn't support --runscript and --submitscript for setup-silent. -------------------------+-------------------------------------------------- Reporter: knarf | Owner: eschnett Type: enhancement | Status: new Priority: minor | Milestone: Component: SimFactory | Version: development version Keywords: | -------------------------+-------------------------------------------------- simfactory doesn't support --runscript and --submitscript for setup- silent. However, it does support --optionlist. The attached patch enables the aforementioned two options, making setup really convenient for a VM. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1347> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 5

[Einstein Toolkit] #1256: scheduling MoL_PostStep in Post_Recover_Variables
by Einstein Toolkit 25 May '13

25 May '13

#1256: scheduling MoL_PostStep in Post_Recover_Variables --------------------+------------------------------------------------------- Reporter: rhaas | Owner: Type: task | Status: new Priority: major | Milestone: Component: Cactus | Version: Keywords: MoL | --------------------+------------------------------------------------------- this is not ideal since some routines in MoL_PostStep will always change results (eg. Con2Prim). We already removed MoL_PostStep from the past timelevels since the prolongation cannot be handled properly. Originally (MoL rev 137, https://trac.einsteintoolkit.org/changeset/137/CactusNumerical/MoL) was introduced to enforce boundary conditions and recompute the ADM variables. Since then the policy has changed and the ADM variables are supposed to be checkpointed (rule of thumb is that anything with more than one timelevels should be checkpointed). When recovering from a checkpoint the boundary conditions are currently satisfied since CarpetIOHDF5 reads in everything that it can, incl. data in ghost and boundary zones. This method ensures that bit identical data is read in. Unfortunately running MoL_PostStep then changes values. It seems as if MoL_PostStep is never required so should not be run. The attached trivial patch adds a parameter to MoL to disable running in Post_Recover_Variables. Note that this is not yet are request for review but a work item since more testing is required to decide if anything breaks when MoL_PostStep is not run. Tests done with GRHydro (and changes so that eg. the atmosphere mask is identical in ghost zones [currently it is not valid in ghost zones but also never checked in ghost zones]) gives bit identical results even when changing the number of processors while recovering. This is a very simple test though. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1256> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 15

[Einstein Toolkit] #1297: Reduce time spent in cycling timelevels if there is only one timelevel.
by Einstein Toolkit 24 May '13

24 May '13

#1297: Reduce time spent in cycling timelevels if there is only one timelevel. --------------------------------------+------------------------------------- Reporter: diener | Owner: eschnett Type: enhancement | Status: new Priority: major | Milestone: Component: Carpet | Version: development version Keywords: performance optimization | --------------------------------------+------------------------------------- I noticed in a run with gridfunctions with only 1 timelevels that a significant amount of time was spent cycling timelevels. The attached patch makes the routine bypass a lot of code, if a grid variable only has 1 timelevel. This reduces the total time spent in cycling timelevels from 417 s to 0.8 s for a run of 32767 iterations. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1297> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 5

[Einstein Toolkit] #705: Activation Order in Parameter Files
by Einstein Toolkit 24 May '13

24 May '13

#705: Activation Order in Parameter Files -------------------------+-------------------------------------------------- Reporter: sbrandt | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Cactus_4.1.0 Component: Cactus | Version: Keywords: | -------------------------+-------------------------------------------------- At the moment the ActiveThorns list is sensitive to the order in which thorns are activated if the ActiveThorns parameter is updated multiple times. However, it is not sensitive to the order in which thorns are activated if all thorns are specified in a single line. This inconsistency should be removed, and the order should not matter in either case. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/705> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 7

[Einstein Toolkit] #1307: Default output directory is '$parfile'
by Einstein Toolkit 24 May '13

24 May '13

#1307: Default output directory is '$parfile' ----------------------+----------------------------------------------------- Reporter: eschnett | Owner: knarf@… Type: defect | Status: new Priority: critical | Milestone: ET_2013_05 Component: Other | Version: Keywords: | ----------------------+----------------------------------------------------- The default output directory is currently '$parfile', but this parameter value is not replaced by the name of the parameter file. It seems that default parameter values are not run through the parser, which would expand "$parfile"? -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1307> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 10

[Einstein Toolkit] #1370: Provide a framework for simulation metadata
by Einstein Toolkit 24 May '13

24 May '13

#1370: Provide a framework for simulation metadata -------------------------+-------------------------------------------------- Reporter: hinder | Owner: Type: enhancement | Status: new Priority: major | Milestone: Component: Cactus | Version: Keywords: | -------------------------+-------------------------------------------------- When writing tools to analysis the output of a Cactus simulation, it would be very useful to have more information than is currently available, and some of the available information could be provided in a more convenient way. For example, users set many parameters, and this provides a good source of information about the simulation, but the parameter file is not always output (e.g. in testsuite data), and it does not contain the value of parameters which are unset, and hence have their default value. Similarly, the value of a parameter is not necessarily a good indicator of what actually happened. Often, a group of parameters needs to be interpreted together to determine the required quantity. For example, if I want to know what the intended final time of the simulation was, I would have to look at Cactus::terminate, Cactus::cctk_itlast and Cactus::cctk_final_time. If I want to know what the timestep or grid spacing on the coarsest grid is, I have to look at a similar set of parameters, or parse a grid structure file from Carpet for which there is no well-defined filename. If I want to know what the last iteration actually was, I have to find an output file and look at it, and there might not even be any appropriate files, depending on the user's choices. I propose that Cactus provides a framework for simulation metadata. The following is one possible way that it could work. 1. Metadata for the simulation is collected and output to disk 2. The metadata comes from both the flesh and from thorns 3. The metadata format is extensible 4. The metadata format is easy to parse (hence, it is in a standard well- specified and commonly-supported format) 5. The metadata file is easily human-readable 6. The metadata file is always output, so that analysis tools can expect that it is present in modern simulations 7. The metadata file is not too large 8. The framework for metadata is managed by the flesh, as it is important and will be available for every Cactus simulation 9. One possible format for the metadata file is the "ini" file format, as used by SimFactory. This satisfies 3, 4 and 5 above. 10. There would be one section per implementation active in the simulation, and one for the flesh. 11. Each thorn is responsible for determining what metadata keys should be output. 12. The flesh will output essential characteristics of the simulation that is knows about, e.g. start and end iteration and times, run title, etc. 13. Output thorns will output the names of output files, and a description of what they contain. 14. Some metadata will be available at startup, some at termination, and some will become available only periodically. For example, due to parameter steering, the set of available output files might get larger during the simulation. We could either handle this by parsing and rewriting the metadata file to insert extra information into existing sections, or allow sections to be repeated. We have a parsing framework in the flesh now (Piraha), so this should be straightforward. 15. Metadata files will be modified safely (e.g. by writing a new one to a temporary file and moving it over the old one) 16. A distinction will be made between metadata items and parameters. Often, there will be a 1-1 correspondence between these. As a result, it would be good to have a convenient way for thorn authors to easily mark parameters as suitable for direct inclusion in the metadata file. For example, marking a parameter with a keyword "metadata = yes" or equivalent in the param.ccl file would cause a metadata key for this parameter to be automatically included in the metadata file. 17. Information which can change during a simulation might not be a good candidate for metadata; maybe then it becomes "data" and should be output in a separate file (pointed to by a metadata entry, of course). In that case, setting "steerable" and "metadata" for a parameter in param.ccl should lead to an error. 18. Metadata entries could be restricted to string values, or could have richer types. Richer types such as strings, integers, floating point numbers, and lists (possibly with nesting) might be convenient. 19. The flesh could provide a function CCTK_RecordMetadata(key, value) [surely the implementation does not need to be told to the flesh by the caller?]. This function would store the data in a flesh data structure, and note whether the on-disk file needed to be updated. 20. Every iteration, the flesh (on the first process) would update the on- disk metadata file if it needed to be changed. 21. The sections in the metadata file will correspond to implementations, and multiple thorns providing the same implementation [who chose this name?] if providing the same information should provide it using the same key names. Related: * An example of this sort of idea is already implemented by TwoPunctures (#551), which outputs a TwoPunctures.bbh metadata file in the "numerical relativity data format". * The thorn Formaline currently handles a limited amount of metadata, but the scope is more limited than this ticket. The above proposal could be implemented using Formaline, but then you could not always expect that the metadata file is available as Formaline might not have been activated. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1370> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 0

[Einstein Toolkit] #526: Reorder ticket states
by Einstein Toolkit 23 May '13

23 May '13

#526: Reorder ticket states ----------------------------------+----------------------------------------- Reporter: eschnett | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: EinsteinToolkit trac | Version: Keywords: | ----------------------------------+----------------------------------------- The order in which the ticket states is displayed (in the form where one modifies the ticket state) should be the natural order in which a ticket progresses. The current order is somewhat random. I suggest this order: new confirmed accept reassign review resolve -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/526> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 1

[Einstein Toolkit] #519: Add all ET repositories to TRAC
by Einstein Toolkit 23 May '13

23 May '13

#519: Add all ET repositories to TRAC ----------------------------------+----------------------------------------- Reporter: hinder | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: EinsteinToolkit trac | Version: Keywords: | ----------------------------------+----------------------------------------- TRAC provides integration with version control systems. It has a list of repositories, and specific changesets and files can be referred to in ticket comments and wiki pages using a convenient syntax. Several ET repositories have been added already. I think this feature is useful, and that the remaining repositories should be added. It would be nice if the links were easier to type. I propose omitting the arrangement name from the repositories, as all thorn names are probably unique, and avoiding spaces which require extra quoting. We have several repositories in Git and Mercurial. It would be nice to include those as well. I believe that there are TRAC plugins to accomplish this in the same way as for SVN. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/519> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 4

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac