Users November 2010

users@lists.einsteintoolkit.org

14 participants
37 discussions

Meeting minutes
by Roland Haas 06 Dec '10

06 Dec '10

Meeting minutes: Present were: Tanja, Roland, Frank, Erik, Bruno, Josh, Ian, Peter, Eloisa - GRHydro coordination (EOS/MHD) will merge "easy" MHD and HD functions (things other than con2prim/prim2con) - EOS_Omni and other EOS interfaces request users to update their thorns/parameter files to use EOS_Omni since EOS_Base support will go away - Define goals for next release and make them priority: - hg Carpet ? needs some work on the mask (weights) which is currently wrong in concave corners - Python Simfactory ? will be included - per-variable tolerances for Cactus testsuites ? * separate tests into regression tests (specific to each machine) and correctness tests * automate regression tests and run at set intervals rather then only before releases * (some minutes are missing since we had a fire alarm, please feel free to fill these in) - use OpenMP for testsuites will be used in the future - create testsuites using McLachlan from BSSN_MoL testsuites Peter will look into this (but it will take a while) Yours, Roland -- My email is as private as my paper mail. I therefore support encrypting and signing email messages. Get my PGP key from http://keys.gnupg.net.

2 1

Optional capabilities
by Ian Hinder 30 Nov '10

30 Nov '10

Hi, (Sent to Einstein Toolkit mailing list because Cactus mailing lists are down) I am trying to introduce an optional dependency on HDF5 in my thorn. The idea is that the thorn could work either with or without HDF5 support in the configuration, and the code in the thorn would be conditionally compiled depending on whether HDF5 is present. The Cactus capability mechanism has an "optional" keyword, so you can say that a thorn depends optionally on a particular capability (in this case, HDF5). However, in the Einstein Toolkit thorns, this is very rarely used, and never for conditional compilation, so I suspect that this feature has not been well tested. Indeed, it appears that it doesn't work. In order to detect at compile time whether a given capability is present, it is necessary to have a preprocessor (#define) macro defined. The file that would do this is Cactus/lib/sbin/CreateConfigurationBindings.pl. This file sets a make-system definition for the given capability (i.e. HDF5 = 1) but it does not set a preprocessor macro. This could be done manually in the configuration script of the thorn providing the capability, by outputting the lines echo "BEGIN DEFINE" echo "HAVE_HDF5 1" echo "END DEFINE" This would cause the line "#define HAVE_HDF5 1" to be included whenever the thorn that requires the capability includes cctki_Capabilities.h. However, since this is a "cctki" file (with 'i' for internal?), I assume that it is not supposed to be included by user thorns. Instead, I think it is supposed to be included automatically, but I can't find any code that would do that, and I think it is missing. Further, there is a line in CreateConfigurationBindings.pl which seems to be wrong. Line 166 says $incs .= "#define " . $cfg->{"\U$thorn\E OPTIONAL \U$providedcap\E DEFINE"} . " 1\n"; which doesn't make sense because $cfg->{"\U$thorn\E OPTIONAL \U$providedcap\E DEFINE"} is a list of defines, not a single one, and anyway these definitions have already been provided earlier in the file which will be included, so this line is redundant. It leads to the output #define 1, presumably because the list evaluates to an empty string. This causes a compilation failure when you include cctki_Capabilities.h. 1. Do we want all capabilities to generate automatically a preprocessor macro which can be checked? e.g. HAVE_CAPABILITY_HDF5, (to avoid conflicts with autoconf-generated macros) 2. If not, then we could add the BEGIN_DEFINE...END_DEFINE lines above to HDF5.sh to manually set the define. 3. I think line 166 of CreateConfigurationBindings.pl should be removed. 4. There should be some mechanism for each thorn to include cctki_Capabilities.h automatically. -- Ian Hinder ian.hinder(a)aei.mpg.de

2 6

Meeting Reminder
by Frank Loeffler 29 Nov '10

29 Nov '10

Hi, This is a reminder about our usual Monday Einstein Toolkit phone call. As usual, you can find instructions how to join on the following web site: http://einsteintoolkit.org/info/support/ With the release out of the way the discussion will mostly, if not entirely, be about what do to next within the development version. This includes: - GRHydro coordination (EOS/MHD) - EOS_Omni and other EOS interfaces - Define goals for next release and make them priority: - hg Carpet ? - Python Simfactory ? - per-variable tolerances for Cactus testsuites ? - use OpenMP for testsuites - create testsuites using McLachlan from BSSN_MoL testsuites Frank

1 0

CRL syntax highlighting for TextMate
by Eric Seidel 27 Nov '10

27 Nov '10

Hi all, I just put together a simple syntax highlighting bundle for the Component Retrieval Language (the thornlists use this) in TextMate. If anyone else uses TextMate, please grab the bundle from the GetComponents repository on GitHub <https://github.com/gridaphobe/GetComponents>. Currently it recognizes comments, directives, and $ variables. Eric

1 0

[knarf@cct.lsu.edu: Temporary cactuscode domain names]
by Frank Loeffler 27 Nov '10

27 Nov '10

----- Forwarded message from Frank Loeffler <knarf(a)cct.lsu.edu> ----- To: users(a)cactuscode.org Hi, IT-support has informed us that it is very likely that the current status will _at best_ be resolved on the coming Monday. The current status is: the cactuscode.org domain got registered by someone else, and is now pointing to someplace else. Subdomains like svn.cactuscode.org do not seem to exist and would probably also not point to the 'right' place. We don't yet know why this happend, and who to blame. In addition, Murphy struck on one of the worst days of the year: the Friday of the long thanksgiving weekend. Work has to continue, so I registered some temporary domain names which now point to the two most important places, the web pages and the repositories: http://cactuscode.dyndns.org http://svn-cactuscode.dyndns.org The web pages will be updated with future status changes of this issue. One important piece of our infrastructure is not yet up and running at the moment: the mailing lists. Due to their complexity I don't think it is likely that there will be a temporary redirect or similar. In the meantime, feel free to join the Cactus IRC channel: #cactus on irc.oftc.net archive: https://svn-cactuscode.dyndns.org/irc-logs/ longer description of IRC: http://einsteintoolkit.org/info/support/ We are sorry for the inconvenience, Frank Loeffler for the Cactus team. _______________________________________________ Users mailing list Users(a)cactuscode.org http://cactuscode.org/mailman/listinfo/users ----- End forwarded message -----

1 0

GRHydro changes to be merged into trunk
by Christian D. Ott 25 Nov '10

25 Nov '10

Hi All, later today, we will merge the current development branch with the trunk branch of GRHydro. Major changes: * GRHydro now knows about electron fraction and temperature and can handle finite-temperature EOS. In order to use this feature, you have to set: hydrobase::temperature_evolution_method = "GRHydro" and hydrobase::y_e_evolution_method = "GRHydro". In addition, you'll of course need a hot EOS (see below) and appropriate initial data. * GRHydro now uses EOS_Omni. The EOS_Base dependence has been removed. You will need to change your parameter files and activate EOS_Omni which will be moved to the EinsteinEOS arrangement today. Example parameters for a TOV NS evolution are: eos_omni::poly_gamma = 2.0 eos_omni::poly_gamma_ini = 2.0 eos_omni::poly_k = 100.0 eos_omni::gl_gamma = 2.0 eos_omni::gl_k = 2.0 EOS_Omni currently supports a polytropic EOS, a gamma-law EOS (this is what we used to call "ideal fluid" EOS), a hybrid EOS (a hot 2-piece polytrope), and nuc_eos, which can handle hot tabulated EOS. Tables for the latter can be obtained from http://www.stellarcollapse.org/microphysics. This currently works well for core collapse, but has not been tried for NS evolutions. When using the nuc_eos routines, please make reference to http://iopscience.iop.org/0264-9381/27/11/114103 . * GRHydro currently still supports the second legacy EOS interface "EOSG_Base", but this support will be removed soon to simplify the code. Please let me and Frank Loeffler know if you have any concerns about the above. Best, - Christian Ott for the Einstein Toolkit maintainers.

1 1

hdf5 error
by Hee Il Kim 24 Nov '10

24 Nov '10

Hi, Recently I've encountered the hdf error. It didn't happen on all my machines but at least I saw this on QueenBee. I'm using the latest development version of EinsteinToolkit. I attached below my hdf5 parameter setup, stderr, and stdout. Thanks in advance, Hee Il # IOHDF5 IOHDF5::out_every = 128 iohdf5::out_dir = "h5" iohdf5::compression_level = 9 IOHDF5::output_symmetry_points = no IOHDF5::out3D_ghosts = no IOHDF5::out_vars = " hydrobase::rho{ downsample={4 4 4} } weylscal4::psi4r{ downsample={4 4 4} } weylscal4::psi4i{ downsample={4 4 4} } " IO::out_unchunked = "yes" IO::out_mode = "onefile" ### stderr ### ... HDF5-DIAG: Error detected in HDF5 (1.8.5-patch1) thread 0: #000: H5Dio.c line 266 in H5Dwrite(): can't write data major: Dataset minor: Write failed #001: H5Dio.c line 578 in H5D_write(): can't write data major: Dataset minor: Write failed #002: H5Dcontig.c line 557 in H5D_contig_write(): contiguous write failed major: Dataset minor: Write failed ### stdout ### WARNING[L1,P0] (CarpetIOHDF5): HDF5 call 'H5Dwrite (memdataset, memdatatype, overlap_dataspace, dataspace, H5P_DEFAULT, data)' returned error code -1 WARNING[L1,P0] (CarpetIOHDF5): HDF5 call 'H5Dwrite (memdataset, memdatatype, overlap_dataspace, dataspace, H5P_DEFAULT, data)' returned error code -1 WARNING[L1,P0] (CarpetIOHDF5): HDF5 call 'H5Dwrite (memdataset, memdatatype, overlap_dataspace, dataspace, H5P_DEFAULT, data)' returned error code -1

2 2

Web page listing presentations/publications?
by Erik Schnetter 23 Nov '10

23 Nov '10

I gave two presentations introducing the Einstein Toolkit and would like to make them available on the ET web site. Do we already have a place for these? If no, I suggest to add a new sidebar item between "Capabilities" and "Mail Lists" called "Publications", and list them there, including pointers to the pdfs. We can also begin to collect there references to papers acknowledging the ET. -erik -- Erik Schnetter <schnetter(a)cct.lsu.edu> http://www.cct.lsu.edu/~eschnett/

1 0

4th order finite differencing in Exact
by Erik Schnetter 23 Nov '10

23 Nov '10

I have just committed the patch that implements 4th order finite differencing in Exact. Thorn Exact uses finite differencing to calculate the extrinsic curvature. This feature (which is disabled by default) can lead to a much more accurate extrinsic curvature. We can now think about enabling this by default; at the moment I cannot see any ill effect from this. -erik -- Erik Schnetter <schnetter(a)cct.lsu.edu> http://www.cct.lsu.edu/~eschnett/

1 0

ReflectionSymmetry, tensor tags, ML_BSSN, etc.
by John Baker 23 Nov '10

23 Nov '10

Hi, We've run into some problems recently with our evolution code, which boil done to the fact that we'd developed the code to support the sort of reflection symmetry defined in cartgrid3d, but recently started working with other thorns which are expecting the use of ReflectionSymmetry to define reflection symmetries. I assume that the motivation for this transition was to support more general grids, multipatch codes, etc, but I haven't found any documentation for the ReflectionSymmetry thorn, or any explanation of its use. One likely problem we are having is that we haven't applied any tensor-related tags in our interface.ccl, and rumor has it around here that ReflectionSymmetry relies on these tags. Presumably there are other EinsteinToolkit thorns which rely on tensor tags as well. I did find one document giving some explanation of tensor tags http://cactuscode.org/documentation/CoreDoc.pdf (thanks Erik). Erik outlines a number of potential tags there, but I would like to know which of these are required to support interaction which the various thorns in the toolkit? Looking at various other interface.ccl files, there didn't seem to be a high degree of consistency about which tags are set. Some also naively appear to be set incorrectly, in ML_BSSN. For instance: CCTK_REAL ML_trace_curv type=GF timelevels=3 tags='tensortypealias="Scalar" tensorweight=1.0000000000000000000' { trK } "ML_trace_curv" Which seems to declare the trK to be a tensor density. If this is indeed wrong, and no one has noticed, then I infer that tensorweight may not really be used by anything important. If anyone can clarify these issues for me I would appreciate it. Thanks, John.

3 5

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Users November 2010