Support/Evaluate expressions also in default values within param.ccl (e.g. $parfile)

Comments (11)

1. 

   Frank Löffler

   • removed comment

   Steve: how difficult would it be to run the default parameter values through the parser as well?

   • 2013-04-25T09:21:53+00:00
2. 

   Steven R. Brandt

   • removed comment

   What I can do is add

   extern "C" void CCTK_EvaluateExpr(const char expr,int *type);

   This function attempts to match "expr" against the grammar rule of the same name, and if it succeeds evaluates the parse tree according to the rules used to evaluate parameters.

   I have a protytype if you'd like to try it.

   • 2013-04-25T09:44:30+00:00
3. 

   Erik Schnetter reporter

   • removed comment

   This seems too invasive just before the release. I suggest instead to change the default value of IO::out_dir to be something else but $parfile. Since the value $parfile never actually worked, no one is relying on this default.

   • 2013-04-25T09:49:22+00:00
4. 

   Frank Löffler

   • removed comment

   I agree, and changed the default back. Leaving the ticket open, to get it into the dev-version eventually.

   • 2013-04-25T09:57:14+00:00
5. 

   Frank Löffler

   • removed comment

   Steve: can you try your prototype and see if it works (with the default being $parfile)? If it does: please post the patch here.

   • 2013-04-25T09:57:55+00:00
6. 

   Frank Löffler

   • changed title to Support/Evaluate expressions also in default values within param.ccl (e.g. $parfile)
   • marked as
   • changed milestone to ET_2013_11
   • removed comment

   • 2013-04-25T09:59:27+00:00
7. 

   Roland Haas

   • removed comment

   extern "C" void CCTK_EvaluateExpr(const char expr,int *type); It might be good to add the word "Parameter" somwhere in the function name. For the trigger thorn (ticket ) we also wanted to expose a flesh function to evaluate expressions containing both parameters and grid scalars as variables. The later one might be all fancy and allow the user to choose which variables to expand (parameters, grid scalars, both, none) and even let the caller pass in an extra list of name-value pairs for private variables that one wants to use.

   Should the routine CCTK_EvaluateExpr be public or flesh internal (ie CCTK or CCTKi)?

   • 2013-04-25T13:53:01+00:00
8. 

   Erik Schnetter reporter

   • removed comment

   I assume this function would call malloc to store the return value, and expect the caller to free it?

   I assume this function is (or will be) also used by the scheduler to evaluate WHILE and IF expressions?

   This function seems quite useful; it should be public.

   • 2013-04-25T14:52:54+00:00
9. 

   Steven R. Brandt

   • removed comment

   Adding parameter to the name did occur to me after posting this :) , and yes it does require the user to call free().

   I'm not sure that the scheduler needs this, as it can take equations and directly from the CCL file and insert them into C code. I have included CCTK_EvaluateParamExpr available on the Piraha branch.

   If you are interested, I have been working on the Piraha interface a bit in general. In the Piraha branch (https://svn.cactuscode.org/flesh/branches/piraha_schedule) there's a file called Piraha.html which shows, side by side, how to use Piraha in C++, C, and Java. Basically, if you know regex's, it shouldn't be too hard to concoct grammars and parse them.

   • 2013-04-25T15:58:22+00:00
10. 

    Steven R. Brandt

    • changed status to resolved
    • removed comment

    Sorry, this was handled a while ago.

    • 2013-05-24T08:57:56+00:00
11. 

    Roland Haas

    • changed status to closed
    • edited description

    • 2019-02-21T19:51:26+00:00
12. Log in to comment