Users

users@lists.einsteintoolkit.org

3 participants
3984 discussions

Re: [Users] Meeting Reminder
by Frank Loeffler 06 Dec '10

06 Dec '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/ We will talk about the progress on combining the MHD functions with the original hydro functions, experiences with EOS_Omni and Python Simfactory so far. Of course, as always, feel free to bring up any other topic you feel like we should discuss. Frank

1 0

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

New thorn NoMPI
by Erik Schnetter 03 Dec '10

03 Dec '10

I have just committed a new thorn CactusUtils/NoMPI. This thorn contains a fake MPI implementation for much (but not everything) of MPI's functionality. It provides only a trivial implementation that runs on a single processor. NoMPI can be used to use an MPI code on systems where there is no MPI conveniently available, e.g. on laptops or workstations. To use this thorn, add #include <nompi.h> to your source code, and "uses include header: nompi.h" to the interface.ccl. Thorn NoMPI will automatically switch itself off if a real MPI implementation is found, so that it can be safely used all the time. My main goal was to make Carpet run on such systems, without having to add #ifdefs around each MPI call. Thorn NoMPI is not quite trivial, since certain functionality (e.g. MPI datatypes) still need to be supported. -erik -- Erik Schnetter <schnetter(a)cct.lsu.edu> http://www.cct.lsu.edu/~eschnett/

3 3

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

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Users