Users April 2012

users@lists.einsteintoolkit.org

21 participants
31 discussions

Carpet innards: restriction usage...
by Scott Hawley 10 Apr '12

10 Apr '12

Something like this? /*=========================================================================== BrusierRestrict The way this routine should work: Pass in the values of the fine level and the course level, Pass in the grid hierarchy and a grid function or set of grid functions Call the half-weighted restriction operator(s) for said grid functions(s) For any coarse grid points adjacent to inner boundary points, replace these points with injected/"straight copy" data from the fine grid Note: currently calling ref_restric_all, but I don't really want to restrict "all" grid functions. Just some of them... Much of this routine was "lifted" from LSUDevelopment/Refluxing/src/correct.cc ===========================================================================*/ namespace variables { char const * restrict const soln[] = { "BruiserConstraints::phi", "BruiserConstraints::wx", "BruiserConstraints::wy", "BruiserConstraints::wz", NULL }; char const * restrict const rhs[] = { "BruiserConstraints::rhsphi", "BruiserConstraints::rhswx", "BruiserConstraints::rhswy", "BruiserConstraints::rhswz", NULL }; char const * restrict const none[] = { NULL }; } // namespace variables static void get_varinds (cGH const * restrict const cctkGH, char const * restrict const * restrict const names, vector<int>& gis, vector<int>& vis) { int nvars = 0; while (names[nvars]) ++nvars; assert (gis.empty()); assert (vis.empty()); gis.reserve(nvars); vis.reserve(nvars); } void BruiserRestrict(CCTK_ARGUMENTS) { DECLARE_CCTK_PARAMETERS; CCTK_VInfo(CCTK_THORNSTRING,"reflevel = %d, mglevel = %d", reflevel,mglevel); CCTK_WARN(0,"BruiserRestrict: No clue what to do here. Aborting."); /* Something like... */ vector<int> gis, vis; get_varinds (cctkGH, variables::soln, gis, vis); CCTK_INT const nvars = gis.size(); int const tl = 0; CCTK_REAL time = 0.0; int const coarse_vi = CCTK_VarIndex ("Brusier::phi"); // What about other variables: wx, wy, and wz? int const coarse_gi = CCTK_GroupIndexFromVarI (coarse_vi); assert (coarse_gi >= 0); int const coarse_v0 = CCTK_FirstVarIndexI (coarse_gi); assert (coarse_v0 >= 0); int const fine_vi = CCTK_VarIndex ("Brusier::phi"); for (comm_state state; not state.done(); state.step()) { for (int m=0; m<maps; ++m) { ggf *const gv = arrdata.AT(coarse_gi).AT(m).data. AT(coarse_vi - coarse_v0); // This subtraction does what? gv->ref_restrict_all (state, tl, reflevel, mglevel, time); } } // for state }

2 4

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 04 Apr '12

04 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

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Users April 2012