Users

users@lists.einsteintoolkit.org

3 participants
3984 discussions

Start a nNew thread

Einstein Toolkit Meeting Reminder
by Frank Loeffler 24 Mar '14

24 Mar '14

1 0

Re: [Users] [Commits] [ianhinder/Kranc] 1fbc89: Use 4th order DG elements
by Frank Loeffler 19 Mar '14

19 Mar '14

On Tue, Mar 18, 2014 at 01:33:36PM -0700, Erik Schnetter wrote: > > Changed paths: > M Tools/CodeGen/DGFE.m > > Log Message: > ----------- > Use 4th order DG elements I am not sure how (didn't investigate), but this commit and the corresponding updates to McLachlan started to break the automated tests. See https://build.barrywardell.net/job/EinsteinToolkit/1144/ e.g.: In file included from /home/jenkins/workspace/EinsteinToolkit/arrangements/McLachlan/ML_ADMConstraints/src/Kranc.cc:33:0: /home/jenkins/workspace/EinsteinToolkit/arrangements/McLachlan/ML_ADMConstraints/src/Kranc.hh:10:29: error: ‘namespace ML_ADMConstraints { }’ redeclared as different kind of symbol Frank

3 4

Einstein Toolkit Meeting Reminder
by Frank Loeffler 17 Mar '14

17 Mar '14

Hi Please consider joining the weekly Einstein Toolkit phone call at 10 am US central time on Mondays. As usual, you can find instructions how to join on the following web site: http://einsteintoolkit.org/community/support/ In short: the number is (+1) 225-578-4942 or (+1) 866-573-0359 and the conference id is 118682#. We will mention changes to GRHydro that started to be moved from Zelmani to the main development repository, and will continue to be moved next week (see https://trac.einsteintoolkit.org/ticket/1531). We will *not* go over these patches one-by-one during the call though if not requested. Just see it as announcement of major code changes (although not a lot would change for a user). Also, more and more machine configurations move to the Intel 14 compiler, not so much because "it is the most recent", but mainly because version 13 has at least one serious bug which requires a workaround that affects performance negatively (disabling 'restrict'). Version 14 seems to have this fixed, and I would like to hear different stories if there are some. Thorn TestMoL was suggested to enter the ET (https://trac.einsteintoolkit.org/ticket/1557). Erik reviewed it as ok, but we should still give it its official 'ok'. Frank

2 1

Meudon_Mag_NS with rotating stars
by Michael Jasiulek 14 Mar '14

14 Mar '14

Hi, I have been trying to import and evolve Lorene data using EinsteinInitialData/Meudon_Mag_NS and the parfile Cactus/par/static_tov.par as a basis. I managed to evolve the example file Meudon_Mag_NS/data/bbig.d for a non rotating magnetised neutron star, as well as the non-rotating non-magnetised Lorene resu.d I created. As soon as I turn on rotation I get nans in all variables from the beginning of the evolution and the warning from GRHydro "Infinite Lorentz factor reset. rho, w_tmp:". Has anyone tried to use Meudon_Mag_NS with rotating Lorene initial data? Thanks, Michael

2 1

No Einstein Toolkit Meeting
by Frank Loeffler 09 Mar '14

09 Mar '14

Hi There won't be an Einstein Toolkit call tomorrow. Too many people will not be available. The next Einstein Toolkit call will happen next week Monday, at the usual time. Frank Loeffler

1 0

Formaline reigned in
by Erik Schnetter 28 Feb '14

28 Feb '14

As noticed by several users, thorn Formaline had slightly wrong dependencies that would lead to unnecessarily rebuilding all its tarballs under certain circumstances (e.g. when the thorn list changes). I was able to identify the cause, and learned about "order-only prerequisites" in GNU make along the way <http://www.gnu.org/software/make/manual/html_node/Prerequisite-Types.html>. This dependency error is now corrected, and Formaline should now rebuild its tarballs only when necessary. -erik -- Erik Schnetter <schnetter(a)cct.lsu.edu> http://www.perimeterinstitute.ca/personal/eschnetter/ My email is as private as my paper mail. I therefore support encrypting and signing email messages. Get my PGP key from http://pgp.mit.edu/.

1 0

Einstein Toolkit Meeting Reminder
by Frank Loeffler 28 Feb '14

28 Feb '14

1 0

Re: [Users] Building on Mac OS
by David Radice 27 Feb '14

27 Feb '14

On Feb 10, 2014, at 8:51 AM, David Radice <david.e.pi.3.14(a)gmail.com> wrote: > Hi Ian, > > On Feb 10, 2014, at 3:42 AM, Ian Hinder <ian.hinder(a)aei.mpg.de> wrote: > >> Has anybody run into this before? If not, then I can attempt to dig into the configure script and find out why it's not detecting openmpi from macports anymore. > > yes I ran into this problem. > > The reason why the MPI thorn does not find the OpenMPI from MacPorts is that MacPorts recently changed the way in which MPI is installed. They wanted to support the simultaneous installation of multiple OpenMPI versions compiled with different compilers, so they decided to move all the header files and libraries of OpenMPI to some nonstandard locations where the MPI thorn does not find them. If I am not mistaken the new paths look like these: > > the headers in ${PREFIX}/include/${OMPI_VERSION} , > the libraries in ${PREFIX}/lib/${OMP_VERSION} . > > The default MPI wrappers have also been renamed as ${OMPI_VERSION}-${NAME}. The new port "mpi select" can create aliases for those, but since ET does not use the MPI wrappers to compile, this does not help very much. > > Possible solutions would be to either compile with the MPI wrappers, change to option list to explicitly set MPI_INC_DIR and MPI_LIB_DIRS, or manually compile OpenMPI and point the MPI thorn to it. I would recommend the last of these options, because I am not sure that OpenMPI is compiled correctly by MacPorts: it used to be the case that OpenMPI was compiled with a mix of clang (for the C part) and gcc (for the Fortran code), which resulted in some very weird behavior when running with OpenMPI and OpenMP, and I am not sure that the new "gcc versions" of OpenMPI are actually compiled with gcc or if they simply use gcc as the default target for the wrapper scripts. > > Cheers, > David

3 2

Einstein Toolkit Meeting Reminder
by Frank Loeffler 21 Feb '14

21 Feb '14

1 0

Updating MoL's LinearCombination to support AMR
by Erik Schnetter 18 Feb '14

18 Feb '14

I would like to support MoL's LinearCombination operator, which is also used to perform time integration on accelerators, to pass an additional argument "refinement level". This will help make it possible to run AMR simulations on accelerators (GPUs). This change is essentially a backport from the respective feature branch. If not using accelerators, this change affects only MoL. One of the main drivers for this change is to fold the CaKernel branch back into mainline. Do you agree with such experimental changes to MoL? -erik -- Erik Schnetter <schnetter(a)cct.lsu.edu> http://www.perimeterinstitute.ca/personal/eschnetter/ My email is as private as my paper mail. I therefore support encrypting and signing email messages. Get my PGP key from http://pgp.mit.edu/.

2 2

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Users