Users

users@lists.einsteintoolkit.org

3 participants
3984 discussions

Carpet version of cctk_bbox?
by Scott Hawley 09 Apr '12

09 Apr '12

Erik et al, For my elliptic solver, I need to know not only if a given grid boundary is an outer boundary or not, I need to know if it's an inter-processor boundary or a mesh refinement boundary. cctk_bbox does not provide the latter distinction. Is there something analogous provided by Carpet? Thanks, -Scott

3 3

Illinois Contribution to ET: Staggered Prolongation/Restriction
by Zach Etienne 06 Apr '12

06 Apr '12

Dear ET folks, Our branch of Carpet, which includes the prolongation/restriction operators we developed for staggered gridfunctions, has been made publicly available. You can download it here: http://webusers.physics.illinois.edu/~vpaschal/UIUC_CARPET/ The license to our modifications and contributions is GPL, chosen to maximize compatibility with the rest of the Carpet code licensing. Though we do not intend to merge these changes into the Carpet mainline, you are more than welcome to do so. Sincerely, Zachariah Etienne Yuk Tung Liu Vasilis Paschalidis Stuart L. Shapiro

4 4

Where is thorn ADMMass now?
by Scott Hawley 05 Apr '12

05 Apr '12

Hi, I know there's an old copy of the thorn ADMMass in the AEIThorns arrangement. Where is the latest version of this thorn? I haven't found it in the various Einstein Toolkit arrangements, or in CactusEinstein….. Thanks

4 3

using multigrid levels
by Scott Hawley 04 Apr '12

04 Apr '12

From "Carpet Under the Hood": "For historic reasons it also has a notion of multigrid levels, but those are currently unused. They might conceivably be reactivated to form multigrid stacks to solve elliptic equations." Yes, please. How soon?

2 2

Re: [Users] gcc-4.7 compile errors
by Erik Schnetter 04 Apr '12

04 Apr '12

Vassilios Thank you for pointing this out! Since gcc 4.7 is relatively new, I recommend using the -fpermissive flag until the next release. I have already a correction for this problem, and will apply it to the development version soon. -erik On Wed, Apr 4, 2012 at 5:19 AM, Vassilios Mewes <vassilios.mewes(a)uv.es> wrote: > Hello Dr. Schnetter, > > i tried to post the following below as a new ticket on the einstein toolkit > trac webiste, but it gets rejected as potential spam everytime...its a about > a compile error with the new gcc-4.7... > > the error disappears when using the -fpermissive flag, but i red that this > is in general not advisable... > > best wishes, > > Vassili > > > Hello! > > when i try to build the einstein toolkit (maxwell release) with the new > gcc4.7 on a iMac running OS X Lion 10.7.3, there are build errors in the > file ioascii.cc, which i think is related to the following changes in gcc: > '' > G++ now correctly implements the two-phase lookup rules such that an > unqualified name used in a template must have an appropriate declaration > found either in scope at the point of definition of the template or by > argument-dependent lookup at the point of instantiation. As a result, code > that relies on a second unqualified lookup at the point of instantiation to > find functions declared after the template or in dependent bases will be > rejected. The compiler will suggest ways to fix affected code, and using the > -fpermissive compiler flag will allow the code to compile with a warning. > template <class T> > void f() { g(T()); } // error, g(int) not found by argument-dependent lookup > void g(int) { } // fix by moving this declaration before the declaration of > f > > template <class T> > struct A: T { > // error, B::g(B) not found by argument-dependent lookup > void f() { g(T()); } // fix by using this->g or A::g > }; > > struct B { void g(B); }; > > int main() > { > f<int>(); > A<B>().f(); > }'' > > the following error messages are generated by gcc4.7 upon compiling: > > /Users/vass/programs/Cactus/arrangements/Carpet/CarpetIOASCII/src/ioascii.cc: > In instantiation of ‘static void > CarpetIOASCII::IOASCII<outdim>::OutputDirection(const cGH*, int, > std::string, std::string, const vect<int, D>&, bool, bool) [with int outdim > = 0; cGH = _cGH; std::string = std::basic_string<char>]’: > /Users/vass/programs/Cactus/arrangements/Carpet/CarpetIOASCII/src/ioascii.cc:1483:18: > required from here > /Users/vass/programs/Cactus/arrangements/Carpet/CarpetIOASCII/src/ioascii.cc:642:15: > error: ‘WriteASCII’ was not declared in this scope, and no declarations were > found by argument-dependent lookup at the point of instantiation > [-fpermissive] > /Users/vass/programs/Cactus/arrangements/Carpet/CarpetIOASCII/src/ioascii.cc:1271:8: > note: ‘template<int outdim> void CarpetIOASCII::WriteASCII(std::ostream&, > std::vector<gdata*>, const bbox<int, 3>&, int, int, const vect<int, 3>&, > const vect<int, D>&, int, int, int, int, int, double, const vect<double, > 3>&, const vect<double, 3>&)’ declared here, later in the translation unit > /Users/vass/programs/Cactus/arrangements/Carpet/CarpetIOASCII/src/ioascii.cc: > In instantiation of ‘static void > CarpetIOASCII::IOASCII<outdim>::OutputDirection(const cGH*, int, > std::string, std::string, const vect<int, D>&, bool, bool) [with int outdim > = 1; cGH = _cGH; std::string = std::basic_string<char>]’: > /Users/vass/programs/Cactus/arrangements/Carpet/CarpetIOASCII/src/ioascii.cc:1484:18: > required from here > /Users/vass/programs/Cactus/arrangements/Carpet/CarpetIOASCII/src/ioascii.cc:642:15: > error: ‘WriteASCII’ was not declared in this scope, and no declarations were > found by argument-dependent lookup at the point of instantiation > [-fpermissive] > /Users/vass/programs/Cactus/arrangements/Carpet/CarpetIOASCII/src/ioascii.cc:1271:8: > note: ‘template<int outdim> void CarpetIOASCII::WriteASCII(std::ostream&, > std::vector<gdata*>, const bbox<int, 3>&, int, int, const vect<int, 3>&, > const vect<int, D>&, int, int, int, int, int, double, const vect<double, > 3>&, const vect<double, 3>&)’ declared here, later in the translation unit > /Users/vass/programs/Cactus/arrangements/Carpet/CarpetIOASCII/src/ioascii.cc: > In instantiation of ‘static void > CarpetIOASCII::IOASCII<outdim>::OutputDirection(const cGH*, int, > std::string, std::string, const vect<int, D>&, bool, bool) [with int outdim > = 2; cGH = _cGH; std::string = std::basic_string<char>]’: > /Users/vass/programs/Cactus/arrangements/Carpet/CarpetIOASCII/src/ioascii.cc:1485:18: > required from here > /Users/vass/programs/Cactus/arrangements/Carpet/CarpetIOASCII/src/ioascii.cc:642:15: > error: ‘WriteASCII’ was not declared in this scope, and no declarations were > found by argument-dependent lookup at the point of instantiation > [-fpermissive] > /Users/vass/programs/Cactus/arrangements/Carpet/CarpetIOASCII/src/ioascii.cc:1271:8: > note: ‘template<int outdim> void CarpetIOASCII::WriteASCII(std::ostream&, > std::vector<gdata*>, const bbox<int, 3>&, int, int, const vect<int, 3>&, > const vect<int, D>&, int, int, int, int, int, double, const vect<double, > 3>&, const vect<double, 3>&)’ declared here, later in the translation unit > /Users/vass/programs/Cactus/arrangements/Carpet/CarpetIOASCII/src/ioascii.cc: > In instantiation of ‘static void > CarpetIOASCII::IOASCII<outdim>::OutputDirection(const cGH*, int, > std::string, std::string, const vect<int, D>&, bool, bool) [with int outdim > = 3; cGH = _cGH; std::string = std::basic_string<char>]’: > /Users/vass/programs/Cactus/arrangements/Carpet/CarpetIOASCII/src/ioascii.cc:1486:18: > required from here > /Users/vass/programs/Cactus/arrangements/Carpet/CarpetIOASCII/src/ioascii.cc:642:15: > error: ‘WriteASCII’ was not declared in this scope, and no declarations were > found by argument-dependent lookup at the point of instantiation > [-fpermissive] > /Users/vass/programs/Cactus/arrangements/Carpet/CarpetIOASCII/src/ioascii.cc:1271:8: > note: ‘template<int outdim> void CarpetIOASCII::WriteASCII(std::ostream&, > std::vector<gdata*>, const bbox<int, 3>&, int, int, const vect<int, 3>&, > const vect<int, D>&, int, int, int, int, int, double, const vect<double, > 3>&, const vect<double, 3>&)’ declared here, later in the translation unit > make[3]: *** [ioascii.cc.o] Error 1 > make[2]: *** [make.checked] Error 2 > make[1]: *** > [/Users/vass/programs/Cactus/configs/BHWinTest/lib/libthorn_CarpetIOASCII.a] > Error 2 > make: *** [BHWinTest] Error 2 -- Erik Schnetter <schnetter(a)cct.lsu.edu> http://www.perimeterinstitute.ca/personal/eschnetter/

1 0

McLachlan updated
by Erik Schnetter 03 Apr '12

03 Apr '12

Dear users of the development version of McLachlan: I have just re-generated the McLachlan code via Kranc. If you update your checkout of McLachlan, you will likely also have to update the Cactus flesh, LSUThorns/Vectors, and Kranc's GenericFD thorn. If you don't update all these, you may encounter either CST errors or compiler errors. As usual, updating everything in the Einstein Toolkit should be a safe thing to do (as safe as development branches are). There are no new features in McLachlan. However, we cleaned up thorn LSUThorns/Vectors, moving some of the code into Kranc, and added new functionality to the flesh that Kranc now generates. -erik -- Erik Schnetter <schnetter(a)cct.lsu.edu> http://www.perimeterinstitute.ca/personal/eschnetter/

1 0

Can't evolve Minkowski with RK4 integrator?
by Erik Schnetter 03 Apr '12

03 Apr '12

I've just encountered a strange problem: I can't evolve Minkowski with MoL's RK4 integrator. Small errors in K grow from floating-point round-off, and the simulation quickly goes bad. The error grows slowly (but measurably) in unigrid, but much faster with mesh refinement. For example, with unigrid the lapse grows by about 10^-15 every ten time steps or so; with mesh refinement, the simulation dies after a few ten time steps. However, things are fine with other time integrators, in particular with the generic RK1 and RK4 integrators. I've looked at other things as well, e.g. the CFL factor, the McLachlan implementation, the gauge parameters, dissipation, but could not find anything else that made a difference. Is there something bad about the RK4 integrator? Is it intrinsically unstable, more so than other RK schemes? Or did it break in some of the recent changes? -erik -- Erik Schnetter <schnetter(a)cct.lsu.edu> http://www.perimeterinstitute.ca/personal/eschnetter/

6 7

simfactory: bad links
by Scott Hawley 02 Apr '12

02 Apr '12

I'm trying to do my "homework" before the workshop… http://simfactory.org/about/ Blank page http://simfactory.org/info/ -> 2.0 Python Tutorial -> https://docs.einsteintoolkit.org/et-docs/Pysim_Tutorial_for_New_Users "THIS PAGE IS OUTDATED" …Where is the link to the non-outdated page?

2 1

_No_ Einstein Toolkit Meeting
by Frank Loeffler 01 Apr '12

01 Apr '12

Dear Einstein Toolkit user This is a reminder that there will be no Einstein Toolkit phone call on April 2nd (and this is no April fools joke). We will resume the usual schedule on Monday April 16th. Of course, questions are as always welcome on the mailing list; so don't hesitate to report problems or request help. Frank Loeffler

1 0

Re: [Users] cactus simulation build
by Steven R. Brandt 01 Apr '12

01 Apr '12

I agree with Shantenu, you shouldn't have to debug these issues. Just send them to the list where there are a lot of people who can provide answers. In this particular case, I think the error message is badly formatted. The command wants to be issued from inside the Cactus directory. It looks like there used to be a more useful error message in simlib.py in the GetDirSuffix routine, but it was commented out. I'm not sure why. Should we put it back? Cheers, Steve On 03/28/2012 10:49 PM, Sharath Maddineni wrote: > Hello Dr. Steve, > > the cactus simulation build is so flaky/inconsistant > > please see the following commands. This does not make senese at all to > me. I have spending lot of time debugging these kind of issues. Other > than these minor issues running/steps > from there DARE part is done. been encountering these issues all along. > > cactus build exists and when I create some times it does creates and > some times it does not. Please let me know if I am doing anything wrong > /[smaddi2@qb1 einsteintoolkit_build]$ > /work/smaddi2/agent/einsteintoolkit_build/Cactus/simfactory/bin/sim > --parfile=/work/smaddi2/agent/einsteintoolkit_build/Cactus/par/static_tov.par > create --configuration sim static1/ > /Parameter file: > /work/smaddi2/agent/einsteintoolkit_build/Cactus/par/static_tov.par/ > /Skeleton Created/ > /Job directory: "/work/smaddi2/simulations/static1"/ > /Error: Given sourcebasedir > '/work/smaddi2/agent/einsteintoolkit_build' does not contain a Cactus > directory/ > /Aborting Simfactory./ > /[smaddi2@qb1 einsteintoolkit_build]$ ls/ > /Cactuscactus_installer.py einsteintoolkit.th > <http://einsteintoolkit.th> GetComponentsGetComponents.1 > GetComponents.2 GetComponents.3/ > /[smaddi2@qb1 einsteintoolkit_build]$ pwd/ > //work/smaddi2/agent/einsteintoolkit_build/ > /[smaddi2@qb1 einsteintoolkit_build]$ ls Cactus/exe// > /cactus_sim sim/ > > please let me know if I am doing anything wrong. > > Sharath

3 2

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Users