Hello Zach, > Contrary to what is indicated above, the code in the loop actually > evaluates only the function in the [local] context, ignoring my [global] > requests, and giving a segfault (see full output from this loop below my > sig). Is there any way I can make this work, or am I doomed to repeat the > messy schedule.ccl of the past? Not having read this very carefully: I suspect that you run into global/local ordering issues. Most likely you need to make all routines OPTION: global and make the ones you think should be local into: OPTION: global loop-local otherwise a global routine cannot access the data in grid functions (only grid scalars). You cannot use OPTION: local (the default) either since it does not mix well with GLOBAL. See eg the scheduling for the Outflow thorn (EinsteinAnalysis I think) for some example (I think).
Erik tends to suggest to do this stuff using C++ and Carpet's ENTER_GLOBAL_MODE and BEGIN_REFLEVEL_LOOP macros (just grep the ET for this, there should be some routines that use it). There are also posts of Erik's to this effect on the list. This approach is kind of cleaner since the schedule is less convoluted but directly binds you code to Carpet (which I tend to dislike but given the Carpet is the only real driver right now). 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. _______________________________________________ Users mailing list [email protected] http://lists.einsteintoolkit.org/mailman/listinfo/users
